Routing controls

Priority presets, model classes, and per-request constraints. Tell the auction what you value.

Owner

Product

Version

beta-2026.07

Verified

2026-07-13

You choose a model class and say what you value. The auction compares every eligible signed quote for that class under the same published rule. Controls ride in the request's routing block; they shape ranking or eligibility without granting a provider a private preference.

Priority presets

Version second-score/3 starts with expected USDC cost for the request. It then applies a router-measured time-to-first-token factor and a service factor built from completion reliability, verification trust, and throughput. The priority preset changes the price-versus-latency tradeoff; it does not turn off the service measurements.

Measurements come from the router's request path rather than a provider's marketing claim. They affect who wins. The clearing tariff is then bounded by the selected profile's published ceiling over the cheapest independent alternative. Every receipt names the price-setter that actually applied.

Six profiles, six explicit ceilings

The router enforces these limits rate by rate before award and checks them again using the final metered token counts. If a provider's own ask cannot fit the selected ceiling, it cannot win that request.

How automatic profile routing is scored

Profile cards call POST /v1/routing/preview, which runs the same chooser as a paid model:auto request. The response names the candidate count, winning class, score contribution from task fit, broad quality, price, latency, and competition depth, plus whether the selected task signal is prior-only, emerging, or observed.

• Coding and reasoning do not inherit broad model quality. Each starts with an independent neutral prior unless the model manifest contains a distinct specialist signal, then task-specific Omnious outcomes update it.
• Frontier uses a separate quality-first objective: 88% broad quality, 7% task fit, 3% price, and 2% measured latency before the competition adjustment. Its provider auction still enforces the 25% service- premium ceiling above.
• Thin supply is penalized, not hidden. One independent economic group adds 0.04 to the loss score, two add 0.0125, and three or more add none. Economic ownership is used instead of raw backend count when that metadata is available.

Reading the FIT score

The Terminal's model drawer shows a task-fit radial with a single FIT number beside it. FIT is the rounded arithmetic mean of the model's supported task-fit axes — general, coding, reasoning, extraction, long context, and tool use — each expressed as a percentage. The vision axis joins the average only when the class accepts images; a text-only class has that axis omitted entirely, not plotted as zero. The dashed catalog-median outline on the radial is a comparison overlay only and never enters the FIT average.

While the label reads transparent route prior, no outcome evidence exists yet and FIT is simply the mean of the class's catalog priors. Once Omnious observes task outcomes, each axis becomes a Bayesian estimate: the catalog prior carries the weight of 20 observations, positive evidence must first clear a conservative lower confidence bound before it raises the score, and no amount of evidence can move an axis more than 10 percentage points from its catalog prior. The label then switches to Omnious observed with the evidence count.

Signals are deterministic and content-local: delivery alone is deliberately not evidence, because transport success measures provider reliability rather than answer quality. The same aggregate evidence is public at GET /v1/analytics/task-fit, so a displayed FIT can always be reproduced from the catalog prior plus the published counts.

Role-aware routing for agent swarms

A multi-agent job should not buy every token from the same tier. Send an agent_role when a request is part of a swarm: a frontier planner owns decomposition, value workers carry parallel volume, reasoning reviewers grade the candidate, and a frontier reconciler resolves supported findings. These are router-enforced market policies, not labels added after selection.

{
  "model": "auto",
  "messages": [{ "role": "user", "content": "Review the candidate" }],
  "routing": {
    "agent_role": "reviewer",
    "parent_task_id": "swarm_7d4...",
    "agent_id": "reviewer_1",
    "provider_deny": ["provider-that-produced-the-candidate"]
  }
}

Explicit request constraints still win. provider_deny is composed with provider allow-lists and capability gates before the auction, so an excluded producer cannot become the reviewer merely because it submits the cheapest quote. Successful responses echo the role, parent task, and agent id in x-routing-agent-role, x-routing-parent-task, and x-routing-agent-id.

One-off swarm UX in the app

Choose Run as swarm beside the composer for a single request. The execution spec makes the hard USDC maximum, worker cap, review mode, quality target, exact role allocations, and likely spend range visible before send. It closes after that request, so swarm mode never silently becomes a permanent conversation setting.

During execution the agent tree becomes a live economic ledger: every node shows its role, selected model and provider, role cap, metered spend, and receipt count. The controller will not create workers or reviewers beyond the signed allocation. Unused session authorization is shown as unspent rather than as a charge.

Project Field Guide

Build projects have a compact, editable Field Guide beside Files and Checkpoints. Agents can record reusable decisions, constraints, discoveries, and warnings through update_field_guide. Entries are project-scoped, deduplicated, bounded to 32 entries and 6,000 characters, visible to the user, and injected into later build turns. Routine progress and raw transcripts stay out of it.

Model classes, not marketing labels

The model field names a class, such as glm-4.7 or minimax-m3. Providers quoting the same class compete on expected cost and measured service, including verification trust. The catalog exposes class capabilities so a customer can choose a flash, workhorse, or frontier tier before the provider auction begins.

An uncataloged class receives the catalog's neutral capability treatment. Image-bearing requests are rejected for text-only classes before payment. Provider claims and supervised model-integrity review remain Shadow controls; they are not a public collateral or insurance promise.

Per-request constraints

• routing.max_price_usdc: a hard decimal-USD ceiling. The router refuses rather than quote above it, before payment.
• max_tokens: bounds the output used in the worst-case 402 authorization.
• routing.session_id and routing.session_budget_usdc: bind turns into a session with one budget authorization and a locked award tariff.