When TypeSafe introduced Jev, it added a different intelligence primitive to the agent stack. Large language models generate open-ended text, code, commands, and plans. Jev receives state plus typed questions, then returns structured answers with probabilities. That narrower contract makes it useful wherever software needs a fast judgment from a closed set.
Developers quickly explored command review, policy checks, model selection, browser actions, and workflow routing. We had already brought Jev into SuperQode through the SystemOne Harness, GEPA-guided decision tuning, and progressive tool discovery. Each integration used the same underlying idea: let a specialized decision model evaluate bounded choices while the surrounding harness owns control flow.
Then Daniel Farina published an experiment called Nitro. He placed Jev in front of Grok Build and asked it to choose which tools the coding model should see for each turn. His measurements reported lower token use and lower cost on the tested tasks. The result exposed a broader opportunity. Every open coding harness carries a tool catalogue. Many send that entire catalogue on every model call. A general routing layer could serve far more than one CLI.
Why Jev fits this decision
Jev is TypeSafe AI's first System One model. Its interface centers on three typed question forms. Choice selects an item from a caller-defined set and returns a probability distribution. Score places an item on an ordered rubric. Noul evaluates a binary proposition with a probability between zero and one. Questions in one request are evaluated against the same state in parallel.
Tool routing has the shape Jev expects. The harness already knows the task, the conversation state, and every available tool name and description. The decision stays bounded: will this turn need a given tool at any step, including validation? Jev supplies probabilities; policy code applies thresholds, dependency rules, and safety constraints.
The division of responsibility matters. Jev selects definitions for the catalogue. It never creates a shell command, file path, patch, or tool argument. The coding model remains the author of each action. The harness continues to enforce permissions and decide whether execution may proceed.
The path through SuperQode
Our first Jev work focused on decisions inside a native harness. The SystemOne Harness added typed tool gates, rubric evaluation, standalone decision packs, and shadow traces. It gave us a clear boundary between generation, judgment, and policy.
Next came SystemOne Tune. GEPA uses execution evidence to improve reviewed question packs, compare candidate policies on a sealed split, and accept an update through an explicit gate. This work treats a decision policy as an artifact with versions, evidence, and evaluation history.
Progressive tool discovery extended the concept into catalogue selection. SuperQode retrieves candidates, sends the bounded set to Jev, inspects the returned distribution, and activates the selected schema when confidence and separation checks pass. A permission check still runs before any execution. Retrieval narrows the search space; Jev verifies the candidate; policy determines activation.
Nitro approached the same pressure point from another direction. Daniel modified the Grok Build sampling loop, placed one Noul question per tool into a single Jev request, retained six workspace primitives, and held the result for the full turn. His article reports eight tools kept from a catalogue of twenty-five on coding tasks, with the first-step prompt moving from 17.8K tokens to 9.5K. In the representative comparisons highlighted in the article, he measured cost reductions between 22 and 40 percent. Two runs per cell make this an early experiment, and Daniel states that limitation in the article. The architecture remains compelling because it targets repeated schema context without changing the coding model.
The hidden weight of tool catalogues
A coding-agent request contains more than conversation history. Tool names, descriptions, parameter schemas, enums, examples, permission hints, and provider metadata may occupy thousands of tokens before the model sees the current task. Browser controls, image generation, workflow management, subagents, schedulers, remote resources, and diagnostic functions can all travel with a request that only needs repository search and a test command.
That catalogue is sent again as the loop continues. Prompt caching can reduce the bill when the prefix stays stable, yet a large cached prefix still consumes context and carries a charge on providers that meter cached input. Cache behavior also varies by minimum prompt size, retention window, and elapsed generation time. A smaller stable catalogue improves the structure of every subsequent request.
Removing tools too aggressively creates a different failure mode. A task may begin with code reading and later need a test runner, process inspection, or an edit. The route therefore covers the entire turn and asks about completion, including checks. Core workspace primitives stay present even when their probability falls below the configured threshold.
Jev Tool Routing in SuperQode
SuperQode 2.4.10 ships Jev Tool Routing as a reusable layer for open coding harnesses. It can run inside SuperQode, beside an existing CLI, in a Python process, through a local gateway, over HTTP, or through MCP. Every surface reaches the same routing core.
The routing sequence has six stages:
- Capture the catalogue. An adapter reads the tool definitions before the model request is constructed.
- Build one closed-set decision. The router sends the turn state and one Noul question for each tool in a single Jev call.
- Apply the safety floor. Repository reads, search, edits, shell access, and process dependencies can remain available through protected rules.
- Freeze the route. A stable
turn_idreuses the same selection for every model step in that turn. - Preserve the original objects. Selected definitions keep their provider-specific schema and metadata.
- Fall back to the full set. Timeouts, transport errors, incomplete answers, or an empty route leave the complete catalogue in place.
Shadow mode records the proposed reduction while forwarding every tool. Enforce mode forwards the selected set after teams have inspected traces and verified their workflows. The threshold defaults to 0.30, with protected tools and dependency rules taking precedence.
A local-first developer experience
Trust begins on the developer's machine. The setup command detects installed harnesses, checks Jev connectivity, and prints the available routes. Verification uses a controlled catalogue to confirm schema reduction and same-turn cache reuse without calling a coding model.
uv tool install superqode==2.4.10
export TYPESAFE_API_KEY="your-typesafe-api-key"
superqode optimize setup
superqode optimize doctor
superqode optimize verify opencodeoptimize run starts a loopback gateway, injects a process-scoped endpoint override, launches the chosen harness, prints aggregate routing metrics, and removes temporary state. Persistent vendor configuration stays untouched. Managed launchers such as opencode-jev offer a short command once the route has been reviewed.
# Observe recommendations while the full catalogue stays available
superqode optimize run opencode -- "review this repository"
# Create managed launchers after reviewing the evidence
superqode optimize enable opencode claude grok pi
# Start a routed session
opencode-jev run "review this repository"Credentials remain separate. The local router reads TYPESAFE_API_KEY. A coding provider continues to use its own key or subscription. Generated OpenCode and Pi configuration receives a local placeholder where needed, while the gateway inserts the upstream credential at request time.
One core, several integration surfaces
Open harnesses expose different seams. Some accept an OpenAI-compatible base URL. Claude Code uses the Anthropic Messages protocol. OpenCode and Pi can speak native Gemini. A Python framework may prefer an in-process call. MCP clients need a tool-shaped interface. SuperQode covers those paths without creating a separate decision policy for each product.
- Native SuperQode: the router sits directly in the harness loop.
- Gateway adapters: OpenAI Responses, OpenAI Chat Completions, Anthropic Messages, and Gemini
generateContentrequests are supported. - Managed launch profiles: OpenCode, Claude Code, Grok Build, and Pi receive temporary endpoint configuration.
- Python SDK: a harness can call the routing core in-process and keep HTTP out of its local path.
- Service API:
POST /v1/route-toolsprovides a provider-neutral request contract. - MCP: local stdio and hosted Streamable HTTP expose
route_toolsto compatible clients.
The Python interface is deliberately small:
from superqode.jev_tools import JevToolRouting
router = JevToolRouting(mode="enforce")
result = await router.route(
task="Review this repository and run its tests",
tools=tool_catalogue,
turn_id="turn-123",
)
model_tools = list(result.tools)MCP offers a convenient shared capability, with one architectural boundary. An MCP server can route a catalogue supplied by its caller. It lacks access to hidden built-in tools inside another harness. Gateway and native adapters handle that interception point.
# Local HTTP and Streamable HTTP MCP service
export TYPESAFE_API_KEY="your-typesafe-api-key"
superqode serve jev
# Local stdio MCP surface
superqode optimize mcpCoverage across coding harnesses
OpenCode, Claude Code, and Grok Build have routable gateway profiles. Pi follows the same path and gains more room for reduction when extensions expand its compact core catalogue. SuperQode uses the router directly.
Codex reaches the gateway, although subscription traffic receives its built-in tool catalogue from the server. SuperQode reports this profile as gateway-limited and avoids catalogue-saving claims for that route. Antigravity is visible in the doctor command as detect-only until its CLI offers a model endpoint hook.
These labels are part of the feature. A routing product needs precise capability reporting because a successful proxy connection says little about where tool schemas entered the request.
What the first checks show
Our packaged OpenCode smoke used a ten-tool catalogue. Jev kept six. Serialized schema size moved from 39,656 bytes to 23,372 bytes, a 41.1 percent reduction. Repeating the request with the same turn identifier reused the cached decision. The run completed without a routing failure.
The hosted service received a two-tool request containing web search and image generation. It retained web search, removed image generation, and returned in 710 milliseconds on the first call. A second request for the same turn used the cache. The hosted MCP path returned the same route through route_tools.
These are integration checks. They establish that interception, selection, caching, schema preservation, authentication, and both service transports work together. Broader savings claims require a larger task set, repeated trials, several catalogue shapes, and end-to-end provider billing. Nitro supplies encouraging external evidence; our figures describe the current SuperQode smoke runs.
The hosted route
Local operation remains the fastest way to evaluate the feature. Teams that want one shared decision service can use the authenticated deployment at jev.superqode.dev. It runs the same bounded in-memory turn cache and routing contract as the local service.
curl https://jev.superqode.dev/v1/route-tools -H "Authorization: Bearer $SUPERQODE_JEV_SERVICE_TOKEN" -H "Content-Type: application/json" -d @route-tools-request.jsonThe service accepts bearer authentication for remote binds. The request contains the task state, tool definitions, mode, threshold, and turn identifier. Responses include kept and dropped names, latency, cache status, and the selected tool objects. The service routes definitions only; upstream model calls remain with the harness.
Why a shared layer matters
Maintaining a deep plugin for every coding CLI would tie the feature to many release cycles and extension systems. A shared core with thin launch profiles changes that maintenance equation. Protocol adapters handle wire formats. Harness-specific code stays limited to discovery, endpoint injection, and documented capability boundaries.
This structure also gives open-source maintainers several adoption paths. They can import the Python SDK, call a local service, connect through MCP, or place the compatible gateway in front of an existing model endpoint. A direct native hook remains available when a project wants the smallest latency and full control over turn identity.
The deeper benefit concerns harness ownership. Tool selection becomes an inspectable policy with thresholds, protected capabilities, traces, evaluation data, and versioned behavior. Teams gain a place to study which schemas are useful for their repositories instead of accepting a fixed catalogue assembled elsewhere.
Where we go next
The next stage is evidence at wider scale. We plan to evaluate longer coding sessions, extension-heavy catalogues, multiple providers, cache boundaries, false removals, latency distribution, and total billed input. Shadow reports will be especially valuable because they can compare the proposed route with the tools a session eventually used.
We also want better calibration by harness and repository type. A browser-oriented project, an infrastructure repository, and a Python library need different protected sets. SystemOne Tune gives us a path to improve those decisions from execution evidence while retaining a sealed comparison and an acceptance gate.
Jev Tool Routing is available today in SuperQode 2.4.10. Start locally, inspect shadow evidence, verify the adapter, and enable enforcement when the route fits your workflow. The source, Docker image definition, Cloud Run configuration, SDK, gateway, MCP server, tests, and command documentation live in the SuperQode repository.
Credits
Jev is created by TypeSafe AI. Daniel Farina's Nitro experiment identified tool-catalogue routing as a practical cost lever inside Grok Build and published the measurements that prompted this broader implementation. SuperQode carries the idea across open harnesses through a local-first, provider-neutral routing layer.