How to introduce TypeSafe's Jev into agentic workflows

Jev is TypeSafe AI's decision model, which TypeSafe announced on 15 September 2026 as its first public model, then in early access. As of 27 October 2026 jev-latest points at jev-1.14.0, the stable release on the models page. It takes a state and a set of typed questions and returns an answer to each, with a probability for every option, and it neither writes text nor runs a tool.

To introduce Jev into an agentic workflow, put it beside the loop as an adviser, starting with a gate that scores every proposed tool call and blocks nothing. Once that shadow gate's logs are trusted, its answers can decide low-risk calls, then which model handles a turn, which tools the agent sees, and when a loop should stop. Application code keeps permissions, arithmetic and every side effect throughout.

The order here is the one we recommend, and the examples are decisions our own agents already make. An agent makes many small decisions between the big ones. On Solarpunk, the executive operations agent we built, a critic looks at every step's result and chooses continue, retry or escalate. On Skionis, our DevOps agent on live AWS, a template that will not come clean after a bounded number of revisions is escalated rather than refined forever.

Each of those is a judgment with a short list of possible answers, and in most agent harnesses the same large model that writes the plan also makes it. A generative model gives that judgment as text, which code then has to parse. No probability comes with it, so there is nothing to set a threshold against, and the same question can get a different answer on the next run. The check also costs a full model call, which adds up fast when it runs on every step of a long task.

This guide covers what Jev returns, the limits TypeSafe documents, where it sits in the loop, and which question type fits which decision. It then walks through the five steps in order, how Jev compares with OpenAI's Decisions API across a run of many small decisions, where an open weight model fits, and what stays in code. It ends on how a gate that runs calls on its own fits the autonomy levels in our guide to AI agent governance and the checks in our guide to AI agent permissions.

What is Jev, and what does it return?

TypeSafe calls Jev a System One model, built for fast, bounded judgments. It trains Jev with a method it calls RLCD, reinforcement learning for calibrated decisions, to return decisions and probabilities instead of generated text. The request has two parts: a state, which can be plain text or nested JSON, and the questions to ask about it. Jev answers every question in one request and returns a typed answer to each, so the output always fits the options you wrote. TypeSafe's documentation names four question types, and the choice between them is most of the design work.

A generative judge can return an option that does not exist, a paragraph where you asked for a label, or a confident answer with no measure of doubt. Jev cannot do any of those, because it has no free-form output. It can still be wrong, and a wrong answer arrives with a probability you can log and compare with what happened.

Do not put a threshold on that probability until you have checked it against your own outcomes. TypeSafe trains Jev to produce calibrated probabilities, and its own documentation tells you to plot confidence against accuracy on your data before relying on them.

Treat answers near a threshold as unsettled even then, because close probabilities flip. In TypeSafe's own consistency cookbook the chosen label changed on 2 of 8 questions across 15 repeated calls, sampled on 11 September 2026, where the probabilities were close.

We decide where Jev sits by its speed and price. If a check is fast and costs little, a harness can run it on every proposed tool call and every step of the loop, not only at the start and end of a task. TypeSafe's launch post gives 70 to 500 milliseconds end to end. As of October 2026 input costs $0.042 per million tokens and output is not charged, within a limit of 64k tokens per request and 32k per question. We start the sequence below with a shadow gate, so you see Jev's latency on your own traffic before any answer decides anything.

The table sets Jev beside the two things it usually replaces.

What limits does TypeSafe document for Jev?

TypeSafe publishes a list of the weak spots it knows about in Jev 1.13, last reviewed on 2 October 2026. Most of them change how the code around Jev should be built, so we treat the list as part of the design.

TypeSafe expects to fix many of these in later versions, which is a reason to pin the version you tested. An alias such as jev-latest moves when a new release ships, so answers can change with no change to your code. A threshold is only as good as the version it was tuned on.

On 27 October 2026 both jev-latest and jev-preview pointed to jev-1.14.0, released on 14 October, and the models page listed no separate preview build. On 22 October jev-latest still pointed to 1.13. Run each new version through the shadow gate before its answers decide anything.

