LLM Routing with Jev 1.14: Judgments Before Actions

Jev 1.14 expands the judgments an application can use before taking an action. Better LLM routing still depends on relevant candidates, clear criteria and measured outcomes: the model supplies a judgment, while your code authorizes and executes the next step.

Key takeaways:

• Jev 1.14 introduces Box questions; TypeSafe also reports incremental improvements, particularly for multilingual inputs.
• Image inputs and extended context are opt-in capabilities with explicit reliability caveats, not automatic production upgrades.
• Independent questions can share a request. A question that depends on another answer needs application orchestration.
• A model selecting an action does not grant permission to perform it or prove that the action will succeed.

This article is by Devesh and connects the smart-routing product to the newer Jev capabilities documented by TypeSafe. It separates vendor functionality, an illustrative action-selection design and the behavior customers should verify in their own deployment. No benchmark or model upgrade was performed for this article.

The problem in one request

A user asks a support agent to explain a failed build and open a ticket if an infrastructure change is necessary. That request contains several jobs: understand the failure, decide whether information is missing, choose an answering model and potentially change another system. A single instruction to choose the best action mixes judgment, permissions and execution.

These distinctions matter even when every response is correctly typed. Choosing the wrong valid identifier is still a routing failure. The useful question is whether newer judgments improve the customer outcome without increasing inappropriate actions or making the request too slow.

For the broader request lifecycle, LLM Routing for AI Agents: One Model Per Step, One Key explains why selecting one model for every agent step can obscure differences between tasks. The application should make those differences observable before introducing another automated action.

Why the naive approach breaks

The simplest router sends a prompt and a few model names to a classifier, accepts its favorite, and executes immediately. That design has three independent failure points: candidate coverage, semantic accuracy and execution authority. Updating the classifier addresses none of them automatically.

1. A narrow shortlist can omit the model that best fits the work.
2. Nearly identical descriptions give the chooser little evidence to distinguish candidates.
3. An ambiguous request can still receive a valid choice, even when none of the options fits.
4. A downstream executor can turn a mistaken judgment into an unauthorized change.

TypeSafe's Choice documentation describes a closed-set question with per-option probabilities. A companion Noul can separately assess whether any candidate fits. That additional check creates a deliberate abstention path; it is not a substitute for authorization.

For routing, descriptions should reflect tested capabilities and constraints, rather than prestige or a generic heavy label. Keep the same eligibility checks whether the chooser is an older release, Jev 1.14 or a deterministic rule. A stronger judge cannot evaluate an option it never receives.

The mechanism: LLM routing with newer Jev judgments

The Jev 1.14 release announcement, dated October 14, 2026, describes incremental improvements and identifies multilingual support as an area of expected gain. It also introduces experimental capabilities. Those are vendor statements, not measured gains for nRouter workloads.

The current model reference lists a 64k-token request limit and a 32k-token per-question limit by default; opt-in long context raises both to 262k. These are native TypeSafe limits. They do not establish how much customer content nRouter sends during Auto selection, nor prove that the gateway exposes every native feature.

Illustrative action-selection architecture. Independent judgments share inputs; application code owns the branch and the action. This diagram is not a claim that nRouter implements this exact pipeline.

TypeSafe's fan-out pattern evaluates independent questions against shared state. Asking both task and model questions does not make model selection task-informed: the second question must either contain the necessary task evidence already or receive the first answer in a later request. Choose parallel or sequential composition because of the dependency, not because one shape sounds more intelligent.

Worked example

Consider a proposed support workflow with a permitted set of read-only actions. The native TypeSafe payload below is a request-shape example. It is not a body to paste into nRouter's Chat Completions endpoint, and it does not imply a separate native TypeSafe endpoint is available through nRouter.

