Jev for Codex: Introducing Qualixar Jev Control v1.1.1 and Policy Mode

How TypeSafe's System One model can give coding agents a selective decision layer for routing, ranking, triage and evidence checks before they spend expensive reasoning on the wrong path.

Release: Qualixar Jev Control for Codex v1.1.1
Repository: https://github.com/qualixar/jev-codex-workbench
TypeSafe documentation: https://docs.typesafe.ai/
Live evidence in this article: TypeSafe direct, resolved model jev-1.13.0
Status: Independent Qualixar open-source integration; not an official TypeSafe or OpenAI product.

I got early access to TypeSafe's Jev through DeepSearch, with live API access.

I expected another model endpoint. What interested me was almost the opposite.

Jev is not designed to be the model that writes the pull request, explains the architecture, or spends ten minutes reasoning through a repository. TypeSafe describes Jev as its flagship System One model: you give it state and small, typed questions, and it returns structured judgments that software can consume directly. No prose needs to be parsed back into a decision. The core primitives are Choice, Score, and Noul. (TypeSafe introduction, System One, Primitives)

That distinction matters for coding agents.

A coding agent does not spend all of its budget writing code. It spends a large part of a trace deciding what to inspect, what to ignore, which tool to use, which files deserve deeper reading, which tests are relevant, whether a claim is supported, whether a completion claim has enough evidence, and whether a piece of information belongs in durable memory.

Those are not all generation problems. Many are bounded semantic decision problems.

That is the architectural opportunity behind Qualixar Jev Control for Codex v1.1.1: keep Codex as the coding and reasoning agent, but give it a selective Jev decision layer for the narrow judgments that do not need another full reasoning pass.

---

First: what is TypeSafe Jev?

Traditional LLM APIs are optimized to generate text. Even when we ask them to classify, rank or verify something, we normally prompt for text or JSON, then parse and validate the response.

TypeSafe is pursuing a different abstraction.

Jev evaluates typed questions against a shared state and returns constrained values plus probabilities. TypeSafe's documentation describes three primitives:

Primitive	The question it answers	Structured output
Choice	Which option from a known set?	chosen option, probability distribution, confidence
Score	Which level on an ordered rubric?	score, probability distribution, confidence
Noul	Is this statement true?	probability of yes from 0 to 1

The important design rule is atomicity. TypeSafe recommends asking one focused judgment per question and composing broader logic in normal code rather than asking the model to perform a long chain of reasoning inside one prompt. (Primitives)

That gives software architects a different mental model:

Generative model
    state + instruction
        -> generated text
        -> parse / interpret
        -> application decision

System One / Jev
    state + typed questions
        -> typed probabilities / values
        -> deterministic application policy

TypeSafe currently lists Jev 1.13.0 as the stable Jev 1.13 model. Its published pricing is $0.042 per million input tokens, with output tokens free. The current documentation lists a 64k-token request context, with text input only. (TypeSafe models)

That price is not, by itself, the reason I built the integration. The more interesting property is that a bounded decision model can sit in front of more expensive work.

What is Jev actually used for?

If you read only the API reference, it is easy to underestimate Jev. The primitives are small, but TypeSafe's own architecture guides show how they compose into larger systems. The strongest patterns are useful far beyond one classification call.

Intent routing

Classify an incoming request first, then route it to deterministic code, a specialist model, or a human. TypeSafe's official Intent Routing guide explicitly argues against sending every request through an expensive LLM when a cheaper classifier can choose the right handler first. (Intent Routing)

Parallel semantic checks

Ask many independent questions against the same state in one call. TypeSafe evaluates the questions independently, so a document can be checked across many dimensions without resending the full state for every question. (Parallel Questions)

Confidence-gated escalation

Choice and Score expose distributions and confidence; Noul exposes a direct probability of yes. That means uncertainty can be a first-class routing signal: accept the clear cases, escalate the ambiguous ones, and preserve the underlying probability instead of hiding it behind prose. TypeSafe groups this under its official Confidence-Gated Routing pattern. (TypeSafe Patterns)

