OpenRouter Auto Code: Why Your Cost Tier Setting May Be Ignored

OpenRouter's Auto Code ignores cost_tier inside the auto-router plugin. That plugin still controls its allowed and excluded models, but changing Auto Code to a general cost tier requires jev-router. A request can succeed while your intended cost setting does nothing, which makes this an easy configuration mistake to miss.

OpenRouter announced its rebuilt Auto Router and Auto Code on November 6. Auto is intended for mixed workloads; Auto Code is aimed at coding agents. Existing Auto users keep the same model ID, but the new default policy can cost more per task than the previous generation. Keeping an endpoint unchanged does not keep its behavior unchanged.

Check the model ID before changing the setting

The Auto Code documentation makes an important distinction between selecting models and selecting a cost policy. Auto Code uses a coding-specific tier by default, with more emphasis on speed and recovery from failures. It accepts model restrictions through auto-router, while a general cost-tier override belongs under jev-router.

For general Auto Router, use auto-router. For Auto Beta, use auto-beta-router. The Auto Router documentation warns that settings under the wrong plugin ID can be accepted and silently ignored. Its current tiers are low, medium and high; the older xhigh and max values map to high.

A successful HTTP response proves the request ran, not that your intended policy controlled it. Treat configuration verification as a separate step from connectivity testing.

A minimal Auto Code configuration

This request body demonstrates Auto Code with a general medium-cost policy and a restricted model pool. It is a documentation-based configuration example, not a measured performance test. Replace the author-wide patterns with the exact model IDs your organization has approved if you need a fixed allowlist.

{
  "model": "openrouter/auto-code",
  "messages": [
    {
      "role": "user",
      "content": "Explain the likely cause of a failing unit test before proposing a patch."
    }
  ],
  "plugins": [
    {
      "id": "auto-router",
      "allowed_models": ["anthropic/*", "openai/*"]
    },
    {
      "id": "jev-router",
      "cost_tier": "medium"
    }
  ]
}

Send the body to OpenRouter's Chat Completions endpoint through your existing authenticated client. If you want the coding-specific default, omit the jev-router override rather than assuming that medium means the same thing as Auto Code's normal policy.

The practical reason to keep these entries separate is reviewability. Someone looking at the request should be able to identify the permitted models independently from the preference used to choose between them. Putting both concerns into a setting that only partly applies makes a configuration look more controlled than it is.

Inspect the decision instead of guessing from the answer

Enable X-OpenRouter-Metadata: enabled and inspect the router metadata. The response's model identifies the selected model; the jev-router pipeline stage provides resolved models, candidates and the reason for selection.

During rollout, retain the requested router ID and plugin configuration alongside that result. Otherwise, a bill showing a particular model cannot tell you whether it was selected under your intended policy or an ignored setting. Avoid putting API keys or sensitive prompt content into diagnostic logs.

For a coding task, compare the configuration with and without the override while holding the repository state and task constant. Record whether the patch passes the same tests, how many attempts it needs and what the complete session costs. This is a proposed verification workflow, not evidence that either policy will win on your codebase.

A cost tier is not a spending ceiling

Both routers charge the selected model's standard rate without an extra routing fee. That still leaves the total dependent on the selected model, context length and number of turns. General Auto's low tier is the documented way to get costs closer to the previous generation, but it should not be interpreted as a fixed dollar limit.

Suppose one agent spends less per turn but takes twice as many turns to repair a bug. Its cheaper-looking individual calls may produce a more expensive completed task. That is why I would keep a session-level budget and a stop condition in the application even after correcting the router configuration.

Also investigate an empty model pool before treating a 404 as an outage: incompatible allowed and excluded lists can leave nothing eligible. Narrowing the pool is useful governance, but it necessarily reduces the choices available to the router.

The worthwhile migration is the one where you can explain both the selected model and the policy that allowed it. Until then, an automatic router is another changing dependency in your application, and a green API response is a weak substitute for knowing what changed.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help technical founders turn API changes and engineering decisions into clear content developers can use.

Book a 30-minute call.