Route by complexity, price by the task

A lower price per million tokens does not necessarily mean a lower bill for a completed job. A model might need more reasoning tokens or retries. Conversely, a less expensive model can clear the same quality bar with fewer dollars spent on the whole task. The useful comparison is how much accepted work a configuration buys.

That changes the role of routing. If the goal were to save a little on a fixed prompt, model choice would be an optimization. When tasks differ in difficulty and cost per successful outcome, it becomes architecture. AIVAX's Complexity Router classifies the latest user request, selects a model and reasoning effort for its tier, then routes that model to a provider. The application can keep one gateway identifier.

The bill that matters is per task

Providers still invoice in tokens, and a task can include other charges. “Price by the task” evaluates a system; AIVAX does not replace token billing with a flat per-task tariff. Count model inputs and outputs, routing, tools, and retries needed for an accepted result. Divide total spend by accepted tasks: a low token price can conceal a high cost per useful outcome.

The distinction is visible in OpenAI's GPT-6 Sol and Luna release. OpenAI lists Sol at $2 per million input tokens and $10 per million output tokens, versus the cited $4 and $20 for GPT-5.6 Sol. The token-rate change is straightforward; the task-level comparison depends on the evaluation, effort setting, and success rate. OpenAI reports that on AutomationBench 1.0.6, an end-to-end business-workflow evaluation using 47 tools, Sol at xhigh effort scored 33.2% at $0.27 per task. In the same published comparison, OpenAI lists Claude Opus 5 at max effort at 26.9% and 11.1 times Sol's cost per task. These are OpenAI-reported results, including the competitor comparison, not an independent AIVAX run.

Routing asks which model clears the quality threshold for this request, and at what cost. Prices, model behavior, and task mix can change. Hard-coding one “best” model everywhere makes reevaluation an application-wide migration; a gateway keeps that decision in one place.

How the Complexity Router works

An AI Gateway configured with @model-router/complexity runs a classification step before the main inference. The classifier considers the conversation but labels the last user message as low, medium, or high complexity. Simple fact lookups, basic classification, reformatting, and greetings belong to low; comparison, explanation, and summarization belong to medium. Deep reasoning, multi-step work, system design, and non-trivial debugging belong to high. The labels describe the work requested, not the importance of its subject.

The classifier's response is constrained to a JSON object with a complexity value of low, medium, or high. It uses medium reasoning effort, a 32,768-token context window with truncation on overflow, and no multimodal input. Its pool contains smaller models selected circularly among those currently usable; if none is usable, selection fails. When the classifier returns unparseable output, AIVAX logs the error and defaults to medium rather than treating a bad parse as low complexity. The instructions also direct it to choose medium when uncertain. These boundaries matter: classification is a model judgment over available text, not a guarantee of the ideal tier.

The gateway exposes the decision in the X-Model-Routed-Complexity HTTP response header as Low, Medium, or High. With the configurable complexity router, it looks up the model name for that tier among integrated chat models and applies that tier's configured reasoning effort. Hard-routed model triples also use the classifier, but their per-tier model choices are fixed by the alias instead of the gateway's model-name settings. After selecting a model, a separate provider-routing decision chooses where to run it. The Balanced, Cheapest, Fastest, and Quality strategies consider provider price, throughput, latency, uptime, and quality signals. Choosing which model and choosing which provider for that model are different decisions.

Classification is not free. Its input and output are metered separately as inference.resolving.routing_complexity.in and inference.resolving.routing_complexity.out usage against the same account. Include that overhead when comparing a routed gateway with a fixed-model call, especially for tiny tasks. Routing only improves economics when its savings or quality gains exceed its cost and the cost of wrong decisions.

Route the work, not the topic

A product area is a poor substitute for task complexity. A support assistant can answer “What is the refund window?” in one turn, compare two policies in the next, then investigate conflicting account and payment records. Sending all three requests to one “support model” hides the difference in work. A coding assistant likewise alternates between formatting and debugging.