Composite judgment

A broad decision can be decomposed into independent dimensions and recombined in ordinary code. This is particularly valuable when the weighting is business logic: the model judges the dimensions; the application owns the coefficients and thresholds. (TypeSafe Patterns)

Cheap-model verification and cascades

TypeSafe's SDE Cascade cookbook demonstrates another architecture: do the first extraction with a cheaper model, verify individual fields with Jev Noul questions, and escalate to a more expensive reasoning model only when a verifier signal fires. The point is not the specific extraction task; the reusable idea is cheap attempt → typed semantic verification → selective escalation. (SDE Cascade)

Speculative fan-out

When the shared state is expensive and the possible checks are cheap, ask more candidate questions up front and let code decide which answers matter. TypeSafe lists Speculative Fan-Out as a cost/speed pattern precisely because the state is ingested once while the questions are evaluated independently. (TypeSafe Patterns)

This is why I call Jev a decision primitive, not a smaller chatbot. Its value is highest when the application already knows the answer shape and needs a semantic judgment to choose among bounded outcomes.

---

The useful pairing is Jev + Codex, not Jev instead of Codex

Jev does not generate code. TypeSafe explicitly documents generation as a case where you should use a generative model instead. It also recommends keeping arithmetic and date comparisons in ordinary code. (Jev 1.13 jaggedness)

That is a feature of the architecture, not a limitation to hide.

A modern coding workflow benefits from separating two kinds of intelligence:

System One: fast bounded judgment

Examples:

• Which of these files is most relevant to the task?
• Which reviewed tool or skill is the best fit?
• Does this supplied evidence support the claim?
• Which tests are most likely to exercise this change?
• Does this candidate fact belong in durable memory?

System Two: deliberate reasoning and construction

Examples:

• understand the task across the repository;
• design the implementation;
• write and refactor code;
• execute tools;
• diagnose failures;
• iterate against tests and acceptance evidence.

For us, Codex remains the System Two coding agent. Jev becomes a narrow System One decision primitive inside the workflow.

This is also consistent with TypeSafe's own positioning. Its official agent skill is a drop-in skill for Claude Code, Codex, and other agent environments, and its examples encourage developers to find places where intelligent judgment can replace brittle parsing or overly complex decision code. (TypeSafe Agent Skill)

The official TypeSafe skill and Qualixar Jev Control solve different problems:

• TypeSafe's skill teaches the coding agent the TypeSafe API, primitives, patterns and best practices.
• Qualixar Jev Control is an executable Codex integration: a plugin, local policy layer, reviewed workflow catalog, gated live adapter, validation layer and evidence mechanism.

They are complementary.

---

Why a decision layer can change the economics of coding agents

This is the part that needs precise language.

Qualixar Jev Control is designed to save Codex tokens. We are not publishing a universal savings percentage yet.

The mechanism is straightforward.

Imagine a repository task with 40 plausible files. A coding agent can load large sections of those files and let a premium reasoning model decide which ones matter. Or it can first run a narrow relevance decision on a reviewed candidate list, then spend the expensive context window on the most promising subset.

The same pattern applies to:

• selecting tests before loading multiple test suites;
• routing to the correct tool or skill before reading every tool description;
• ranking research sources before deep reading;
• filtering context before it enters the primary reasoning trace;
• classifying issues and incidents before invoking a larger workflow.

This is not magic token compression. It is earlier selection.

TypeSafe documents the same general economic pattern in its Intent Routing architecture: classify first, then invoke deterministic logic, a specialist LLM, or a human only when that handler is needed. (Intent Routing)