Where does Jev sit in the agent loop?

Jev sits beside the loop and never in the path that changes anything. The generative model proposes, Jev answers questions about the proposal, and code decides what happens, with a person taking the cases code routes to them.

The line matters most at the tool runner, where a judgment turns into an action. When Jev picks a tool with a Choice question, the winner is only an input to the code that runs tools. That code still checks the caller's permission, the allowlist and the spend cap before anything executes.

If Jev could trigger a side effect directly, a wrong answer on unusual input would reach a production system with nothing in between. With execution in code, the worst outcome of a bad answer is a refused call or an unnecessary question to a person.

We built Skionis on the same rule: the agent is untrusted, and every step is either machine-checkable or human-reviewable, so "nothing in the system depends on the model being correct." A decision model is another model, so it gets the same treatment.

Code also builds the state Jev reads, because Jev judges only what it is given. Your code pulls the task, the proposed tool, its arguments, the user and the relevant history into named fields.

Jev is not fine-tuned on customer data, and the same weights serve every account, so whatever it needs to know about your business has to arrive in the state. As of October 2026 TypeSafe's models page lists text as the input, and images are an experimental opt-in.

Missing state can still get a confident answer, because Jev has no way to flag a field it never received unless a question asks about it. Our guide to a semantic layer for AI agents covers giving every agent the same business definitions, and those definitions are often most of the state Jev needs.

A spread-out answer is information, and code should act on it. When the probabilities spread across options instead of peaking on one, route the case to a person, ask the user, or fall back to the larger model.

Which question type fits which decision?

Most of the design work is choosing the type and writing the options. Solarpunk's critic is a clean example of a Choice: the state holds what the step was meant to achieve and what came back, and the options are continue, retry and escalate. A Score fits a question with an order, such as how far through the task the agent is. A Noul fits a single yes-or-no claim.

A Choice always names a winner. Asked which of forty tools fits a request, it returns one of the forty, even when no tool fits. For tool selection, pair it with a Noul that asks whether anything on the list fits. Read the Choice only when the answer is yes, because the Noul can say no and the Choice cannot. Adding a "none of the above" option is the obvious fix, and TypeSafe's Choice documentation warns it "may not work well in many use cases".

Split any question that asks two things. "Is this call safe and within the user's intent?" gives one probability for a combination nobody can act on, because a low score does not say which half failed. Jev answers all the questions in a request in parallel, and TypeSafe says adding questions barely changes the response time. Two questions also give two numbers to log, which you need when you set thresholds later.

In what order should Jev's answers gain influence?

We recommend five steps, and each gives Jev's answer more say over what the agent does. The order matters more than any single pattern, because each step produces the logs the next one is tuned against. Start the next step when the previous one has those logs, however long that takes.

This figure is the sequence we recommend, and the pacing depends on traffic and risk.

The shadow gate goes first because it changes nothing. It adds a check without removing one, the allowlist and permission checks stay in place, and it produces labelled traffic quickly.

Every logged score can be compared with what the agent did and with whether a person later reversed it. On the telecom marketing platform we are building agents for, the same caution applies to the agents themselves, with shadow mode and canary releases. A canary release sends a small share of traffic to a change first, before any agent acts more widely. There a person approves every agent action, and autonomy widens one action type at a time as the audit history supports it.

Threshold governance runs under all five steps and never finishes. Every threshold is a named constant in code, changed through review like any other code. A sample of the cases near each threshold goes to a person on a schedule, and a gate whose outcomes drift goes back one step. A gate that stays promoted after its evidence has gone stale keeps running calls on its own that a reviewer would now send to a person.

How does the tool-call gate work?

The gate asks, before each proposed call runs, whether it is safe to run without a person. Run it in shadow mode first, where Jev scores every proposed call and the score goes to the log. The agent behaves exactly as before, which makes this step safe to ship on a production agent.