{
  "model": "jev-1.14.0",
  "state": {
    "user_request": "Explain this build failure; ask me if logs are missing.",
    "available_evidence": "The build log was not attached."
  },
  "questions": {
    "next_step": {
      "type": "choice",
      "instructions": "Which permitted next step fits the request and evidence?",
      "criteria": {
        "ask_for_logs": "Required build evidence is missing; request it.",
        "explain_failure": "Evidence supports a useful explanation now."
      }
    },
    "evidence_sufficient": {
      "type": "noul",
      "instructions": "Is the supplied evidence sufficient to explain the cause?"
    }
  }
}

Both judgments see the same missing-log evidence. The application can reject an inconsistent pair of answers and ask for clarification. It should not fabricate a cause because one output has the expected type.

There is also an operational reason to compare batching. Suppose a decision sends the same state to two independent questions:

The request-count reduction is (2 - 1) / 2 = 50%. That is arithmetic about this example, not a 50% latency, token-billing or invoice claim. Instructions and criteria still consume input, and actual provider accounting must be measured. Fan-out also leaves question independence unchanged. It cannot implement an answer-dependent second stage inside the same request.

A structural comparison of request packaging, not a measured performance chart. Validate latency, usage and answer quality separately.

Edge cases we had to decide

The following are design decisions for the illustrative application, not promises about undocumented nRouter behavior. The important improvement is making each branch explicit enough to test.

1. When no offered action fits, we return a review outcome, because a closed-set choice should not force the executor to pretend the request is covered. A separate fit judgment makes this branch visible.
2. When evidence is insufficient, we ask for the missing evidence, because a valid action name does not repair an incomplete state. We retain the original request so that a follow-up can be evaluated against the same goal.
3. When the caller lacks permission, we refuse the action, because a model output is not a new authorization grant. Permission checks run again against the concrete target before execution.
4. When an action request times out, we reconcile its execution status before retrying, because repeating a decision is different from repeating a side effect. A ticket creation needs a stable operation identifier and duplicate protection.
5. When an experimental image judgment is uncertain, we request review or better evidence, because a guessed coordinate can refer to the wrong control. A model upgrade alone does not justify an automatic click.

This separation follows the risk described by OWASP's Excessive Agency guidance: excessive functionality, permissions or autonomy can amplify model mistakes. Keep available actions narrow and their credentials scoped. Do not rely on a prompt asking the model to behave responsibly as the only enforcement layer.

What you see from the outside

For nRouter model routing, start with the public API contract rather than assuming that new native Jev primitives change the Auto request format. This request uses the customer gateway key and asks for quality-oriented selection:

curl --include https://api.nrouter.ai/v1/chat/completions \
  -H "Authorization: Bearer $NROUTER_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "nrouter/auto",
    "nrouter_optimize": "quality",
    "messages": [
      {"role": "user", "content": "Explain this build error and identify what evidence is missing."}
    ],
    "max_tokens": 512
  }'

Use the router settings guide to check the current customer controls. The response's x-nr-model identifies the answering model, and x-nr-request-id connects the request to its logs. If a cost is unknown, an absent cost header is not evidence of a free request.

For a separate application that consumes typed judgments, keep dispatch explicit. This executable TypeScript fragment operates on an illustrative result; it does not call a live model or create a ticket:

type Action = 'ask_for_logs' | 'explain_failure';

function nextStep(
  answer: { choice: string; confidence: number },
  evidenceSufficient: number,
  permitted: ReadonlySet<Action>,
): Action | 'review' {
  if (!Number.isFinite(answer.confidence) ||
      answer.confidence < 0 || answer.confidence > 1 ||
      !Number.isFinite(evidenceSufficient) ||
      evidenceSufficient < 0 || evidenceSufficient > 1) return 'review';
  if (answer.choice !== 'ask_for_logs' &&
      answer.choice !== 'explain_failure') return 'review';
  if (!permitted.has(answer.choice)) return 'review';
  // Illustrative thresholds only: tune using your own labeled requests.
  if (answer.confidence < 0.8) return 'review';
  if (answer.choice === 'explain_failure' &&
      evidenceSufficient < 0.9) return 'review';
  return answer.choice;
}

