Jev: Keep the Power. Cut the Overhead.

ELI5: give the computer buttons

Imagine an assistant with a blank page. It can write a plan, explain a bug, or produce code. That is what my main AI agents do.

Now imagine an assistant with three buttons: research, change code, or something else. You give it a request. It picks a button and returns numbers describing how strongly the evidence supports each option.

That second interface is Jev. You supply the situation and define the possible answers. It makes a bounded judgment. Your software decides what happens next.

A useful question is whether the next step needs new sources. Writing the research report remains a different job. Jev can help with the first; a generative model handles the second. The System One documentation makes that boundary explicit.

Why this landed on my desk

I run Claude Code, Codex and Grok Build with their strongest configured models and maximum reasoning settings. The cost problem is real enough to deserve engineering attention. Reducing capability by default is not the optimization I am looking for.

The direction in Astra × Fable: Full Power, Less Waste was to remove avoidable work around the models: repeated setup, oversized source loads and mechanical operations that ordinary code can perform. I Love Trios added the third agent to that environment. Handling AI Usage Limits and Clean Handovers describes limit detection and clean handovers.

Jev raises a narrower, useful question: how many steps in that environment need a full generative-model call, and how many only need a well-defined decision?

This is a research guide and an integration proposal. I have not installed Jev into that setup or measured savings from it. The older projections in The Expensive Part Is Remembering were projections too. The current requirement remains maximum capability with evidence that an optimization preserves the result.

What Jev actually is

TypeSafe AI introduced Jev on September 15, 2026. Founder Diogo Almeida describes a model architecture, parallel sampler and training method called Reinforcement Learning for Calibrated Decisions, or RLCD. The stated training target is useful decisions with probabilities that reflect uncertainty. The name Jev comes from William Stanley Jevons; the System One label borrows the fast-thinking idea popularized by Daniel Kahneman. These are TypeSafe's product and research descriptions. Launch announcement.

The distinctions matter:

“Building a Harness with Jev” is LangChain's integration article. Jev is a component you can put inside a harness. It does not replace Claude Code, Codex or Grok Build merely because you install a package.

Nor is this the first time software has used machine learning to classify something. Spam filters, classifiers, rerankers and structured LLM outputs already exist. The interesting proposition is the combination: natural-language questions, a constrained answer space, explicit probabilities, low latency and a low published input price.

If a regular expression or an exact database lookup already answers the question reliably, use it. Jev becomes interesting where the branch depends on meaning.

Why giving up prose changes the economics

A generative model produces a sequence of output tokens. Even when the desired result is a small classification, the interface may involve generating structured text and, depending on the model and settings, additional reasoning. Constrained output already exists for LLMs; returning valid JSON is not a new invention.

TypeSafe's proposition goes further: train for the bounded decision itself and evaluate the answer probabilities in parallel. Its AI primer distinguishes RLHF, which uses human preference feedback, RLVR, which uses verifiable rewards, and its own RLCD decision objective. That explains the intended specialization; it does not prove an advantage on every task.

Input preparation, reading the supplied state and network travel still take time. Jev's design removes a kind of output work. The whole application still has to supply a useful problem.

Three primitives, three different questions

Every request contains state, the evidence to examine, and questions, the judgments to make. State can be text or structured text such as JSON. The caller defines what each question means.

Choice: which option fits?

Use Choice for a category or action selected from a finite set. For a software request, the options might be research, code_change, documentation and other.

Jev returns the selected option, a probability distribution over the options, and a confidence value. The current limit is 255 options. A larger taxonomy needs candidate filtering or multiple stages. Include an escape category when the list might not cover the input; otherwise a closed list still produces a winner. Choice reference.

An illustrative distribution of 0.80 research, 0.15 code change and 0.05 other means the model favors research. Those are example values, not a result I obtained.

Noul: is this proposition true?

Use Noul for a yes-or-no proposition: “Does this request require current external documentation?”

