Introducing Verboo Code routers: a new way to bring AI models together through a single integration, with a model selected for each request. As the work changes throughout development, the model handling it can change too.
Our first routing strategy uses Jev, from TypeSafe, to assess how well candidate models fit the task. Verboo Code combines that assessment with access controls, model capabilities, and the response generation workflow.
Your application uses one alias. For each request, Verboo Code selects the model that will generate the response and manages the candidate pool. We can add or remove models over time while preserving that integration point.
What this means for developers
- Less manual model switching. Your agent keeps using the same alias as it explains code, writes tests, and investigates problems. Model selection happens with every call.
- Capabilities matched to the task. Different stages can be handled by different models, within the authorized pool and the technical requirements of each request.
- Cost considered during selection. The strategy considers task suitability and estimated execution cost. The goal is to allocate resources more efficiently; actual gains depend on the models and the workload.
- An integration that evolves with the product. The candidate pool can change without requiring applications to use a different model identifier. Messages, tools, and streaming remain part of the Chat Completions workflow.
A session might start with reading a function, move on to writing tests, and end with an investigation spanning several files. The router can assess each stage individually, based on the context supplied with each request.
A stable integration, an evolving model pool
The same cycle governs each call: receive the request, check which models meet its requirements, assess eligible candidates, and forward generation to one of them. On the next call, the process repeats with the new context. One model generates the response to each request.
Verboo Code manages this pool and can add or remove models in the future. Your application continues to use the same router alias and Chat Completions workflow. The pool can evolve while the mechanism stays consistent: assess each request and select a model capable of handling it.
Jev's role in the decision
Jev is a TypeSafe model designed to evaluate information and return structured answers. Its API lets applications ask questions about a text context and use the resulting assessments to inform decisions. Explore the TypeSafe API.
In our first strategy, we use this capability to estimate how suitable each candidate is for the task. That estimate informs the decision alongside the request's technical constraints and the models' costs.
The selected model handles generation. It receives the call's messages, tools, and parameters, then produces the content delivered to the user. This separation allows the selection strategy and the generation models to evolve independently.
How a request works
1. Check compatibility
The router checks candidate model availability and applies technical filters to the request:
- Context: an estimate of input size and the requested output limit, checked against the model's context window.
- Vision: image support when the request includes images.
- Reasoning: support for the
reasoning_effortlevel specified in the call.
The context estimate serves as an initial check. The exact token count still depends on the tokenizer of the model performing generation.
2. Select from eligible candidates
The strategy considers the suitability assessment and the estimated cost of input and output tokens. The assessment itself also has a cost and adds a processing step. Its efficiency depends on the model pool and the results achieved across the full workflow.
3. Generate the response
The request is forwarded to the selected model with its messages, tool definitions, and parameters. Execution retains the applicable access controls and limits. The router can make a new decision on the next call.
Built on Chat Completions
Routers are built for the /v1/chat/completions endpoint. The workflow preserves messages, tool definitions, and streamed responses. The request's technical requirements guide the selection of the model that performs generation.
For the application, the model field identifies the router. In this example, the alias is jev-router: it stays the same when Verboo Code updates the model pool. Access to the router follows the group's permissions:
{
"model": "jev-router",
"messages": [
{
"role": "user",
"content": "Analyze this function and propose tests for edge cases."
}
],
"stream": true
}
In a coding agent, a response may request a tool, and the tool's result may feed into the next call. The same alias stays in use throughout that cycle, while model selection follows the context of each step.
One instance, unified access
The router acts as a virtual instance in Verboo Code, assigned to the groups that can use it. It brings together the selection strategy, candidate models, and a default model for fallback.
Verboo Code manages the composition of the pool. Applications continue to access it through the router: model updates preserve the identifier used in API calls.
Continuity and failure handling
Selection has a time limit. If the assessment times out, fails, or does not identify a suitable candidate, the router can use the default model, provided it remains eligible for the request.
If no eligible option is available, the call returns an error. The selection layer does not automatically repeat generation once it has started. Fallback happens during the decision that precedes generation, as shown in the diagram.
Jev's assessment uses a text excerpt from the recent conversation history, which may contain task content. Image URLs and binary content are excluded from that assessment. The generation request's context is forwarded to the selected model.
A foundation for new strategies
Jev powers the first strategy in this architecture. Separating selection from execution makes it possible to add other strategies in the future and adapt the model pool to different workloads.
Models at launch
The initial pool includes DeepSeek V4.1 Flash, GLM 5.3, and MiniMax M3. GLM 5.3 Flash is one option for future additions. This composition is a starting point: we can add or remove models as the service evolves while keeping the alias used by your application.
With routers, we bring different AI capabilities into a common integration: developers keep their workflow, and model selection adapts to each new request.
