我把 Jev 放到 Claude Code 前面，讓它以概率而非段落作答

Most of this series is about one AI: the coding agent that wrote ParkEase. This post is about a different kind of model, and an experiment in putting it in front of the coding agent.

The model is Jev, from TypeSafe. It's what they call a System One model: instead of generating prose, it answers a question with a typed judgment and a probability. A yes/no comes back as a number between 0 and 1. A pick from a list comes back as a choice plus a probability for every option. A rating comes back as a score.

That makes it a different tool from a chat model. You don't parse its answer; you branch on it.

The two hooks

Claude Code lets you run a script every time you submit a message. I built two of these hooks, with Jev doing the deciding.

A model router. Not every message needs the biggest model. "Rename this variable" and "design the payout reconciliation" deserve very different horsepower. The router asks Jev one question with four described options: is this message tiny (a lookup or rename), everyday (a routine single change), large (a multi-step build or a feature across files), or hardest (strategy, or anything where a wrong call is expensive)? Each size maps to a model, from the smallest to the strongest. Jev returns its pick and a probability for each.

A skill picker. Given my message and the list of installed skills, which one fits? Same shape of question, a choice over skills, a probability on each.

The parts that made it trustworthy

A router that guesses wrong is worse than no router. So the design leaned hard on Jev's numbers:

• A confidence floor. If Jev's top pick is below 60% sure, the hook stays quiet. No suggestion beats a coin-flip suggestion.
• It fails open. Any error, timeout or malformed answer, and the hook outputs nothing; the message reaches the coding agent exactly as if the router weren't installed. It gets a 2.5-second budget, then gives up.
• Every answer is validated. The response is checked for the right type, a known option, and real probabilities before anything acts on it.
• It suggests, it doesn't override. The workflow's gates always win. Money, ledger, migration and auth work stays with the main model regardless of what the router says.
• It never logs what I typed. Only the decision and its numbers.

Off by default, on purpose

Both hooks are switched off unless I say "router on" or "skill picker on". While they're on, every message I type goes to a third-party API. That's fine for building a parking app in public. It isn't fine for anything private, so the default is off.

Cost was handled by construction, not discipline: the account runs on a small prepaid credit with no card attached. If it runs out, the hooks fail open and nothing gets billed.

What it didn't do

Honesty, because this series is supposed to be useful.

Jev was also approved for use inside ParkEase's API and job worker, for small judgment features such as sorting support tickets. That never shipped. The product has no Jev calls today. Its real contribution was to the development workflow, not the app.

And the router's value isn't that it picks better than I would. It's that it makes the choice explicit and cheap on every message, without me having to think about it.

The takeaway

There's a whole category of decisions in AI-assisted development (which model, which skill, is this risky, is this done) that don't need a paragraph. They need a calibrated yes, no or pick. Putting a small judgment model in front of a big generative one is cheap, fast, and easy to keep honest, as long as it fails open and you respect its uncertainty.

Next: I counted every skill the AI actually invoked across 55 sessions. The top of the list wasn't what I expected.

ParkEase is a peer-to-peer parking marketplace for India, built solo with Claude Code.
Code: https://github.com/Deonkar/parkease