Routing OpenCode Tasks with Jev

A developer built a model router for OpenCode that uses the TypeSafe AI Jev model via OpenRouter to classify coding tasks by coordination, uncertainty, and consequences, then routes each request to either a powerful or weaker model based on a computed complexity score. The classifier, tested on roughly one hundred requests, selects the powerful model when complexity meets a threshold that tightens as potential consequences grow.

After the release of the TypeSafe AI Jev model and its availability in OpenRouter, I decided to immediately test its capabilities and rewrite my minimalist model router in OpenCode. To do this, I wrote a tool for OpenCode that sends requests to Jev through the OpenRouter API. The main idea is to build the solution based on three criteria. After testing the classifier on about a hundred different requests, I settled on the following instructions: Coordination "Does successful implementation require reasoning about interactions or coordinated behavior across multiple parts of the system, rather than merely making localized changes in more than one file or module?" Uncertainty "Does successful implementation require open-ended investigation to discover an unknown root cause, bottleneck, design, or implementation strategy, rather than following a bounded diagnostic procedure with clear tools and success criteria?" Consequences "Would an incorrect implementation have significant consequences, such as broad regressions, compatibility breakage, security issues, or data loss?" These have currently shown the greatest effectiveness. Next, I calculate complexity as the maximum of two criteria: coordination and uncertainty. And a threshold value that depends on the consequences. The more serious the consequences, the lower the threshold value and the higher the probability that a powerful model will be used to solve the task. If complexity is greater than or equal to the threshold value, the powerful model is selected; otherwise, the weaker one is selected. While developing this tool, I used ideas from several sources. I will quote them below: "Rather than ask a model to solve the entire problem in one shot, we ask independent narrow questions and defer to code where possible. ... The results are then used programmatically to produce the output actions." "The most reliable real-world workflows tend to have many independent, decomposed questions, with fine-grained behavior that's dependent on probabilities instead of discrete decisions." "Jev outputs all probabilities in parallel instead of autoregressively generating by token." "The end result is discrete branching, but how we get to a final answer involves a lot of domain-specific engineering that needs to be done highly consistently." https://typesafe.ai/blog/introducing-system-one-models-and-jev https://typesafe.ai/blog/introducing-system-one-models-and-jev "Each prompt was evaluated ... and returned a structured JSON object containing scores for seven criteria ... These scores constituted a computable prompt-level vector used by the routing rule. ... consists of calculating the total weighted score of each decision alternative and then selecting the alternative with the highest final value." https://www.mdpi.com/2078-2489/17/6/539 https://www.mdpi.com/2078-2489/17/6/539 The complete source code of the tool: js // .config/opencode/tools/jev route.ts import { tool } from "@opencode-ai/plugin"; const apiKey = process.env.OPENROUTER API KEY; if apiKey { console.error "Missing OPENROUTER API KEY environment variable. Please set it to your OpenRouter API key.", ; process.exit 1 ; } const lite = Choose lite when the plan can be implemented reliably with localized changes and does not require cross-cutting reasoning. Typical lite work: - small fixes or straightforward feature changes - changes confined to one area of the codebase - following existing patterns - mechanical edits, tests, lint/type fixes, config tweaks - investigation or commands with a clear procedure ; const build = Choose build only when successful implementation requires substantial cross-cutting reasoning, design judgment, or carries significant regression risk. Choose build when the plan involves one or more of: - coordinated changes across multiple components or services - architecture or system design decisions - non-trivial debugging where the root cause is unknown - substantial refactoring with behavioral consequences - public APIs or compatibility guarantees - database schema changes or migrations - concurrency, distributed systems, or complex async behavior - authentication, authorization, or security-sensitive logic - significant performance or resource-management work - dependency or infrastructure changes with broad impact ; export default tool { description: "Classifies an approved implementation plan and returns either lite or build.", args: { plan: tool.schema .string .describe "The complete approved implementation plan" , }, async execute { plan } { const response = await fetch "https://openrouter.ai/api/alpha/decisions", { method: "POST", headers: { Authorization: Bearer ${apiKey} , "Content-Type": "application/json", }, body: JSON.stringify { model: "~typesafe/jev-latest", state: Approved implementation plan: ${plan} If uncertain, choose build. , questions: { coordination: { type: "noul", instructions: // "Does successful implementation require coordinating behavior or changes across multiple parts of the system?", "Does successful implementation require reasoning about interactions or coordinated behavior across multiple parts of the system, rather than merely making localized changes in more than one file or module?", }, uncertainty: { type: "noul", instructions: // "Does successful implementation require resolving substantial uncertainty, such as an unknown root cause, unclear design choice, or missing implementation strategy?", // "Does successful implementation require first discovering the root cause, bottleneck, correct design, or implementation strategy because it is not already known from the plan?", "Does successful implementation require open-ended investigation to discover an unknown root cause, bottleneck, design, or implementation strategy, rather than following a bounded diagnostic procedure with clear tools and success criteria?", }, consequence: { type: "noul", instructions: "Would an incorrect implementation have significant consequences, such as broad regressions, compatibility breakage, security issues, or data loss?", }, }, } , } ; const { answers } = await response.json ; const complexity = Math.max answers.coordination.noul, answers.uncertainty.noul, ; const threshold = answers.consequence.noul = 0.7 ? 0.4 : 0.65; return complexity = threshold ? "build" : "lite"; }, } ; The orchestration agent is forbidden from taking any actions other than calling one tool and delegating the task. Route agent configuration: --- description: Routes tasks to the appropriate implementation agent mode: primary model: openai/gpt-5.6-luna permissions: - action: " " resource: " " effect: deny - action: subagent resource: Build effect: allow - action: subagent resource: Lite effect: allow - action: jev route resource: " " effect: allow --- You are a task orchestrator. Planning is complete. Treat the latest plan as approved. 1. Call jev route with the latest approved plan. 2. It returns lite or build . 3. Delegate the implementation to that subagent. 4. Do not override the routing decision. 5. Do not implement the task yourself. 6. After completion, verify the result and respond concisely. This is much faster and cheaper than using "thinking" models. It is too early to draw final conclusions, but the initial results look promising. I will observe how it goes.