Auto, TokenLab Verified, or Official: Choosing a Delivery Tier

When we saw an unexpected route, the model name was not the useful clue; the delivery tier was. The route that serves a request can change price eligibility even when the logical model stays the same. That mismatch is why we treat delivery tier as a routing decision, not a quality badge. It matters when price eligibility and routing need to be explicit. It matters much less when your default policy already matches your risk and cost goals.

Key Takeaways

What the three delivery tier options actually are

Channels declare delivery tiers as VERIFIED and OFFICIAL. Only channels with an active public delivery tier can be bound to an organization model binding. A workspace can bind a logical model to a specific channel. That binding is rejected unless the channel is active, not deleted, and declares an active public delivery tier. A route for the model on that channel must also be enabled.

Official means the route is served by the official provider path, while Verified means a TokenLab-verified path. Auto is the policy that lets the router pick among reachable routes; when we inspect a request after dispatch, resolvedDeliveryTier tells us whether verified or official served it. That field is null when the record predates the feature.

What changes when you choose a delivery tier

Choosing a tier changes price eligibility, per-request records, and the estimate you see before dispatch. Pricing can be adjusted per delivery tier through organization-level delivery price adjustment rules, and that adjustment is normalized and validated before it is applied. Post-launch, explicit Verified or Official choices continue to apply, while requests that predate the policy default to Auto.

Auto estimates the maximum amount for the request rather than a single price. More than one route may be reachable, but Auto keeps every reachable route and does not drop the more expensive route to make the estimate look lower. In our pipeline, we check the estimate before dispatch and resolvedDeliveryTier after completion.

Option	What it optimises	When to pick it	What you can verify afterwards
Auto	Reachable routes and maximum cost estimate	You want the default policy to choose among reachable routes	resolvedDeliveryTier shows the route that served the request
TokenLab Verified	Access to TokenLab-verified paths when Official is not available or not required	You need a verified route, or no Official route matches	resolvedDeliveryTier shows verified
Official	Exact Official route match for official pricing eligibility	You need official pricing eligibility	resolvedDeliveryTier shows official

How teams usually configure delivery tier policy

The readback numbers in this section come from the TokenLab 2.0 launch readback recorded in internal release rehearsal notes, observed 2026-09-11; treat them as an internal production readback, not a public benchmark.

The default setup is inheritance, not per-request ceremony. At the 2026-09-11 production readback, we saw 5,536 workspaces with an explicit Auto policy, while another 217 inherited the system default. All 4,134 API keys inherited from their workspace, so old clients did not need a new header. That pattern makes sense because the workspace policy covers the common case, and per-request override remains the exception.

A later readback the same week showed 5,536 explicit and 219 inherited, while the explicit count held flat and the inherited count moved from 217 to 219. Those inherited workspaces were newly created accounts that had not set a policy yet, so these counts move as accounts are created. Setting a policy was never a migration, no bulk backfill of workspace or key policy ran at launch, and inherited keys needed no client change.

The binding rules still apply when a workspace binds a logical model to a specific channel. The binding is rejected unless the channel is active, not deleted, and declares an active public delivery tier. An enabled route for the model on that channel must also exist. A channel can only be bound to an organization model binding while its Registry declaration is ACTIVE and its own record is ACTIVE with no deletion timestamp, so a paused or retired channel cannot be pinned.

Pinning a logical model to a specific channel is how a workspace expresses always Official for this model without touching individual requests. Requests that predate the delivery policy default to Auto. No client change was required, and no bulk backfill of workspace or key policy was performed at launch. For model-level context, pair this with the model data center guide.

How to check which delivery tier served a request

When a request finishes, read resolvedDeliveryTier in the request record; the value is verified or official, and a null value means the record predates the field. The request also carries requestedDeliveryPolicy, which records what the caller asked for and is nullable when the workspace default applied.

To override the tier for one request, add the X-TokenLab-Delivery-Policy header; the accepted values are auto, verified, and official. Here is the header by itself:

# Add this header to the Claude Sonnet 5 request
X-TokenLab-Delivery-Policy: verified

For example, this cURL call targets Claude Sonnet 5 and asks for official:

curl https://api.tokenlab.sh/v1/chat/completions -H "Authorization: Bearer $TOKENLAB_API_KEY" -H "Content-Type: application/json" -H "X-TokenLab-Delivery-Policy: official" -d '{"model":"Claude Sonnet 5","messages":[{"role":"user","content":"Hello"}]}'

After the call, the request record for that call carries:

{
  "requestedDeliveryPolicy": "official",
  "resolvedDeliveryTier": "official"
}

The request record also includes usage fields, and the Request Console guide shows where that record lives and the current field names for usage.

If the requested tier has no enabled route, the gateway answers with delivery_tier_unavailable and does not silently fall back to another tier. The request console shows where that record lives, and the Request Console guide explains how to find it. We start there when a price or route looks unexpected, because the console and request evidence can show which tier served the traffic.

When Auto picks a delivery tier you did not expect

When Auto picks a tier you did not expect, read resolvedDeliveryTier on the request and compare it with the channels your organization has bound. Then either bind the model to the channel you want or override the tier for that request. This keeps the default policy simple while giving you a concrete way to correct a surprising route.

Limitations

The numbers here are a point-in-time readback from 2026-09-11, and they will drift. Delivery tier availability depends on which routes are active for your model and organization. A workspace binding can be rejected if the channel is inactive, deleted, lacks an active public delivery tier, or has no enabled route for the model. The per-delivery-tier price adjustment depends on your own organization rules. We cannot give a universal comparison because the source data does not provide one. The delivery decision is resolved after route selection, so the tier you get depends on which routes are enabled for your organization at that moment.

FAQ

What does Auto actually choose?

Auto is the default policy, not a third route type. It keeps reachable paths and estimates the maximum amount the request can cost before dispatch. Requests that predate the policy default to Auto. After dispatch, resolvedDeliveryTier records whether the request was served through a verified or official route.

Why would a Verified route cost more than an Official route?

Pricing can be adjusted per delivery tier through organization-level delivery price adjustment rules. The adjustment is normalized and validated before it is applied. So the difference depends on your configuration, and you should check the price shown before dispatch.

Do I have to set a delivery tier on every request?

No. Workspace and API-key policy inheritance is the normal setup. At the 2026-09-11 production readback, 5,536 workspaces had an explicit Auto policy, 217 inherited the system default, and all 4,134 API keys inherited from their workspace. The inherited count moved to 219 later that week as new accounts were created. These figures come from the TokenLab 2.0 launch readback recorded in internal release rehearsal notes, observed 2026-09-11; treat them as an internal production readback, not a public benchmark. You can override the delivery choice per request, but a workspace default covers the common case.

How do I know which tier served a finished request?

Read resolvedDeliveryTier in the request record. The value is verified or official, and it is null when the record predates the field. requestedDeliveryPolicy shows what the caller asked for, and it is nullable when the workspace default applied. The request console and the Request Console guide show where that record lives.

What happens if I request a tier with no enabled route?

The gateway answers with delivery_tier_unavailable. It does not silently fall back to another tier. Read the request record, then either enable a matching route or change the requested policy.

Create an API key and compare the tier you get with the tier you expected; the Request Console guide shows where that record lives.