TypeSafe also publishes a useful batching example. In its Parallel Questions cookbook, 13 questions over the same ~54,000-character GDPR article were evaluated in one request versus 13 separate requests. TypeSafe reports the batched version at $0.000497 and 0.27s, versus $0.006090 and 2.71s for the 13 sequential single-question calls — 12.2x cheaper and 10.0x faster for that specific vendor benchmark. (Parallel Questions cookbook)

That is TypeSafe's benchmark, not a Qualixar Codex benchmark. It demonstrates why shared-state atomic decisions can have attractive economics. It does not prove that our Codex integration saves 12.2x, 50%, or any other fixed percentage.

For Qualixar, the next honest measurement is a controlled Policy Mode OFF vs ON benchmark over the same coding tasks, recording Codex-side input/output tokens, tool calls, wall time, retries and acceptance results.

Until that exists, the public claim is the mechanism: decide what deserves context before paying to expand context.

---

What changed in Qualixar Jev Control v1.1.1

Version 1.1.0 established the adapter, 20 workflows, fixture system, TypeSafe-direct live path, workspace-bound grants, validation and receipts.

v1.1.1 changes the operating model. It adds Jev Policy Mode.

Policy Mode is a deterministic local control plane that evaluates the task intent before Codex expands context or starts governed tool work.

It returns one of four outcomes:

Outcome	Meaning
SKIP	No bounded Jev decision was identified. Continue with Codex.
SUGGEST	In the default assist mode, a specific Jev workflow could reduce unnecessary exploration.
REQUIRE	In opt-in enforce mode, the matching live Jev evaluation must complete before governed Bash or file-edit use can proceed.
BLOCK	Sensitive material was detected locally and should not be sent to the external Jev provider.

The classifier itself makes no provider request and stores no prompt text.

Assist is the default

Policy Mode ships on in assist mode.

That is deliberate. The objective is not to put a remote model in front of every Codex turn. A deterministic file read, arithmetic operation, known test command or unmatched task should not need a Jev call simply because the plugin is installed.

If the local policy classifier recognizes one of the bounded semantic patterns, it can suggest the corresponding workflow. Codex can then use the Jev decision where it is useful.

Enforce is opt-in

enforce is for teams that want the matched semantic decision to become a prerequisite before certain governed tools continue.

Three Codex lifecycle hooks make that possible:

UserPromptSubmit
    -> classify locally
    -> create a pending request only when enforcement is required

PreToolUse
    -> if the current turn is governed and still pending,
       hold Bash / file-edit use

PostToolUse
    -> accept only the matching qualifying jev_evaluate receipt
    -> satisfy the per-turn gate

v1.1.1 also hardens what counts as a satisfying result. A failed evaluation, synthetic receipt, unrelated tool that merely happens to be named jev_evaluate, cross-workspace receipt, or mismatched request does not satisfy the enforcement gate.

The current implementation binds the policy ledger to the canonical Git workspace, repository revision, case, classification and generated request ID.

That is a much stronger integration than simply adding another MCP method.

---

Seven tools, but only one makes a live Jev request

v1.1.1 exposes seven MCP tools to Codex:

1. jev_health - inspect local readiness without exposing credentials.
2. jev_policy_status - inspect the configured Policy Mode and boundaries.
3. jev_policy_check - run the local no-network intent classifier.
4. jev_catalog - list the 20 reviewed decision workflows.
5. jev_describe - inspect a workflow's state contract, questions and thresholds.
6. jev_run_fixture - run a clearly labelled synthetic fixture with no model inference.
7. jev_evaluate - perform the actual live evaluation when the required workspace grant exists.

This matters because “Jev is available in Codex” does not mean “every Codex message becomes a Jev API call.”

The plugin can inspect, route and rehearse locally. The live call is a separate path.

---

The 20 workflows: from routing to memory admission

The first release ships 20 bounded decisions. I find it more useful to think about them as five families.

1. Route

• skill routing;
• task routing;
• tool selection;
• worker routing.

These decisions answer: where should this work go?

2. Focus

• file ranking;
• context sieve;
• test selection;
• research ranking.