After enough traffic the shadow logs show three things. You can see where the scores for routine reads cluster and where the scores for calls a person later reversed cluster, and how much traffic falls between them. Set the first thresholds from those three facts. Choosing thresholds before you have seen that distribution means picking numbers from intuition, and the first sign of a bad pick would be an incident.

The soft gate turns the scores into outcomes. A call with a high probability of being safe and a small possible impact runs on its own. A call in the middle band goes to a person, and a call with a low probability is refused. The deterministic checks run first, so a call outside the allowlist is refused without Jev being asked.

The thresholds of 0.40 and 0.90 and the impact cutoff are examples, not TypeSafe defaults, and yours should come from your own shadow logs.

The gate itself is a few lines of code, with the thresholds as named constants. The client call below is schematic, because SDK names change faster than the policy does.

# Thresholds are reviewed like code. Change them in a PR, never at runtime.
AUTO_RUN_MIN = 0.90
REFUSE_BELOW = 0.40
# A Score position runs 0 to 4 on five levels, so 2 is the middle level.
MAX_AUTO_BLAST_RADIUS = 2
 
def gate(call, user, task):
    if not policy.allows(user, call.tool, call.args):
        return log_and_return("refuse", call, reason="policy")
 
    answers = jev.evaluate(
        state={"task": task.summary, "tool": call.tool, "args": call.args, "user_role": user.role},
        questions=[
            noul("safe_without_person", "Is this call safe to run without a person reviewing it?"),
            score("blast_radius", "How much damage could this call do if it is wrong?", levels=5),
        ],
    )
    p_safe = answers["safe_without_person"].p_yes
    radius = answers["blast_radius"].score
 
    if call.tool in IRREVERSIBLE or radius > MAX_AUTO_BLAST_RADIUS:
        outcome = "ask_person"
    elif p_safe >= AUTO_RUN_MIN:
        outcome = "run"
    elif p_safe < REFUSE_BELOW:
        outcome = "refuse"
    else:
        outcome = "ask_person"
    return log_and_return(outcome, call, answers=answers)

In the sketch the proposed arguments sit in a named field of the state, and the question text is fixed. Tool arguments, web pages and model output are all text an attacker can reach. Pasted into the question, that text can change what Jev is being asked, which is prompt injection aimed at the judge. Do not treat the state as safe either, because steering text in the state is on TypeSafe's own list of things that can move the answer. The checks in code before Jev have to hold on their own.

An off-the-shelf integration does not remove that work. LangChain's AutoModeMiddleware uses Jev to check tool calls for risky actions and block them before the tool runs. It blocks and does not send a call to a person, so the middle band in the sketch is still yours to build. Whichever you use, the policy check before Jev and the thresholds after it stay in your code.

How should Jev choose between models?

Once the gate's logs are trusted, a router is the next step. A Choice over model tiers reads the task and the conversation so far and picks which model handles the next turn. Easy turns go to a smaller model, and planning and hard reasoning stay on the large one. The generative model still writes every word the user reads.

The failure to design against is a hard turn sent to a small model, which writes a plausible plan that is wrong, and nothing in the output shows that the routing caused it.

Make the large model the default whenever the router's confidence is low, so an uncertain decision costs more and does not risk a wrong plan. A model router earns its place only if the routed system matches the all-large-model system on the cases that matter. Check that with a fixed set of real tasks run both ways, comparing outcomes and not only final answers. Our guide to LLM evaluation covers building that set from real failures.

LangChain's ModelRouterMiddleware chooses the model from the latest user message, and the choice holds for the rest of that run, so a conversation that turns hard partway through stays on the model picked at the start. Test long runs as well as single turns.

The same Choice can route a request to a specialist subagent instead of a model tier. If every request has to pass through that router, put it before the main model runs, so the main model never has to decide whether to delegate. Our guide to multi-agent systems covers where that kind of routing pays.

How does Jev pick from a large tool catalogue?