It returns the probability of yes. Near zero means a strong no; near one means a strong yes; near the middle means uncertainty. Noul does not have a separate confidence field. A value of 0.8 for “is urgent” describes the model's belief in that proposition. It does not mean the task is 80% urgent. Noul reference.

This is useful for independent flags: needs fresh sources, mentions a production incident, includes contradictory evidence. Your code can combine them.

Score: where does it sit on a rubric?

Use Score for ordered descriptive levels. A source-quality rubric could define “unsupported assertion,” “relevant but incomplete evidence,” and “direct evidence covering the claim.”

Jev returns a probability-weighted position on those levels. Three levels have indices 0, 1 and 2; the score can fall between them. The current API accepts two to ten levels and also returns the distribution and confidence. Score reference.

A score of 1 can describe certainty about the middle level or a split between the two extremes. Those situations deserve different treatment. Keep the distribution when the distinction matters.

A rubric also has to contain the meaning. Naming a question excellent_evidence does not explain what excellent means. Put the criteria into the instructions and descriptions.

Confidence is useful because you can do something with it

Choice and Score confidence summarize how concentrated their distributions are. That statistic is distinct from the probability attached to one answer. A confidence value of 0.9 should not be read automatically as “this decision is 90% likely to be correct.” Confidence documentation.

Calibration is another concept. Across a well-calibrated population of predictions assigned probability 0.8, the relevant outcome should occur roughly 80% of the time. A single answer is still fallible, and calibration on one workload does not establish calibration on yours. TypeSafe's machine-learning primer.

The engineering benefit is that uncertainty becomes an input to the program. You can route ambiguous cases to a stronger reasoning step, gather missing evidence, or retain the existing workflow.

There is no universal threshold that makes every action safe or every answer useful. Tune against the error you actually care about. A misplaced document in a shortlist and an incorrectly accepted production change have different consequences.

For a first experiment, I would prefer a question with an observable answer and a reversible consequence: whether a document belongs in a research shortlist, for example. That makes mistakes easier to label and the benefit easier to measure.

What a harness with Jev looks like

In Your Agent Doesn't Have a Model Problem, I separated the model from the program that operates it. Jev makes that distinction especially concrete.

The harness prepares a useful state, asks a bounded question, interprets the answer, selects a permitted next step and checks what actually happened. Jev only supplies the judgment in the middle.

Consider a request to investigate a failed build. Ordinary code already knows whether the build failed, which revision ran and which logs exist. There is no reason to ask a model to rediscover those exact facts.

Jev could classify the failure evidence into a known set of investigation paths, or rank candidate documentation for relevance. The selected full-strength agent then investigates and writes the fix. Tests and the required independent review still decide whether the change is ready.

The important optimization is where the decision happens. If the premium agent has already loaded the entire trace and reasoned through the routing question, calling Jev afterward adds a second opinion and more work. It may improve quality, but it has not automatically saved the first call.

To save work, the new component must eliminate a call, prevent unnecessary context loading, avoid a bad retry, or otherwise reduce a measured downstream cost. Drawing another box in the architecture does none of that by itself.

What LangChain already provides

The official TypeSafe integration exposes TypeSafeClassifier, a Runnable returning classification results rather than a chat response. It accepts text, JSON and LangChain messages. Its results separate choices, scores and nouls.

The experimental middleware adds two concrete patterns. ModelRouterMiddleware chooses from configured models using the latest human message and keeps that selection for the run. It is not an automatic reassessment after every tool result. AutoModeMiddleware checks the tools you list and refuses blocked calls through a tool error message. Human approval is a separate mechanism.

Those are useful building blocks for a custom application. They are not a switch that rewires every internal decision in three existing native coding programs. For my environment, the first integration point would be code I already control around the agents.

General-purpose products may use Jev to select a cheaper writing model for simple requests. My first trial would preserve the three maximum-strength workers and test the small decisions surrounding them.