Reserve less expensive models for straightforward work and escalate when a request calls for more synthesis or planning. Low complexity does not mean low stakes: formatting a legal clause can demand careful review even if it requires little reasoning. Put those requirements in application policy and quality checks, not in an assumption that the classifier understands risk. A configured model must also support the workflow's tools and input modalities.

Reasoning effort travels with the configurable tier. The nominal model alone does not define the bill: more effort can produce more tokens or a different result. Pair low complexity with modest effort and high complexity with more effort when your own tasks justify it, without changing the caller's gateway identifier. The classifier uses medium effort; routed responses need not.

What today's catalog move changes

As of 2026-09-22, the AIVAX catalog points @model-router/openai:mid to GPT-6 Sol, @model-router/openai:budget to GPT-6 Luna, and @model-router/claude:frontier to Claude Opus 5.5. These aliases name individual models, not an automatic low/medium/high mapping for every complexity-routed gateway. Configure the gateway's three tier names and efforts explicitly if you want those models in its complexity policy; check the current catalog before relying on time-sensitive alias targets.

OpenAI reports GPT-6 Luna at $0.10 per million input tokens. On DeepSWE v1.1, an evaluation of long-horizon software-engineering work in real codebases, OpenAI reports Sol at max effort at 68.8%, close to Claude Fable 5 at xhigh effort at 69.9%, at approximately 80% lower cost per task. OpenAI reports Luna at max effort at 66.6% on DeepSWE; compared with Claude Opus 5 and Fable 5 at medium effort, it estimates 93% and 96% less per task, respectively. These comparisons use different models and effort settings and do not establish a universal coding ranking.

For computer use, OpenAI reports Sol at xhigh effort scoring 60.5% on OSWorld 2.0 offline, versus 60.3% for Claude Opus 5 at medium effort, at approximately 80% lower cost per task. On Agents' Last Exam, which tests complex professional workflows, OpenAI reports Sol at max effort scoring 56.4% at 60% lower cost per task than the highest-scoring Opus 5 configuration in its comparison. Separately, Anthropic says Claude Opus 5.5 costs 40% less to run on typical workloads than Opus 5. None of these vendor-reported benchmarks measures your prompts, tools, context lengths, or acceptance criteria. OpenAI notes that competitor results in its launch comparisons come from published reports rather than its own runs.

The catalog change widens the choices; it does not make one alias right for every task. Revisit tier assignments when the catalog changes, but include routing overhead and error recovery before claiming savings.

Observe the header, replay the decision

Start with a gateway configured for integrated @model-router/complexity and with model names and reasoning efforts for its low, medium, and high tiers. With a server-side private key, a non-streaming call to the OpenAI-compatible endpoint can read the selected tier directly from the response:

const response = await fetch("https://inference.aivax.net/v1/chat/completions", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.AIVAX_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    model: process.env.AIVAX_ROUTING_GATEWAY_ID,
    messages: [{ role: "user", content: "Compare these two designs." }],
  }),
});

if (!response.ok) throw new Error(`Inference failed: ${response.status}`);

const tier = response.headers.get("X-Model-Routed-Complexity");
const completion = await response.json();
console.log(tier, completion.choices[0].message.content);

Use the header as an audit signal, not proof that the choice was right. In an evaluation set, keep the request, observed tier, configured model and effort, outcome, latency, and total account usage together. Compare tier mix with task success and cost: a rising low-tier share is only good news if accepted outcomes hold steady. Replay failures through the same gateway configuration, and test whether a different tier would have changed the result before changing production policy. Save the configuration version alongside the evaluation; a tier label without its contemporaneous model settings cannot explain a historical response.

Misclassification is the central operational risk. A high-complexity request sent to low can fail cheaply but repeatedly; an easy request sent to high can succeed expensively. Medium on parse failure limits one kind of under-escalation, but cannot rescue an unavailable classifier model or prove that classification was correct. The useful architecture is a measurable loop: route per request, observe the decision, measure accepted work and total spend, then revise the tier policy. Token rates are inputs to that loop. Cost per successful task is the outcome.