Bouncer

Every prompt gets the best seat

The way I use AI models right now, every prompt goes to the same place. A one-line “what does this flag do” and a request to restructure half a package both land on the most capable model I have, with the same tools attached and the same context loaded. That’s the comfortable default, and it’s also the expensive one. Most of what I send doesn’t need frontier-level reasoning, and some of it doesn’t deserve an answer at all — it’s a half-typed thought, or something I’d have been better off spending ten more seconds writing.

Bouncer is the thing at the door. Before a prompt reaches a model, something cheaper looks at it and decides whether it gets in, and where it gets seated.

How the door works

The gate is JEV, a small model built for exactly this kind of judgment call. Instead of asking it to generate text, Bouncer asks it structured questions about the prompt and gets typed answers back, each with a confidence score. Right now there are two:

• Is this a bad prompt? Empty, chitchat, spam, or gibberish. If JEV says yes with better than 80% confidence, the prompt is turned away with a note asking for more context, and no expensive model is ever called.
• How complex is it? Low, medium, or high — a rating of how much technical or cognitive effort the instruction actually needs.

The threshold on the first question matters more than it looks. A gate that blocks too eagerly is worse than no gate, because the moment it turns away a real question I’ll stop trusting it and route around it. So it only blocks when it’s sure, and anything ambiguous falls through.

Where it is today

Honestly, early. The gate works: JEV classifies the prompt, bad prompts get stopped, and everything else streams back from a model. But the routing table behind it is a foundation rather than a policy — every complexity level currently lands on the same model. The next step is the obvious one: low-complexity prompts go to a small, fast model, and only the genuinely hard ones get sent up to a high-reasoning tier.

That alone is most of the savings. The rest of the idea is about what happens to the prompts that do go up.

Checking bags at the door

A prompt doesn’t travel alone. By the time it reaches a model it’s carrying conversation history, files that were relevant three messages ago, and the full definition of every MCP server I’ve got connected — whether this particular question needs a browser, a docs connector, and a database client or not. All of that is tokens, and on a high-reasoning model it’s the most expensive tokens in the request. It’s also noise. A model reasoning carefully about a type error doesn’t benefit from knowing it could also open a Chrome tab.

So the two goals after routing are:

• Strip context that isn’t needed. Use the same cheap pre-pass that judges complexity to judge relevance — which parts of the history and which attached files actually bear on this prompt — and send only those.
• Turn off MCPs that aren’t needed. Decide up front which tools this prompt could plausibly use, and only expose those to the model. Fewer tool definitions means a smaller prompt and fewer wrong turns.

Both have the same failure mode as the gate itself: trim too aggressively and the expensive model gets a worse question than the one I asked. The rule I’m holding onto is the same one as the 80% threshold — when Bouncer isn’t sure something is unnecessary, it stays.

Why a library

Bouncer is a package in my monorepo rather than a setting in one tool, because the decision it makes isn’t specific to any one client. Anything that sends a prompt to a model can ask the bouncer first. The goal is that the expensive model only ever sees prompts worth its time, carrying only what they need.