This step takes tool selection out of the generative model's context. On Solarpunk, describing every tool in the prompt worked up to roughly thirty tools. Past that, the model started choosing plausible but wrong tools, and the failure was quiet: a confident result from the wrong system. We fixed it by not giving the model the registry at all. The agent queries the registry and sees a handful of relevant tool definitions, which carried it past a hundred tools.

Jev fits after that retrieval step. Code assembles a shortlist and asks a Choice over it, with a companion Noul asking whether the request needs a tool at all. When the Noul says no, the agent answers directly. When the Choice is unsure, the agent asks the user or searches again instead of guessing.

Jev picks the tool and does not write the arguments. Arguments are open-ended values such as an ID, a date range or a message body, and Jev can only choose among options you listed. Code or the generative model builds them against the chosen tool's schema, and the gate checks the finished call. Our guide to MCP prompts and agent playbooks covers shaping a catalogue the agent can search, and the one on MCP tools covers keeping it small. Jev cannot choose reliably between two tools whose descriptions overlap, so that catalogue work comes first.

How does Jev tell a stuck loop from finished work?

The last step puts supervisors on the loop itself. After each step, code sends Jev the recent history and three questions. A Noul asks whether the agent is looping, a Score asks how far it has got against a defined scale, and a second Noul asks whether the task is complete against its exit evidence.

A loop that repeats the same call with small changes shows up in the first two answers before a step limit would catch it. Keep the step limit anyway. On Solarpunk retries are bounded because "an agent that retries indefinitely against a broken vendor is worse than one that stops, because it burns cost and time while looking busy." A supervisor that misreads an unusual loop would leave it running, and only a hard limit in code guarantees it stops.

The completion question has to judge evidence, never the agent's own claim. Solarpunk compares the agent's claimed completion against the actual state of the target application, which is how it catches a run that claims success on work that never happened. Read that state back from the system of record in code, and let Jev's completion Noul judge what code read. Our guide to AI agent verification covers the expected state to check and how to read it back independently.

How does Jev compare with OpenAI's Decisions API?

We pick Jev for the decisions inside an agent loop, where the same kinds of question run on every step, and OpenAI's Decisions API when the agent already runs on OpenAI and every call has to sit under the same data terms. OpenAI released the Decisions API in beta on 6 October 2026 and made it generally available on 22 October 2026. It runs on GPT-6 Luna at POST /v1/decisions, takes text, images or JSON plus typed questions, and returns typed answers with probabilities and no generated text. It is OpenAI's closest match to a decision model.

The interfaces are close. The differences that change a pick are the cached price and which versions you can pin.

Score the two on your own shadow logs, because neither vendor gives one model-wide accuracy figure to compare. OpenAI's Decisions guide tells you to set thresholds from labelled examples from your application, and TypeSafe's tells you to plot confidence against accuracy on your data, so both point at the same check. Run one question set through both in shadow, compare each against what happened, and keep the one whose probabilities sit closer to the outcomes. Thresholds do not carry across, so tune them again after a switch.

Batch every independent question about one state into a single request, on either service. Jev reads the state once and evaluates every question against it. TypeSafe's models page sets no separate question cap, so the binding limits are 64k tokens for the request and 32k for any one question. In TypeSafe's parallel-questions cookbook, 13 questions about one long document cost 12.2 times less and came back 10.0 times faster in one call than in 13 sequential calls, with no change in the answers.

OpenAI's guide puts independent questions in one request too, and keeps a separate request when a later question depends on an earlier answer. As of the 22 October general availability a request holds up to 400 questions, up from 200 in the beta. One request reads the shared input once. A separate request for each question sends that input again.

TypeSafe's models page lists one input rate for Jev and no cached-token price, so we price every Jev token at $0.042 per million whatever repeats. On the Decisions API the cache covers shared input only. The reusable prefix has to reach 1,024 tokens, and question text does not count toward that minimum and is not cached.

