HarnessRouter Open-Sources System One Harness: One Typed Decision per Step

Launch

System One Harness is open source

We have open-sourced System One Harness under Apache 2.0. It drives a live environment one decision at a time: a few hundred milliseconds and a fraction of a cent per step, with the probability the model put on that decision attached to it, so the loop acts while confidence is high and hands over the moment it is not.

A System One model is a decision function. The name is Kahneman's: fast, focused judgments rather than deliberation. You send it a state and a set of typed questions, and it answers all of them in one request, evaluated in parallel rather than generated one token after another. A choice or a score comes back as a value with a probability across the options; a yes or no comes back as a probability. TypeSafe, an AI lab, calls Jev its first public model in this category. TypeSafe describes Jev's outputs as typed decisions with calibrated probabilities, and prices input at $42 per billion tokens, which works out to $0.042 per million, with no charge for output.

That model needs a loop built for typed decisions rather than generated text. Something has to hold the state, enumerate what can be done right now, ask the questions, weigh the probabilities that come back, execute the chosen action against the environment, and stop for a reason it can name. That is the harness, and it is what we released.

The inversion

The harness offers the actions; the model picks one

A text harness reaches its actions through generation. The model produces a candidate tool call, and the harness parses and validates it. Strict schema enforcement has closed much of that gap on the providers that offer it, but where a harness still has to check and retry what the model wrote, bridging prose and structure costs parsing, validation and repair logic.

With a decision model the gap does not exist, because the structure is sent first. At every step the controller compiles the current action space into questions: which action to take next as a choice among the actions that are feasible at this moment, every parameter of every feasible action as its own typed question, and a yes or no on whether the goal is already met. The model answers all of them in one request, and the controller reads only the answers belonging to the action it chose.

This has a consequence that sounds small and is not. An action that cannot be taken right now is not offered at all, rather than offered with a rule attached telling the model not to take it. A candidate list that is empty removes its action from the step. Fewer constraints have to be stated as rules the model could ignore, because an action that is not on offer cannot be chosen. What is on offer is still only as accurate as what the environment reports.

• A parameter is a fixed choice, a choice drawn from a list the environment enumerates each step, a yes or no flag, or a score on a named legend.
• A parameter that is free text is refused at load time. A System One model cannot generate text, and the harness will not pretend otherwise by asking it to.
• For an optional parameter the controller asks a second question, whether the value is stated at all, and applies the parameter's default when the answer is no.

Confidence

The probability is a control surface, not a decoration

Because every answer arrives with a probability, the harness can set a bar before it acts. Each action carries a risk level, and the weakest judgment a step depends on, the action's own probability and every parameter's, has to clear the threshold for that level. Reading costs little and a destructive action cannot be taken back, so they do not answer to the same number:

An action space can set its own numbers; the built-in example runs a little looser, at 0.6 for write and 0.8 for destructive.

A step that fails the gate executes nothing and is recorded with the full distribution the model gave. Outside real-time environments, three refusals in a row end the run as no_confident_action; where the world moves on its own, a refusal is treated as a tick with the last action standing. The model can also choose to escalate, which ends the run as escalation_requested and means nothing on offer fits and a person or a larger model should look.

During development of the built-in environment this fired for real. The order desk reported that a parcel was packed, but never said that it was not yet shipped. The model therefore put about a tenth of its probability on the order already being finished, and its confidence on the shipping action settled right on the destructive threshold. Two runs in five stopped rather than ship. The fix was to make the environment state the goal's own predicates outright, including the false ones, not to lower the gate.

That is the behaviour we want from an automation layer. A recorded refusal is a visible handover point, which is worth more than a run that ends in a confident sentence and a shipped parcel.

What it can drive

An environment is any process, any MCP server, or a web page

The narrow interface is a process that speaks one JSON object per line: reset, observe, execute, close. Anything that can be started and can answer those four is an environment, which keeps simulators, internal systems and real surfaces on the same footing.

An MCP server that follows the state-definition convention needs no declaration file at all. The harness lists the server's tools once and compiles them into actions, reading the read-only and destructive annotations as risk levels, an enum as a choice, a boolean as a flag, a small bounded integer as a score. Those annotations are advisory: the protocol tells clients to treat them as untrusted unless the server is, so on a server you do not control the risk levels are a starting point to review rather than a safety boundary to lean on. A tool whose parameters cannot be answered by a decision model, one taking a free string, an array or an object, is reported as unsupported with the reason rather than dropped in silence.

A web page becomes an environment through the open-source Browser Use project, which reads the page into an indexed representation and executes by index over the Chrome DevTools Protocol. Numbered controls become candidate lists, and the text a form needs is supplied by you as named values that the model selects by name and never writes.

Numbers

What we measured, and what the numbers do not show

The repository ships a benchmark and the raw rows behind it. It covers three built-in order-desk scenarios with five runs each, all fifteen run against the live model typesafe/jev-1.13-20260917 on 2026-09-19. The success bar is the scenario's own goal being met, and cost is input tokens at TypeSafe's published price.

Across all fifteen runs no step was refused, every run ended because the environment declared itself terminal, and the slowest single step was 403 ms. A whole run costs a fraction of a cent.

On a booking form driven through the browser, measured the same day, the model completed the task in four actions in all three runs, between 4.6 and 5.2 seconds each, at 150 to 315 ms per model step.

Here is what those numbers do not show. The order desk is small, deterministic, and its actions are described plainly, so a clean sweep shows the loop, the compiler and the gate working together on these scenarios and the model reading a clear state well. It does not establish performance on ambiguous state, arithmetic, dates, or long irrelevant context, which TypeSafe documents as weak spots. The benchmark is a floor to keep, not a ceiling reached. The repository also records one boundary of the current browser adapter: a page that draws itself on a canvas gives a DOM observation almost nothing to read, and on one such page the loop stopped when the observation stopped changing.

The contract

A model that cannot write still speaks the same protocol

The harness serves itself over the Unified Harness Protocol, and the conformance suite that ships with the protocol reports 40 of 40 core checks passing on 2026-09-19. Each executed action becomes a function call item and its output, a refused or finishing step becomes a reasoning item carrying the distribution and the gate's verdict, the provider's usage is summed into the usage field, and the way the loop ended maps onto the protocol's own completion states. The extended and full classes are not claimed.

This is the part worth pausing on. Everything underneath is unfamiliar: the model is not autoregressive, it writes no prose for anyone to read, it accepts no sampling parameters, and what it returns is a probability distribution. None of that changes the shape of the contract. A client working against the protocol's core surface can drive this harness the same way it drives a text one, and the distributions and gate verdicts are there to read in the reasoning items when it wants them.

HarnessRouter is the world's first unified interface for agent harnesses. That interface is the full product-backend contract: task execution, sessions, files, streaming and returned results, across complete harnesses from different vendors. This is the case it was worth standardising for. The layer below can change shape entirely, and a product built on the same core surface keeps its integration.

Next

Where this goes

The next milestone is a systemone base inside HarnessRouter, so this loop sits beside the harnesses we already run. In that design the harness configuration's MCP servers would be the environment, every action an item in the task stream, and a run that ends in escalation or in a refused gate would open a door for a person or for a larger harness to take over.

After that: skills loaded as an action, so a capped state carries only the instructions a step actually needs; a browser extension that is a plain protocol client; and the extended conformance class.

The repository is public, the license is Apache 2.0, and the design document carries the measurements the design rests on, including the ones that went against the first guess.

FAQ

System One models and this harness

Keep reading

Related reading

• What is an agent harness?
• Agent harness vs model: which one decides quality?
• The agent harness layer