What people are building

The early projects are interesting because they expose different places where a bounded judgment can replace a longer model interaction. They are also days-old demonstrations. Here is what their evidence actually shows.

Browser Use: choose an operation and an observed target. The open-source Jev Ultrafast project turns the page into an indexed set of DOM controls. Jev chooses actions and targets; another model writes text when a field needs it. Code checks whether the target is still valid before execution. Jev does not see screenshots in that normal loop.

Its recorded flight search took 7.073 seconds with 17 Jev requests. The performance report includes inference, typing and browser work in that clock, but excludes setup, initial navigation and the independent final verification. It is a search demonstration, not a completed ticket purchase or a broad browser benchmark. The architecture is more reusable than the stopwatch number.

Stagehand: another browser wrapper around the same idea. Kyle Jeong's September 17 post demonstrates Jev with Stagehand and reports a $0.001 task. That is a creator-reported example, not a cost guarantee for arbitrary websites.

Email triage: a natural first workload. Ryan Vogel reported trying 1,500 of his own emails. The post does not supply a labeled accuracy study. The use case is nevertheless clear: classify subject matter, whether a reply is requested and which queue should receive it. Generating the reply remains a separate step.

Computer use: perception still has to happen somewhere. Andrew Levin's macOS prototype combines OCR, accessibility controls and ordinary preprocessing with Jev's choices. Its large model-cost comparison concerns a narrow decision; the complete step includes capturing and interpreting the screen. That distinction matters when comparing it with a vision-capable agent.

MCP and CLI wrappers: useful packaging. Projects such as jev-mcp expose decision tools to agents. Its extraction pattern is revealing: code finds candidate strings, then Jev selects among them. It has not acquired free-form text generation. These are community integrations; check their ownership, data path and execution behavior separately from TypeSafe's model.

Fast trading decisions are also being demonstrated. Jarrod Watts showed Jev selecting trades on Monad/Kuru. A fast buy-or-sell decision demonstrates integration and latency. The post does not establish profitability or forecasting quality.

The strongest general use cases are less theatrical: queue routing, document relevance, repeated rubric evaluation and bounded decisions inside an existing workflow. They come with clear inputs, a finite answer space and outcomes you can check.

Jev as a judge: promising, with a small evidence base

LangChain's September 20 Jev-as-a-Judge experiment reports stable repeated evaluations and complete agreement with its human binary labels. The corpus contains five frozen weather-agent responses, each evaluated 100 times. That is five distinct examples, not 500 distinct tasks.

The published repository is valuable because it exposes the rubric and implementations. One continuous quality metric averages three Noul probabilities. The LLM comparators produce numeric ratings, so the variance comparison is not a clean experiment isolating model architecture alone. Jev's mean reported call cost was $0.00035 versus $0.00039 for Luna in that workload: a modest cost difference, despite a larger latency difference.

A broader first-party operator report comes from Nexus. On its 469-case comparative subset, Jev decided 58% of cases and made five errors among those 274 decisions. With the old rules handling abstentions, the total was 90 errors; the Sonnet-plus-rules version had 92. Much of the labeling used independent AI judgments and adjudication, with a separate human audit. Comparator thresholds and timing also had limitations.

That illustrates why coverage belongs beside accuracy. A system can look excellent on the cases it accepts while handing the hardest cases to something else. The useful comparison includes that fallback's errors, time and cost.

For my workflow, Jev could help screen traces or flag weak completion evidence for attention. It would not replace a required independent reviewer or turn a model's “done” label into proof that a task succeeded.

The price is small. The accounting still matters.

As checked on September 20, the direct TypeSafe model reference lists $0.042 per million input tokens, or $42 per billion, with output free. Both jev-latest and jev-preview currently resolve to jev-1.13.0. These are dated service details, not permanent guarantees.