These decisions answer: what deserves deeper attention? This is the family with the most obvious direct relationship to context economics.

3. Verify

• claim verification;
• completion gate;
• patch review;
• semantic lint.

These decisions ask whether the supplied evidence supports a bounded proposition. Deterministic checks still remain deterministic: for example, the completion workflow can block if test/lint evidence, executed-test count, revision binding or freshness is missing even if a semantic judgment looks favorable.

4. Triage

• injection triage;
• failure classification;
• issue triage;
• incident triage.

These turn ambiguous incoming material into a bounded routing result.

5. Govern

• documentation drift;
• security-review routing;
• support triage;
• memory admission.

These apply semantic judgment at system boundaries where “keep everything” or “let the large model decide later” is often the wrong default.

Every workflow includes nominal, uncertain and adversarial fixture contracts. That gives 60 offline scenarios for deterministic local branching and contract behavior. Those fixtures are not Jev inference and are not an accuracy benchmark.

---

The live TypeSafe-direct architecture

For this launch, the live evidence is deliberately limited to the path we actually verified: TypeSafe direct with resolved model jev-1.13.0.

OpenRouter support exists in the codebase, but I am not using OpenRouter results to make the claims in this article.

The live path is:

Codex
  -> reviewed workflow contract
  -> data screening + typed question construction
  -> workspace/revision/provider/time/call-budget grant
  -> TypeSafe System One API
  -> exact model + schema validation
  -> deterministic local policy
  -> content-addressed receipt
  -> Codex continues with the result

The current adapter uses a fixed TypeSafe direct endpoint. The model ID is pinned in the provider profile, and the response model is checked before the typed answers are accepted.

Choice and Score probability distributions are validated. Score is checked against its probability-weighted value. Noul remains a probability-of-yes primitive rather than receiving a fabricated confidence value.

Provider HTTP error bodies are suppressed rather than echoed back into the agent context, because an error body can contain submitted material. Ambiguous transport failures are not automatically retried because the provider may already have processed the request.

These details are not the launch headline, but they matter once this stops being a demo and becomes infrastructure.

---

Why the grant exists

A locally stored API key proves that a machine can authenticate to a provider. It does not answer a more important question:

Which repository, at which revision, is authorized to send which reviewed request right now?

Qualixar Jev Control therefore separates credentials from live authority.

A live grant is bounded by:

• canonical workspace identity;
• Git revision fingerprint;
• selected provider and provider-profile hash;
• expiry;
• finite HTTP-attempt budget.

For custom state, the grant narrows further to the case, classification, request ID and request hash.

A change to the repository revision or provider profile invalidates the old authority.

Again, this is not the reason to click on the project. The reason is the Jev + Codex decision architecture. But if we want that architecture to survive outside a toy repository, authority and evidence have to be explicit.

---

What we verified

There are three different evidence classes and they should not be collapsed into one headline.

A. Offline contract evidence

The project contains 20 executable workflows and 60 nominal/uncertain/adversarial fixture contracts. These test the local application behavior. They do not demonstrate Jev model accuracy.

B. Live TypeSafe-direct evidence

A nominal live run completed all 20 workflows through TypeSafe direct with resolved model jev-1.13.0.

The recorded nominal outcomes were:

• 15 RECOMMEND
• 5 REVIEW

Every result kept execution_authorized=false because the model result is a decision input, not an execution permission.

The v1.1.1 release notes also record a request-bound live review of the Policy Mode implementation returning REVIEW across three runs. A REVIEW is a valid system outcome; this integration does not rewrite uncertainty into success.

C. Release verification

The v1.1.1 GitHub release records pre-release verification of:

• 170 Python tests passed, with one managed loopback skip;
• 60/60 offline fixture contracts passed;
• 287 package files verified;
• plugin and skill validation passed;
• all 20 live workflows completed through TypeSafe direct with jev-1.13.0.

