This Is More Than Just One Guide
11 courses and 20 free guides on AI automation for business — and beyond.
Make your agent faster and cheaper in one evening: move its decisions off the writing model
By the end of this guide you have four things: a marked-up list of the decision points in your own loop, a typed schema for the questions behind them, a router with a confidence threshold and a fallback, and your own before-and-after measurement. Generation stays with Claude Code. Only the checks move.
What is inside
free, all of itAn agent does two different jobs, and it has one tool for both
Generation and decision are different tasks with different prices. While both run through one model, you pay writing rates for classification.
Generation
Write the function, draft the reply, summarise the document. The answer space is open, nobody can list the valid outputs in advance. This needs a language model and always will.
Decision
Did the tests pass, which team owns this ticket, is this risky enough for a human. The answer space is closed and typed: yes or no, one of five, a score. Structurally this is classification.
The mix
Agents route both through the same model, so a three-way decision arrives as a paragraph of reasoning you then parse. Full generation cost, full generation latency, for an answer with three valid values.
Where the decisions hide in your loop
Take any loop you already run and read it as two streams. The generative stream stays where it is. The decision stream is the one worth moving, and it is usually larger than it feels while you are writing the prompts.
- Did the previous step actually succeed?
- Is this the file the task meant?
- Does the result satisfy the constraint I was given?
- Retry, escalate, or continue?
- Does this need a human before it ships?
Each of those has two or three valid answers. None of them needs a sentence. All of them, in a standard loop, are answered by generating one.
The neighbouring link in the same chain, where the agent picks the tool rather than the answer: Monid, a tool gateway for agents.
What the gain really is, and where it comes from
The figures going around are 200x faster and 400x cheaper. They are real, but they are the top of a range, and the range is published. TypeSafe's own launch post says the speed gain runs from 40x to 200x depending on the task, and calls the headline numbers the higher end of real-world gains. Plan for the band, not the ceiling.
speed range published by TypeSafe for System One shaped queries
per million input tokens for jev-1.13.0; output tokens are free
end-to-end decision latency, against 3–329 seconds for a frontier model doing the same check
The multiplier comes from density, not from one call
A single check is not 200x faster in isolation. The gain compounds because a loop with a review or validation step asks the same kind of question over and over. Move thirty checks and you removed thirty full-price generations. A workflow that is almost entirely writing gains close to nothing, because there is nothing to move.
Figures from typesafe.ai and its documentation, checked 20 September 2026. Versions and prices move, so verify before you budget against them.
Audit your own loop before you change anything
Do not start from the SDK. Start from a real transcript of your agent, not a hypothetical one, and mark every place the model was asked a bounded question. Hand the transcript and this prompt to Claude Code.
Read this agent transcript and find every point where the model was asked a bounded question instead of being asked to write something.
For each one give me: where it sits in the loop, the question as it was actually asked, whether the answer space is bounded or open, roughly what it cost in tokens and seconds, and whether it is a candidate to move to a decision model.
Rules: a question is bounded only if I can list every valid answer in advance. If you are unsure, say unsure rather than guessing. Tell me what you could not judge from the transcript alone.
At the end: how many calls were decisions, how many were generation, and what share of the run the decisions were.The two lines that matter are the last ones. A list that never admits uncertainty and never reports what it could not see is a list you will have to redo.
What Jev actually is, what it costs, and the nine places it breaks
Where the 40–200x range comes from, what Choice, Score and Noul return, and the failure modes its own authors publish. Free, no sign-up.
Four ways this goes wrong
- 01
Sending generation to the decision model because it is cheap. It will answer. It will answer badly, because you asked a classifier to write. Cheap and fast is not the same as correct with the wrong tool.
- 02
One confidence threshold for everything. A misrouted support ticket and a wrongly merged pull request are not the same risk. One number for both means you are too loose on the dangerous one or too strict on the cheap one.
- 03
Overlapping categories. If two of your options can both be true, the model still returns a confident answer, and nothing in the response looks wrong. A broken schema does not raise an error, it produces clean-looking mistakes.
- 04
Treating 200x as a target. It describes a narrow band: high volume, low ambiguity, tightly bounded decisions. Building your architecture toward a statistic instead of your own workload is how you end up with a fast wrong answer.
The whole pipeline, not just the split
Choosing thresholds per decision type, catching schema drift before it becomes a pattern, and measuring the before and after on your own workload: that is the part that takes a course rather than a page.
The loop stops waiting on its own bookkeeping
Nothing about the writing changes
Reviews, fixes and drafts stay with Claude Code, because that is genuinely generative work. What leaves is the bookkeeping: the pass-fail reads, the routing, the should-a-human-see-this. You do not get a smarter agent. You get one that stops charging you writing rates for arithmetic it was never doing.
Six steps to the split
Enough to run it on one loop this week
01.Take a real transcript
Pick a run that actually happened and was moderately complex. A hypothetical loop hides the checks, because when you imagine your agent you remember the writing and forget the twenty times it asked itself whether something worked.
This is the map. Tuning thresholds per decision, sampling for drift and proving the saving on your own numbers are worked through step by step in the course.
What counts as a result
Not a screenshot of a latency graph. A result is that one loop you actually run has its checks on a decision model, a threshold you chose by measuring rather than guessing, and a fallback path you have seen fire at least once. If you cannot say what happens when confidence is low, the split is not finished.
Build the agent, not just the shortcut
The courses walk the whole road: agents that route their own work, the checks that keep them honest, and the measurement that tells you whether any of it paid off.
Comments