Here is simple arithmetic at that input rate. Assume every decision uses 5,000 billed input tokens, including its questions and rubric.

These are calculated examples. They exclude retries, fallback models, browser infrastructure, integration work and the cost of correcting mistakes. A request with a long trace costs more than one with a short ticket.

For a workflow that previously called a frontier judge every time, the simplified comparison is:

Old model cost = N × frontier decision cost

New model cost = N × (Jev cost + fallback rate × frontier decision cost)

Then include infrastructure, retries, maintenance and error correction.

This only describes the work actually replaced. If decision calls represent 5% of total cost, even removing their entire cost cannot save more than 5% of the whole. If Jev is an extra check after the existing call, it initially increases cost.

For subscription-funded workflows, a lower API-equivalent token valuation does not reduce a fixed monthly subscription charge. Less consumption might leave more allowance for useful work or postpone hitting a limit; that requires observation. Any Jev API calls add their own bill.

TypeSafe's launch headlines report roughly 194× faster and 445× cheaper results on selected workflows. The company itself describes those as toward the high end of expected gains. Its workflow evaluation site uses model-consensus reference probabilities and a particular comparison harness. Those figures do not measure my complete three-agent workload.

The metric I want is cost and elapsed time per accepted task at the same quality standard. Price per classifier call is one input.

Your first call, without building a new framework

The direct route uses a TypeSafe account and API key. Access availability is handled through its console. The quick start documents POST https://api.typesafe.ai/v1/systemone, authenticated with a bearer token.

For Python 3.10 or newer, the official SDK supports the following shape. This example is checked against the documentation; I have not run it against the live Jev service. Set TYPESAFE_API_KEY in your environment rather than putting a credential in the source.

pip install typesafe-sdk==0.7.0

from typesafe_sdk import Choice, Noul, TypeSafeClient

with TypeSafeClient(model="jev-1.13.0") as client:
    result = client.system_one(
        state={
            "request": "Find the official SDK retry documentation."
        },
        questions={
            "work_kind": Choice(
                instructions="Which category describes request?",
                criteria={
                    "research": "Find and read external sources.",
                    "code_change": "Write or modify application code.",
                    "other": "Neither category fits."
                }
            ),
            "needs_current_sources": Noul(
                instructions=(
                    "Does request require current external documentation?"
                )
            )
        }
    )

kind = result.answers["work_kind"]
print(kind.choice, kind.probabilities, kind.confidence)
print(result.answers["needs_current_sources"].noul)

The example prints judgments. It neither fetches the documentation nor launches another agent. That next operation belongs to your application.

The raw API response contains the answering model, named answers and usage. Log the returned model version. The response can report output-token usage even though outputs are free and Jev is not writing prose.

For a read-only preparation step, the surrounding control flow could look like this. This is pseudocode: the helpers and thresholds are supplied and tested by the application.

def prepare(request):
    enforce_existing_policy(request)

    route = exact_rule_for(request)
    if route is not None:
        return run_permitted_helper(route, request)

    try:
        answer = classify_with_jev(request, deadline=HELPER_DEADLINE)
        validate_answer(answer)
    except DecisionServiceFailure:
        return existing_full_strength_path(request)

    if answer.choice == "other" or not passes_validated_threshold(answer):
        return existing_full_strength_path(request)

    enforce_helper_policy(answer.choice, request)
    return run_permitted_helper(answer.choice, request)

The threshold represents evidence from evaluation, not an arbitrary constant. Response validation covers the expected schema, allowed choice and valid probability values. Both paths keep their existing verification requirements.

There are other access routes. OpenRouter lists typesafe/jev-1.13. Vercel AI Gateway exposes typesafe-ai/jev through the AI SDK's experimental evaluation interface. Cloudflare documents typesafe/jev. Check each route's schema, effective limits and pricing; a provider-specific decision interface is not automatically a chat-completions replacement.