console.log(nextStep(
  { choice: 'ask_for_logs', confidence: 0.95 },
  0.1,
  new Set<Action>(['ask_for_logs']),
)); // ask_for_logs; no external action is performed

The confidence guide explains why confidence and answer probability are different signals. Neither the example thresholds nor a concentrated distribution establishes your system's real error rate. Persist the actual served version, question version and review outcome so that a threshold change can be evaluated later.

Limits: LLM routing still needs evidence

Jev supplies focused judgments, not a replacement for generative reasoning or a trusted policy engine. Use an answering LLM for explanations, code generation and open-ended synthesis. Keep exact arithmetic and permission comparisons in ordinary code. TypeSafe's model-jaggedness reference also identifies literal interpretation, irrelevant context and option-order sensitivity as cases to test.

For images, TypeSafe requires an opt-in header and explicitly labels the capability experimental. A Box question returns one set of normalized image edges; it does not execute an action, and it returns a box even when the target is absent. Pair localization with a presence judgment and validate coordinates before use.

Run a pinned-version replay before enabling a moving model alias. Include supported languages, missing evidence, competing tasks, reordered options and adversarial content. Then compare final task success and cost per successful task, not only classification accuracy. Hash-Based A/B Tests: Same User, Same Model Variant, Every Call explains stable assignment, while LLM Latency: p50, p95, p99, and Time-to-First-Token explains why a mean response time can hide unacceptable tails.

Frequently asked questions

What is actually new in Jev 1.14?

Box questions require 1.14. TypeSafe reports incremental model improvements, with particular emphasis on multilingual support. Images and opt-in longer context are also documented for 1.13, so they should not be described as exclusive 1.14 features.

Does Jev execute tools or change models by itself?

No. A judgment can identify an action or model option, but application code must resolve the identifier, apply permissions and execute it. A typed choice is useful control input, not unrestricted tool access.

Does a Jev upgrade automatically improve nRouter Auto?

No. Native vendor features, a deployed integration and measured routing quality are separate facts. Verify the serving version and supported request contract; this article does not announce an Auto rollout or native image/Box support through the gateway.

Should task classification always precede model selection?

Only when the later step needs the classification result. Independent questions can run together; task-informed candidate retrieval requires a real dependency and an additional stage. Compare both designs on your requests before accepting the added latency.

Try it

1. Inspect the available models and their supported interfaces in the model catalog.
2. Run the Auto request above and record the answering model, request ID and final-answer quality.
3. Replay a small labeled workload before changing routing or action thresholds; keep experimental visual judgments outside automatic execution until evaluated.

To start using the managed gateway, visit app.nrouter.ai/signup. Pay as you go starts with a $5 minimum credit purchase; usage settles at the answering model's list price with 0% platform markup. See pricing for current terms. For permission-sensitive deployments, discuss requirements with nRouter Enterprise. The nRouter platform provides the broader gateway context; the code and native TypeSafe examples here serve different interfaces.

See also

• LLM Routing for AI Agents: One Model Per Step, One Key — separate answering-model selection from the rest of an agent's workflow.
• Cut LLM Costs by Routing, Not by Rewriting Your App — compare cost-oriented routing with quality-oriented selection.
• Hash-Based A/B Tests: Same User, Same Model Variant, Every Call — keep experimental assignment stable while comparing changes.
• LLM Latency: p50, p95, p99, and Time-to-First-Token — measure the delays that affect real users rather than relying on an average.
• Smart routing — check the customer-facing Auto and fallback behavior before changing an integration.

Sources

Verified 2026-11-07. Vendor capabilities are documented claims; no new latency, accuracy or production-scale benchmark was run. Send corrections to hello@nrouter.ai.

• TypeSafe release: Jev 1.14 announcement.
• TypeSafe model contract: Versions, context limits and aliases.
• TypeSafe judgment interface: Question types, Choice and confidence.
• TypeSafe composition: Fan-out and companion Noul.
• TypeSafe experimental inputs: Images and Box.
• TypeSafe known limitations: Model jaggedness.
• OWASP action boundaries: Excessive Agency.