A cache read costs $0.01 per million tokens. A cache write costs $0.125 per million for the 30-minute default and $0.25 per million for a 12-hour lifetime, the GPT-6 Luna rates on OpenAI's pricing page. Output tokens are not charged.

Put the standing context at the start of input and set an explicit breakpoint after it, so the new state is billed at $0.10 with no write charge. Leave the breakpoint at the end of an input that changes every step and the prefix misses, which puts the whole request on the $0.10 rate. A gap longer than the lifetime you paid for does the same thing to the next step.

GPT-6 Luna on the Responses API can cache the question text as well, because the questions live in the prompt rather than in a separate array. A repeated prefix of at least 1,024 tokens is cached by default. The first call writes it at 1.25 times the input rate, later calls read it at a tenth, and each read keeps the default cache for another 30 minutes. A 12-hour write costs 2.5 times the input rate.

Here is the arithmetic for an illustrative run of 40 steps, at the rates on the vendor pages as of 27 October 2026, for prompts under 272K tokens. Each step sends 4,000 input tokens: 2,000 of standing context, 1,000 of question text and 1,000 of new state.

The Decisions rows put the standing context in shared input with an explicit breakpoint after those 2,000 tokens, and they bill the questions and the new state at the uncached rate. The GPT-6 Luna row places the standing context and the question text before the breakpoint, assumes 50 output tokens a step, and assumes the cache stays warm.

The first Decisions step is 2,000 × $0.125 + 2,000 × $0.10 per million, the write on the standing context plus full rate on the rest. Each later step is 2,000 × $0.01 + 2,000 × $0.10 per million. The first GPT-6 Luna step is 3,000 × $0.125 + 1,000 × $0.10 + 50 × $0.50 per million. Each later step is 3,000 × $0.01 + 1,000 × $0.10 + 50 × $0.50 per million.

Jev needs no cache to reach $6.72 per 1,000 runs. With no reusable prefix the Decisions API costs $16.00, about 2.4 times Jev, which is $0.10 divided by $0.042. On this split a warm cache brings Decisions to $9.03, about 1.3 times Jev, because the 1,000 question tokens are rebilled every step.

If the question text is only a few hundred tokens and the standing context is most of the request, recompute before you pick on price. Cached input at $0.01 can come in under $0.042 once the cache is warm. GPT-6 Luna on the Responses API comes in just under Jev, at about $6.55, only while its cache is warm. A GPT-6 Luna answer is text the model generated, and the model page lists no logprobs, so there is no probability on each option to threshold.

Measure latency in the shadow gate for whichever you choose, because the two speed figures are on different bases: TypeSafe gives milliseconds end to end, and OpenAI gives a ratio to its own Responses API. On Jev, cost and latency both follow the number of requests, so fold questions into one call wherever they read the same state.

We default to Jev for gates, routing and loop checks inside an agent. Of the three services in the worked example, it has the lowest listed uncached input price with nothing to keep warm, a versioned model ID to pin each threshold to, Box for finding an element on a screenshot, and a published list of its own weak spots to build the code around.

We pick the Decisions API when the agent already runs on OpenAI and the decision has to fall under the same terms, such as Zero Data Retention, HIPAA eligibility or data residency in the US or Europe. It also fits a decision made inside a GPT-Live voice session, which OpenAI connected to Decisions on 15 October 2026.

Use it too when a long standing input repeats inside the cache lifetime and you have recomputed the bill, because the $0.01 read rate narrows the gap with Jev. GPT-6 Luna through the Responses API fits a step that also has to write something, such as tool arguments, and the decision in that step still goes to a decision model.

Keep the question set behind one function in your code, so a move from one service to the other changes the client and the thresholds and leaves every call site alone.

When does an open decision model fit?

Use that same function for open weights when the decision state cannot leave your network. Cloudflare released Clef and Clef-flash on 1 October 2026, and the weights are on Hugging Face under the Apache-2.0 license. Clef has 27 billion parameters and Clef-flash has 9 billion. Run a fresh shadow gate before either model decides a call. A request shape you can reuse does not carry a threshold with it.

