▸ jev ai router for intelligent llm routing | surp usage
new: Jev smart routing is live — how the Jev router picks your model · vote on SRP

How the Jev AI Router Selects an LLM

Product update · published September 29, 2026 · updated October 12, 2026

Surp now uses Jev, TypeSafe System One, as an opt-in decision model for intelligent LLM routing. The new router scores the task, reasons over exact live candidates, and accepts a model switch only when Surp's own safety and price rules allow it.

Choosing an LLM by a fixed table works until two requests need very different things. A short extraction task does not need the same model as a difficult debugging session with tools and a large context. Price also moves across the live Surplus marketplace, so a model name alone does not tell the router which fill makes sense now.

The surp/jev route adds a small typed decision before Surp quotes and dispatches the request. We adapted the policy ideas in gargpratyush/jev-router to Surp's API architecture. The original project routes Claude Code and Codex sessions. Surp has different constraints: a live candidate market, per-request pricing, x402 settlement, prepaid keys, prompt privacy, and a rule that the model choice cannot raise an amount already quoted.

One request returns four typed judgments

Surp sends one TypeSafe System One request for each Jev routing decision. That request asks four questions together:

  • How complex is the task?
  • How much reasoning does it require?
  • How complex is the expected tool use?
  • Which exact candidate model should handle it?

The first three answers are ordered scores. The fourth is a typed Choice whose keys are the live model IDs Surp supplied. The response also includes confidence and a probability for each candidate. Surp records those factors separately from payment and settlement data, then applies ordinary code rules before changing the route.

One typed call keeps the decision coherent. Four separate classifiers would add network work and could disagree because each saw a different decision frame. Surp instead gets one bounded result under one deadline.

Exact model IDs replace abstract tiers

The Claude and Codex router maps Jev's answer onto broad tiers. Surp already has an eligible pool resolved from the live market, so another tier-to-model translation would discard useful price and quality information. We send exact candidate IDs instead.

Each option describes the current Surp price and, when present, its intelligence score, throughput estimate, and discount from list price. Jev must choose from those options. An invented, stale, or ineligible ID fails validation and the original Surp route stays in place. The list is capped at 12 candidates by default.

No raw prompt messages enter the Jev decision

Surp does not copy messages, system instructions, source code, or tool definitions into the Jev request. The default state contains routing metadata: requested output tokens, estimated context size, model class, image and tool flags, tool count, cache eligibility, and candidate-pool size.

A client can optionally send surp_task_descriptor, such as Review a Python patch for concurrency bugs. Surp never derives this field from the prompt. It removes common email, credential, URL-userinfo, token, and long-secret patterns, normalizes whitespace, and caps the result at 1,200 characters. Keep private records, credentials, and prompt text out of the descriptor.

Four guards keep Jev inside Surp's rules

A Jev answer is advice. Surp has the final say.

  1. Candidate guard. The chosen model must appear in the exact pool supplied to Jev.
  2. Confidence guard. The default confidence floor is 0.55. Below it, Surp holds the original route.
  3. Cache guard. At 48,000 context tokens or more, Surp blocks a switch to a lower-quality model. Rebuilding a large provider prompt cache can erase the saving from a cheaper model. Read more about cache-aware LLM routing and the cache-affinity auction.
  4. Price guard. Jev's model cannot cost more than the baseline model already priced for the request. Surp falls back instead of silently increasing the charge or issuing a second quote.

Timeouts, missing credentials, SDK errors, invalid choices, and low confidence all lead to the same result: the existing router serves the request. Public routing counters are available at GET /api/jev/stats. They are decision telemetry, not x402 settlement or API-key accounting.

Connection reuse keeps the decision path small

The gateway creates one async TypeSafe client at startup and reuses its connection pool. Opening a new HTTP and TLS connection for every decision would waste much of the routing budget before Jev evaluated a candidate. The SDK timeout and Surp's outer async deadline both protect the request path.

This shared client was one of the practical changes that mattered when moving the policy from a local coding proxy into a public API gateway. The router can be clever only if it stays out of the way when it is slow.

How to call surp/jev

The endpoint stays OpenAI-compatible. Use a prepaid Surp key or complete the same x402 flow documented in the Surp API guide.

curl --fail-with-body https://surp.ivc.lol/v1/chat/completions \
  -H "Content-Type: application/json" \
  -H "Authorization: Bearer $SURP_API_KEY" \
  -d '{
    "model": "surp/jev",
    "messages": [{
      "role": "user",
      "content": "Review this retry strategy and identify failure modes."
    }],
    "surp_task_descriptor": "Review a backend retry strategy for correctness",
    "max_tokens": 800
  }'

The descriptor is optional. Existing presets keep their current behavior unless you select surp/jev. For evidence on model speed and cost, use the measured LLM performance board.

Payment and settlement do not change

Jev does not authorize payments, settle USDC, spend a prepaid balance, or alter accounting. Surp still quotes the selected model, returns the same x402 challenge when payment is required, verifies the same per-request EIP-3009 authorization on Base, and dispatches only after the existing payment checks pass.

This separation is deliberate. A routing model can recommend a fill. It does not get the keys to the cashier.

Frequently asked questions

What is Jev routing?

Jev routing is Surp's decision layer for selecting among the exact, live LLM candidates available for a request. Jev is TypeSafe System One. It evaluates the supplied candidates but cannot invent a model, add an unlisted provider, or route outside Surp's candidate set.

Does Jev receive raw user messages?

No. Jev receives request metadata and may receive an optional bounded, redacted surp_task_descriptor. It never receives raw prompt messages. The descriptor should contain only the limited, non-sensitive task context needed for routing.

How does Jev evaluate an LLM request?

Jev returns independent task-complexity, reasoning, and tool-use scores together with an exact model choice in one request. Surp then applies deterministic confidence, price, candidate, and cache rules before accepting the choice.

What happens when Jev has low confidence or is unavailable?

Surp keeps the route it already selected. Timeouts, client errors, invalid model IDs, and low-confidence answers do not block inference. This is fail-open routing: Jev can improve a selection, but inference does not depend on Jev.

Does Jev routing change Surp's x402 payment flow?

No. Jev changes model selection, not payment handling. Surp's x402 challenges, prepaid API keys, quotes, settlement, and accounting keep the same behavior. The price guard also prevents a Jev choice from increasing the amount already quoted.

Source and related pages