There is one publication caveat worth making explicit. At the time of writing, the public GitHub Actions matrix for the tagged commit is red. The hosted runner logs discover 170 tests and show one installer test error because the runner does not have the Codex CLI installed (CODEX_CLI_REQUIRED). The Policy Mode tests and the 60 fixture tests shown in that run pass before the environment error. I am therefore not describing the current hosted CI matrix as green. (v1.1.1 release, current Actions run)

That distinction is important. Evidence-led engineering means publishing what the evidence proves, not what would make the strongest launch sentence.

---

What we are deliberately not claiming

This release does not establish:

• a universal Codex token-saving percentage;
• a universal cost-saving percentage;
• superior accuracy over a coding model or another classifier;
• a security or compliance certification;
• enterprise production adoption;
• guaranteed prompt-injection detection;
• automatic interception of every Codex turn.

TypeSafe itself publishes Jev's current jagged edges. Jev 1.13 can struggle with numeric precision, date/time comparison, indirection, large irrelevant state and adversarial content; TypeSafe recommends keeping arithmetic in code, filtering state, writing precise questions and testing edge cases. (Jev 1.13 jaggedness)

Our local data screening is a useful boundary check, not an enterprise DLP system. Local owner-only credential files are not a hardware-backed secret vault. A hostile process running as the same OS user is outside the protection offered by Unix file permissions alone.

Those are engineering boundaries, not footnotes to hide.

---

Why I think this pattern matters

The coding-model race is making the top model more capable every quarter. That does not imply the best architecture is to send every micro-decision to the most capable model with the maximum context available.

At scale, agent economics become an orchestration problem:

• what deserves the premium model;
• what can be determined locally;
• what can be routed by a cheaper specialized primitive;
• what evidence should enter context;
• when uncertainty should trigger escalation;
• which decisions need a receipt before the workflow continues.

TypeSafe's System One idea is interesting because it makes judgment itself a composable primitive.

Qualixar Jev Control is our attempt to turn that primitive into a practical Codex architecture.

Not Jev instead of Codex.

Jev for fast bounded judgment. Codex for deep reasoning and construction. Deterministic code for the rules that should never have been probabilistic in the first place.

That division of labor is the part I expect to matter long after this release number changes.

---

Try Qualixar Jev Control v1.1.1

Prerequisites: Python 3.11+ and Codex available on PATH.

git clone https://github.com/qualixar/jev-codex-workbench.git
python3 jev-codex-workbench/scripts/install.py

The installer configures the Codex plugin, lets you choose the supported provider, and accepts the provider credential through a hidden terminal prompt. For v1.1.1, restart Codex Desktop after installation, inspect the three Qualixar Jev hooks with /hooks, and explicitly trust them before relying on Policy Mode.

Start in the default assist mode. Explore the catalog and run fixtures before authorizing any live call.

Then read:

• TypeSafe Introduction: https://docs.typesafe.ai/introduction
• TypeSafe System One: https://docs.typesafe.ai/concepts/system-one
• TypeSafe Primitives: https://docs.typesafe.ai/primitives
• TypeSafe Agent Skill: https://docs.typesafe.ai/agent-skill
• TypeSafe Intent Routing: https://docs.typesafe.ai/patterns/intent-routing
• TypeSafe Parallel Questions cookbook: https://docs.typesafe.ai/cookbooks/parallel_questions
• TypeSafe Jev 1.13 boundaries: https://docs.typesafe.ai/model-jaggedness/jev-1.13
• Qualixar Jev Control source: https://github.com/qualixar/jev-codex-workbench
• v1.1.1 release: https://github.com/qualixar/jev-codex-workbench/releases/tag/v1.1.1

The next thing I want to publish is not a marketing percentage. It is the benchmark that earns one: the same real Codex traces with Policy Mode off and on, measured end to end.

That is where we will find out exactly how much of the coding agent's expensive reasoning budget can be protected by making the small decisions first.