The official agent skill teaches the integration patterns. Installing it does not create credentials, replace the planner or automatically intercept expensive calls. Use the model directly first, on one well-understood question.

Advanced: make the question set do useful work

The first design improvement is to ask independent questions together. Suppose a document needs relevance, freshness and evidence-quality judgments. Sending its entire body three times repeats work. A shared-state request lets several questions examine the same material. TypeSafe's parallel-questions cookbook demonstrates this pattern.

The independence has a consequence: one question does not see another question's answer. If the second decision requires a newly fetched document, it needs a new state. If all the evidence is already present, you may ask several possible branch questions together and let code use only the relevant result.

Browser Use makes this tangible by asking about possible operation-specific targets alongside the operation itself. The executor selects the compatible target. An answer produced for an unused branch does not authorize an action.

The second improvement is decomposition. “Is this research good?” compresses several judgments into one vague rating. Ask whether the cited source supports the claim, whether a date-sensitive claim has current evidence and whether two sources conflict. Combine those signals with explicit rules. TypeSafe describes this general approach in its patterns guide.

The third improvement is state design. Give the decision the evidence it needs, with provenance and enough surrounding context to avoid misleading fragments. A relevance classifier with no task definition is guessing. A completion classifier with no success criteria cannot know what completion means.

Shared state within a request should not be confused with a cross-request cache discount. Application-level reuse is possible, but the key must include every input that can change the answer: evidence, question, policy and model version. Reusing a decision after any of those changes creates a different problem from paying for a repeated call.

Finally, plan for abstention and failure as ordinary outcomes. A low-confidence decision, a timeout and an invalid request are different events. Keep them visible. The SDK retry controls support bounded retry behavior; the surrounding workflow still needs a fallback and an overall time budget.

Where it breaks, and what should stay in code

TypeSafe's own Jev 1.13 limitations page is essential reading. It documents weak counting and arithmetic, problems with date comparisons, literal interpretation, indirection and irrelevant context. Adversarial instructions inside state can influence answers. Related questions can also produce answers that are not logically consistent with one another.

Use ordinary code for totals, date ordering, exact membership, permissions and invariants. Use Jev where interpreting meaning adds value. Keep authorization separate from its assessment of an action.

The “zero hallucinations” claim has a narrow meaning: the answer is constrained to the declared schema. A valid label can still be wrong. A label named allowed does not establish that a caller has permission to perform the action.

Current direct-service limits allow 64k tokens across the state and all questions, with a separate 32k ceiling for the state plus the longest question. Input is text only. English is the strongest documented language; test the languages you use. Model aliases move, and rate limits can change. Model limits.

The managed service also adds a network dependency and a data destination. Open SDKs do not mean open model weights or local inference. TypeSafe says it does not train on customer requests; that is distinct from its enterprise zero-retention offering. Use the data-handling terms appropriate to the material being evaluated.

None of this makes the model uninteresting. It identifies the questions worth giving it and the responsibilities its caller still owns.

The founder's coding-agent notes, and the PDF that is not his

On September 21, Diogo Almeida, TypeSafe's founder, posted a link to a public Google Doc titled "[public] thoughts on a typesafe coding agent", with one line of framing: the team "likely will never have time (ever again) to play ourselves", and he hopes "the community goes WILD (and makes me look like a naive idiot)". It is a design notes document. No implementation, no measurements, and the one set of cost proportions in it is introduced with "let's have chatgpt vibe some proportion".

The same day, a widely shared post announced that the "Jev Founder … just released [a] 12-page PDF on building a Jev Harness for coding agents", a "10-step blueprint on how to make your coding agents 200× faster and 400× cheaper". The PDF exists. Its own title page says "A Synthesis for Study · Based on design notes by Diogo Almeida (TypeSafe) · Independently compiled, September 2026. Not affiliated with or endorsed by TypeSafe", and its sources page adds that "all diagrams are original" and that its token-share table "is an illustrative estimate". So the founder released notes; an unnamed compiler typeset them into a twelve-page paper with tables and figures of its own; and the "200× faster and 400× cheaper" line reads as a rounding of TypeSafe's 193.6× and 444.6× launch figures for selected workflows, covered above, and appears in neither the notes nor the PDF.