On Workers AI, as of 27 October 2026, the model pages list Clef at $0.24 per million input tokens with a 65,536-token window, and Clef-flash at $0.038 per million input tokens with a 24,576-token window. Output is not charged, and a hosted request accepts 1 to 64 questions. On 9 October the Clef-flash hosted price moved from $0.090 to $0.038 and the hosted window moved from 64K tokens to 24,576. The changelog gives those same weights a window of up to 256K tokens when you run them yourself.

Call hosted Clef for a trial of the larger model. Its rate of $0.24 per million input tokens sits above Jev's $0.042 and above the Decisions API's uncached $0.10, so the case for Clef is the license and the weights. Clef-flash's hosted rate of $0.038 sits under Jev, and the 24,576-token window is the limit to check: a state inside Jev's 64k request cap can still be too long.

Price a self-hosted run on the GPUs you will use before you treat the download as the lower bill. Set the threshold from your own shadow logs, including where a score Cloudflare publishes disagrees with them.

What has to stay in code?

Everything that changes state or enforces a limit stays in code, however good Jev's answers become:

• permissions, checked against the user and the task when the call runs;
• allowlists of tools and argument ranges;
• spend caps and rate limits per user and per run;
• arithmetic, dates and any calculation with one right answer;
• step limits and timeouts on the loop;
• the thresholds, as named constants;
• building the state Jev reads.

Log every Jev call with the full probability distribution, not only the winning option, along with the state fields sent, the question versions, the versioned model ID that answered, the thresholds in force and the outcome the code chose. When someone later asks why a call ran without review, the answer is then a probability of 0.93 against a threshold of 0.90 on a named version of the question and the model. Our guide to an AI audit trail covers tying that record to the business case it belongs to.

Never let Jev be the only check on an action that cannot be undone, at any confidence. If the probabilities were perfectly calibrated, an answer of 0.99 would still be wrong once in a hundred. On a system that deletes accounts or sends payments at volume, that is a steady run of incidents nobody can reverse, so those actions go to a person or a deterministic rule.

How does a soft gate fit autonomy levels and permissions?

A soft gate that runs a class of calls on its own moves that class to the last level in our AI agent governance guide, act inside limits. That level asks for a check in code for each thing the approver was catching, the result confirmed in the target system, a tested way to undo it, and a named person who can stop it. A probability from Jev is not a check in code.

So a soft gate should run on its own only the calls whose mistakes are quick to find and easy to undo, and the rest stay with a person.

The permission model does not change. The permissions guide gives each change its own tool and checks the person, the target and the current state in code before the call, with the credential held where the model cannot read it. Jev's answer can be one input to that check. It can say a call looks routine, and it cannot grant a permission the caller does not hold.

Common questions

What is TypeSafe's Jev?#

Jev is a decision model from TypeSafe AI, announced on 15 September 2026 as the company's first public model, then in early access. As of 27 October 2026 jev-latest points at jev-1.14.0, the stable release on the models page. It takes a state and typed questions, which TypeSafe's documentation calls Choice, Score, Noul and Box, and returns an answer to each with a probability for every option. It does not write text, so it cannot return an option outside the ones you defined.

Is Jev a large language model?#

Not in the usual sense. Jev does not generate text, and TypeSafe trains it with a method it calls RLCD, reinforcement learning for calibrated decisions, to return a typed answer and a probability for each option instead. LangChain's integration post describes it as "not a traditional LLM". In an agent it works beside the generative model, which still writes the plans, the tool arguments and the replies a user reads.

How is Jev different from using an LLM as a judge?#

An LLM judge writes text that code then parses, and no probability comes with it. Jev returns one option per question from a list you wrote, with a probability for each, which gives code a number to threshold and log. TypeSafe trains Jev for calibrated probabilities and its documentation recommends checking confidence against accuracy on your own data, which the shadow gate does.

Can Jev replace permission checks on agent tool calls?#

