I put a second AI in front of my AI. It answers in probabilities, not paragraphs.

A developer built two Claude Code hooks that place TypeSafe's Jev, a System One model returning typed judgments with probabilities rather than prose, in front of the coding agent. One hook routes each message to one of four model tiers (tiny, everyday, large, hardest) and the other picks among installed skills, with both defaulting to off and failing open on a prepaid credit account with no card attached. The developer reports the router's value is making the model choice explicit and cheap on every message, and that Jev was approved for ParkEase's API but never shipped there.

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. 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. A router that guesses wrong is worse than no router. So the design leaned hard on Jev's numbers: 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. 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. 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 https://github.com/Deonkar/parkease