The post is wrong on two checkable points, authorship and numbers, and right that the notes are worth reading. The ideas are the founder's. The tables, the policy snippet and the percentages not attributed to someone else are the compiler's. The speed and cost multiples are TypeSafe's launch figures for other workloads. None of it is a measurement of a coding agent, because no such agent has been built.

Design as if the KV cache did not exist

The notes open with a question the founder says he asks engineers: "how would you design a coding agent if LLMs had no KV cache?" The cache is why agents are append-only transcripts. Reusing a cached prefix is cheap; changing anything early in the context invalidates everything after it. Take the cache away as a thought experiment and six familiar behaviors look different.

Routing fails, and not because cheap models are weak. The plan of letting a frontier model plan, a cheaper model execute and the frontier model review has a hidden cost: the cheaper model must load the whole accumulated context fresh, and the frontier model then reads back everything the cheaper model produced and touched. With list prices of $5 in and $25 out per million tokens for Opus and $3 and $15 for Sonnet, the notes write the two paths out. X is context, Y is generated output, Z is tokens read during the work.

Path 1, pure Opus:              25·Y + 5·Z
Path 2, Opus → Sonnet → Opus:   3·X + 20·Y + 8·Z
                                (Sonnet loads context, generates, reads;
                                 Opus reloads what changed)

With X = 0.65, Y = 0.12, Z = 0.23  (proportions the notes call "vibed"):
pure Opus ≈ 4.15   routed ≈ 6.19   → staying put costs about two thirds

The proportions are invented for illustration and the list prices move. The shape of the result does not depend on them. Subtracting the two formulas, the routed path only wins when 3X + 3Z is smaller than 5Y, that is, when generated output is large relative to the context and to what the work reads, and coding sessions are read-heavy. Routing becomes viable only when the harness can hand the cheaper model a small, purpose-built context and take back a scored result rather than a transcript.

Tools crowd the context. Every schema must be declared up front whether or not it is relevant, and the notes' guess is that models are "not that smart" at high-cardinality, off-policy tool calling, which may be why skills, which load a description and defer detail, often do better than raw tool lists. Compaction compresses blind, before the next question is known; query-aware compression is easier because you know what to keep. Sub-agents are rare because deciding what to pass in and what to merge back is the expensive part. Restarts throw away good state with bad. And the batteries debate exists only because every built-in costs context forever.

The notes quote Microsoft's FastContext project for where tokens go: "reading and searching account for 56.2% of all tool-use turns and 46.5% of the main agent's total tokens" in GPT-5.4 trajectories. I could not fetch that README directly; the figure is cited here as the notes quote it, and the FastContext paper's own abstract reports up to 60% token reduction from moving exploration into a sub-agent. The PDF's fuller breakdown, with writing code under a tenth of tokens, is the compiler's estimate and says so.

Six decisions Jev would make per turn

Everything the notes propose reduces to a Jev question asked at a high-frequency decision point. The PDF's own table lists six; every one of them is in the notes.

The first row is the one the founder calls "meta-attention": context is not static, and for every query the harness asks how good the previous context was, whether reusing the KV cache is worth it, and how to construct a new one with everything relevant and nothing else. In its simplest form that is a noul on every chunk. A later form is a four-level visibility ladder, so a 2,400-line grep result can be twelve relevant hits for one question and invisible for the next without ever being deleted from state. It is the idea behind compaction with its main flaw removed: compress after the question, not before.