No. Jev can advise on whether a call looks safe, and code still enforces permissions, allowlists and spend caps before anything runs. A call outside policy should be refused without asking Jev at all. For irreversible actions such as deleting an account or sending a payment, a person or a deterministic rule makes the final decision at any Jev confidence.

Where should a team start with Jev in an existing agent?#

Start with a shadow gate on the agent's existing tool calls. Jev scores every proposed call, the score goes to the log, and nothing is blocked, so the agent's behaviour does not change. After enough traffic the logs show where routine calls and later-reversed calls sit, and that distribution sets the thresholds for the soft gate that follows.

How should thresholds for a Jev gate be set?#

Set them from your own shadow logs, never from a vendor default or an example. Compare the scores of routine calls with the scores of calls a person later reversed, and set the run and refuse thresholds around them. Keep the thresholds as named constants in code, send a sample of the cases near them to a person on a schedule, and move the gate back a step if its outcomes drift.

Does Jev make agents faster or lower cost?#

TypeSafe reports 70 to 500 milliseconds per request and input pricing of $0.042 per million tokens as of October 2026. Any saving comes from moving small decisions such as gates, routing and progress checks off the large model. Planning and writing stay on the generative model, so the effect on a whole run depends on how many of its steps were judgments.

How does Jev compare with OpenAI's Decisions API?#

Both take typed questions and return typed answers with a probability for each option, and neither writes text. Jev costs $0.042 per million input tokens, and the models page lists no cache discount. The Decisions API, generally available since 22 October 2026 on GPT-6 Luna, costs $0.10 per million uncached input tokens and $0.01 for cached input, and output is not charged.

Question text sits outside that cache, so with no warm prefix Jev costs about 2.4 times less, and a long cached prefix narrows the gap. We pick the Decisions API when the agent already runs on OpenAI under its data terms.

When does an open decision model fit instead of a hosted API?#

Use Cloudflare's Clef or Clef-flash when the state cannot leave your network and you can run the weights. Cloudflare released both on 1 October 2026 under the Apache-2.0 license, Clef at 27 billion parameters and Clef-flash at 9 billion. On Workers AI as of 27 October 2026, Clef is $0.24 per million input tokens and Clef-flash is $0.038, with output not charged. We take the weights for that boundary, and we still start them in the shadow gate.

Further reading

• TypeSafe, Introducing System One models and Jev, 15 September 2026. The launch post, with the vendor's latency, speed and pricing figures.
• TypeSafe documentation: models and pricing, question types, Jev 1.13 weak spots and the consistency cookbook and the parallel-questions cookbook. Checked 27 October 2026.
• OpenAI, Build more responsive apps with the Decisions API, 22 October 2026. General availability, the $0.10 and $0.01 rates, the 400-question limit, and the customer accounts named there.
• OpenAI documentation: the Decisions API guide, the GPT-6 Luna model page, pricing, prompt caching and the changelog. Checked 27 October 2026. The interface, rates and caching rules behind the worked example.
• Cloudflare, Introducing Clef, 1 October 2026, plus the Workers AI pages for Clef and Clef-flash and the 9 October changelog. Sizes, license, hosted prices and context windows. The weights are Clef and Clef-flash on Hugging Face.
• Sydney Runkle and Hunter Lovell, LangChain, Building a harness with Jev, 17 September 2026. The auto-mode and model-router middleware.
• Our guide to AI agent governance. The evidence a soft gate needs before it runs calls on its own.
• Our guide to AI agent permissions. The check in code that Jev can inform and never replace.
• Our guide to an AI audit trail. Where the full probability distribution for each gate belongs.
• Our guide to AI agent verification. The evidence a completion check should judge.
• Our guides to MCP prompts and agent playbooks and MCP tools. The catalogue Jev selects from.
• Our guide to a semantic layer for AI agents. The definitions that make up much of the state Jev reads.
• Our guide to LLM evaluation. Measuring a router or gate against real tasks before it goes live.
• Solarpunk build notes. Retrieval before tool calls, the critic, and bounded retry.