Introducing Sys1

An agent, a fast model, and a language that remembers

Sys1 is one part of a three-part system. The agent is the large language model you already use. It plans, writes code, and works through the problems that need deliberate reasoning.

Jev handles the reflexes. A question with a declared answer shape (yes or no, a choice among named options, or a score) comes back as probabilities your code can act on, not a paragraph to parse. Sys1 routes the question, checks the answer, and hands the agent a result it can use in one step.

ALGAL is a programming language for agent programs. An ALGAL program can wait for a person’s approval, resume after a crash, and replay what it did from its receipts. A procedure that proves itself on declared test cases is kept with its evidence and reused. That is what lets a harness get better with use instead of starting from scratch every session.

Sys1 already works this way on a small scale. When a review turns up a real mistake, you can draft a repository rule from it, and every later review checks for it. Feedback on each finding is kept, and reviews of unchanged code are reused instead of paid for twice. ALGAL takes the same idea further, to whole procedures. Today, Sys1 and ALGAL are separate open-source projects that call the same Jev decision API.

What a decision looks like

In TypeSafe’s System One approach, an application supplies state and questions, and a model returns structured decisions with probabilities. The caller defines what the possible answers mean. A question can ask whether a condition holds, choose among named alternatives, or score evidence against ordered criteria.

Jev is TypeSafe’s hosted model for those decisions. Sys1 is the layer around the call. It offers a Jev-compatible API, picks the backend you configured, checks the answer against the question that was asked, and reports which backend answered.

That distinction matters when choosing where to run a decision. Sys1 can send a request to hosted Jev, an installed Qwen model, or a compatible HTTP service you configure. Enabling Jev selects hosted-only routing. An outage returns an error instead of silently substituting a local model. The local adapter approximates the answer format with generic Qwen models; shared JSON shapes do not establish equal quality or calibration.

The API calls its three answer types noul, choice, and score. These names describe the data your code receives. Validation can reject an unknown choice or a malformed probability, but the caller still needs evidence that the model makes useful judgments on its own tasks. The Jev setup guide explains the connection, and the runtime design traces the request.

Start with the evidence an agent can inspect

The review workflow begins with a Git change and a rule. A repository might require a login path to finish storing a token before reporting success. A review question can bring that requirement together with the selected diff. The answer points the agent toward a candidate to investigate in the implementation and its tests.

The sys1-review skill supplies the sequence: preview a checkpoint, inspect findings, and record whether each was useful, incorrect, or unverifiable. You choose the paths and rules. The bundled rules cover newly empty catch blocks and removed test assertions in JavaScript and TypeScript; broader language or policy coverage needs suitable rules and examples.

This workflow also keeps costs down. A preview makes no model calls. An unchanged batch is reused for up to 24 hours instead of being paid for again, and findings the agent has already seen stay out of new output. A checkpoint reports skipped evidence, so a partial review is visible. When a repair changes the evidence, a fresh checkpoint evaluates that change; a changed file alone does not establish that a reported problem was fixed.

The separate sys1-verify skill checks a proposed completion message. Git state can contradict a claim that all work was committed or pushed. A linked pull request can contradict a claimed merge. A fetched page can be compared with a claim that a change is live. Missing evidence stays unverifiable. File or stdin input works with any agent; check-command results are available through local Devin transcript discovery.

Both skills install project instructions without adding automatic hooks or activating a backend. Their usefulness depends on the repository’s rules and the selected model. An earlier review experiment missed its reproduced defect and flagged two of five control hunks, which is why findings require investigation and ordinary tests remain part of the work.

The trial points to one next experiment

Sys1 also includes source-checkout profiles for failure triage, excerpt relevance, and claim support. A profile fixes the questions and model route while accepting new input. On September 28, 2026, Jev 1.13.0 received 48 synthetic examples across these profiles, each submitted once. It returned 45 valid answers matching the authored labels and three errors.

Claim support is the most useful next candidate from this small screen. Its baseline predicted insufficient evidence on every example and matched six labels, so this comparison leaves stronger entailment models and better rules untested. The profile judges a claim against the supplied excerpt; it does not verify that the excerpt itself is true.

The relevance errors also matter. Two responses reached the gateway with provider HTTP 200 and failed response validation. The first failure was a gateway HTTP 502 whose underlying cause was not retained. The original failed request was never retried; a continuation submitted only the 30 previously unsubmitted cases. These observations test the profiles and evaluator, not the installed review skill or production accuracy.

This trial measured answers, not savings. Per-decision cost and latency come from TypeSafe’s published figures, and the separate compact check output skill returned 35% less text across 563 real test and build runs. Nobody has yet measured how many tokens a whole agent task saves; that is the next number worth getting.

The profile evaluator makes a similar comparison available from a source checkout. It validates examples offline before you opt into calls, then records coverage, matched labels, errors, timing, and routes. A next trial can preserve the first result, use stronger baselines, and measure how the decision changes the completed task.