Two limits from earlier in this article apply to every row. With 32k tokens for the state plus the longest question, a transcript is never the state; chunks are. And per-chunk questions are linear in transcript length, which the founder himself flagged on September 17 about binary checks on every message: linear work per message adds up even at a hundred times cheaper. His sketch of a fix is a hierarchical history that makes context "a log(n) search". A sketch, not a design.

The fifth row is the one closest to what exists today. The notes describe it as "similar to claude's auto-mode" with two additions: policies expressed as programmable queries, and deeper inspection where the stakes justify it, reading a script's contents before running it rather than approving its name. The PDF's example policy is worth reading for what is a rule and what is a judgment.

policy "exec":
  deny  if command touches ~/.ssh or .env*                # rule
  deny  if script contents contain network egress
        unless task.scope is deploy                        # Jev reads the script; the scope is a rule
  ask   if command writes outside repo root               # rule
  allow if command in read_only_set                       # rule

One line in four is Jev-shaped: the policy is code. Jev interprets the script; it does not hold the authority.

Tiers, conditions, trust and background work

Four more ideas follow from explicit, typed state.

Tools in tiers. Short snippets of what exists, because a model cannot propose an action it does not know is possible; the full schema on demand, like a tool-search tool; documentation for one-off queries; and none of it corrupting the context once it is no longer needed. If that works, the notes argue, an agent can ship with "100s of tools + 1000s of docs built-in" at almost no cost, and the batteries debate dissolves.

Instructions by condition. Instead of loading AGENTS.md in full, load sections when their condition holds: front-end work loads the style guide, a subdirectory loads its gotchas file, and the notes suggest every subdirectory should have one. The distinction from skills is deliberate. Skills mean "do this now"; conditional instructions mean "have this in memory somewhere", and they need a property skills lack, immunity to compaction, because a condition-bound instruction is reloaded whenever its condition holds rather than remembered.

Routing by trust, not only difficulty. Some open-weight models served through low-cost endpoints are dramatically cheaper, and the notes are blunt that data passing through some of them may not stay private. The proposal: estimate which kinds of files a subtask will touch, attach a policy to each file class, and route accordingly. Public documentation can go anywhere; secrets, environment and infrastructure configuration stay on first-party frontier models; a team doing model research might exclude a named vendor for reasons that have nothing to do with cost. Once routing is policy-driven, those preferences become configuration instead of discipline.

Background work on shared retrieval. The notes spot a pattern across recent agent workflows: progress pages that update in parallel, evals generated in the background, an ELI5 explainer, and cross-model review, "have codex review claude's work". All of them run in the background and all are read-only functions of the current codebase state. Finding the files relevant to a change is expensive; if that retrieval is done once and shared, running many read-only tasks becomes cheap, and being explicit about reads versus writes means they never contend for locks.

What has actually been measured

The notes measure nothing, by their author's own framing. Three independent data points bear on the notes' proposals, none from TypeSafe.

ctxjev is the first row of the decision table, built by a third party, on one transcript, with nobody yet checking whether the agent's later answers changed after the cut.

The injection test agrees with the limitations page on adversarial text in state: blunt "ignore your instructions" attacks fail, social ones partly succeed. In the project's words, "Claiming a human already approved the command worked ten times more than claiming authority over the model." The command that flipped under every framing was git stash clear, which needs a hard rule regardless of any model. The confidence gap between successful attacks and legitimate traffic is the kind of signal a threshold can act on, with the usual caveat that an average is not a distribution.

Battleship is a shape result. Choice discriminates between meaningfully different options; it does not search a large space of nearly identical ones. That is the caveat for the tools tier above: a Choice over hundreds of similar tools is the wrong shape, and a deterministic shortlist followed by a Choice among a dozen distinct candidates is the right one.

Against those three: the notes' zero measurements, the PDF's illustrative tables, and a post that turned selected-workflow launch multiples into a promise about coding agents. The Nexus comparison earlier in this article remains the evidence for the judge role. "200× and 400×" attached to a document with no benchmark is marketing, whoever forwards it.

What this changes for my three agents

Less than the post suggests, and in one place more.

The routing arithmetic supports something I had decided by instinct: never hand a task to a weaker model mid-session. A cheaper model that has to receive the whole context and hand it back is not cheaper, and the notes put illustrative numbers on the intuition. It is also the case for running my independent reviews as separate, tool-less children with a purpose-built brief rather than as a mid-session handoff: the reviewer gets a context built for the question, not the transcript. That is an argument matched to my setup, not a number from it.

Conditional instructions are close to what a manifest already does for me: each repository lists the references a task must read, generated adapters point every agent at the same canonical file, and a hook refuses to run without them. Compaction cannot erase them because they are re-read from disk, not remembered. What I lack is a judged condition: the manifest keys on task type, and Jev would only be asked where a task description leaves that ambiguous. The notes' version, per file pattern and per subdirectory, is worth borrowing.

Background read-only work on shared retrieval describes cross-vendor review almost exactly. What I do not have is the shared retrieval pass; each reviewer rebuilds its own picture from the brief.

Nothing here changes the plan. The pilot in the next section is still a proposal, still replay-then-shadow, still one narrow reversible path at a time. Two candidates join the table: context-chunk visibility on a replayed transcript, judged against what the agent actually needed later, and command policy in shadow mode, judged against the decisions the existing permission system made.

Where I would start with my three agents

My current configuration is Claude Code with Fable 5.1 at max, Codex with Astra at ultra, and Grok Build with Grok 4.7 at xhigh. Those are native settings on different products, not a universal reasoning scale or a guarantee about every backend execution.

I would leave the primary work and required independent reviews there. The candidate experiments sit around them:

My first choice would be optional research-source ranking. Mandatory procedures and required original sources would remain mandatory; Jev would only help select among additional candidates. It is a contained decision with a concrete failure to measure: omitting useful evidence.

The first pilot would run on a labeled replay set with the existing path retained. Separate cases used to tune questions from cases used to judge the result. Split related traces together so near-duplicates do not leak across that boundary.

Then run in shadow mode: record Jev's proposed decisions without letting them change execution. Measure false inclusions, false exclusions, uncertainty, latency and how often its suggestion would actually remove work. Include awkward and adversarial inputs, not only obvious examples.

Only after that would I enable one narrow, reversible path. Keep the same task-quality standard and record fallback work, corrections, retries and rejected outputs. Each decision record should identify the model version, evidence and policy versions, distribution, latency and eventual outcome. Compare cold starts with cold starts and resumed runs with resumed runs. A successful process exit is not an accepted result.

I would stop the experiment if integration overhead exceeds the work removed, or if quality loss merely pushes effort into repair. I would expand it if the full workflow completes the same work reliably with less consumption or delay.

The part worth being excited about

The practical opportunity is more places where software can make a small, context-sensitive judgment without waiting for a long generative interaction. That can improve routing, make evaluations affordable more often, and keep expensive reasoning focused on the work that benefits from it.

It can also lead to far more decisions being made. A cheaper call is an invitation to use it everywhere, which is why the Jevons reference fits. Efficiency per decision and lower total expenditure are separate outcomes.

For my setup, the next useful step is a measured experiment around one repeated decision. The three agents keep their capability. Jev has to earn its place by removing work while preserving the result.

The September 21 notes sharpen that sentence rather than changing it. Of the notes' proposals, the two worth trying are the ones I can measure at a boundary I already control: which chunks a turn sees, and whether a command may run. Both queue behind research-source ranking. The ones worth admiring from a distance, for now, are the ones nobody has built. The evidence for a Jev-centric coding agent today is one transcript, three hundred gate calls and a second-hand board game; the judge role has Nexus and LangChain, and TypeSafe has its selected workflows. When someone builds the harness the notes describe, the question will be the same one this article ends on: did it remove work while preserving the result, and who measured it? I will run the replay before I believe more.