Auto, TokenLab Verified ou Official: Como escolher um nível de entrega

Quando vimos uma rota inesperada, o nome do modelo não foi a pista útil; o nível de entrega sim. A rota que atende a uma solicitação pode alterar a elegibilidade de preço mesmo quando o modelo lógico permanece o mesmo. Essa incompatibilidade é o motivo pelo qual tratamos o nível de entrega como uma decisão de roteamento, não como um selo de qualidade. Isso importa quando a elegibilidade de preço e o roteamento precisam ser explícitos. Importa muito menos quando sua política padrão já atende aos seus objetivos de risco e custo.

Principais pontos

• Uma solicitação pode ser atendida por meio de uma rota official ou uma rota verified. A escolha é registrada por solicitação como resolvedDeliveryTier (verified ou official, nulo quando o registro é anterior a isso).
• auto é a política padrão, não um terceiro tipo de rota. Ela mantém os caminhos acessíveis e estima o valor máximo que a solicitação pode custar antes do despacho.
• A herança de política de Workspace e API-key é a configuração normal. Na leitura de produção de 11/09/2026, 5.536 workspaces tinham uma política Auto explícita, 217 herdaram o padrão do sistema e todas as 4.134 API keys herdaram de seus workspaces. Uma leitura posterior naquela semana mostrou 219 herdadas. A contagem explícita permaneceu estável porque esses workspaces herdados eram contas recém-criadas que ainda não haviam definido uma política. Esses números vêm da leitura de lançamento do TokenLab 2.0 registrada em notas internas de ensaio de lançamento, observada em 11/09/2026; trate-os como uma leitura de produção interna, não como um benchmark público.
• A elegibilidade de preço Official requer uma correspondência exata de rota Official. A entrega Verified permanece disponível quando nenhuma rota Official corresponde.
• Você pode substituir a escolha de entrega por solicitação com o cabeçalho X-TokenLab-Delivery-Policy. Um padrão de workspace cobre o caso comum.

O que são realmente as três opções de nível de entrega

Os canais declaram níveis de entrega como VERIFIED e OFFICIAL. Apenas canais com um nível de entrega público ativo podem ser vinculados a uma vinculação de modelo de organização. Um workspace pode vincular um modelo lógico a um canal específico. Essa vinculação é rejeitada a menos que o canal esteja ativo, não excluído e declare um nível de entrega público ativo. Uma rota para o modelo nesse canal também deve estar habilitada.

Official significa que a rota é atendida pelo caminho oficial do provedor, enquanto Verified significa um caminho verificado pelo TokenLab. Auto é a política que permite ao roteador escolher entre as rotas acessíveis; quando inspecionamos uma solicitação após o despacho, resolvedDeliveryTier nos diz se verified ou official a atendeu. Esse campo é nulo quando o registro é anterior ao recurso.

O que muda quando você escolhe um nível de entrega

Escolher um nível altera a elegibilidade de preço, os registros por solicitação e a estimativa que você vê antes do despacho. O preço pode ser ajustado por nível de entrega por meio de regras de ajuste de preço de entrega em nível de organização, e esse ajuste é normalizado e validado antes de ser aplicado. Após o lançamento, escolhas explícitas de Verified ou Official continuam a ser aplicadas, enquanto solicitações anteriores à política usam Auto como padrão.

Auto estima o valor máximo para a solicitação em vez de um preço único. Mais de uma rota pode estar acessível, mas Auto mantém todas as rotas acessíveis e não descarta a rota mais cara para fazer a estimativa parecer menor. Em nosso pipeline, verificamos a estimativa antes do despacho e resolvedDeliveryTier após a conclusão.

Opção	O que otimiza	Quando escolher	O que você pode verificar depois
Auto	Rotas acessíveis e estimativa de custo máximo	Você deseja que a política padrão escolha entre as rotas acessíveis	resolvedDeliveryTier mostra a rota que atendeu à solicitação
TokenLab Verified	Acesso a caminhos verificados pelo TokenLab quando Official não está disponível ou não é necessário	Você precisa de uma rota verificada ou nenhuma rota Official corresponde	resolvedDeliveryTier mostra verified
Official	Correspondência exata de rota Official para elegibilidade de preço oficial	Você precisa de elegibilidade de preço oficial	resolvedDeliveryTier mostra official

Como as equipes geralmente configuram a política de nível de entrega

Os números de leitura nesta seção vêm da leitura de lançamento do TokenLab 2.0 registrada em notas internas de ensaio de lançamento, observada em 11/09/2026; trate-os como uma leitura de produção interna, não como um benchmark público.

A configuração padrão é a herança, não a cerimônia por solicitação. Na leitura de produção de 11/09/2026, vimos 5.536 workspaces com uma política Auto explícita, enquanto outros 217 herdaram o padrão do sistema. Todas as 4.134 API keys herdaram de seus workspaces, então clientes antigos não precisaram de um novo cabeçalho. Esse padrão faz sentido porque a política de workspace cobre o caso comum, e a substituição por solicitação permanece a exceção.

Uma leitura posterior na mesma semana mostrou 5.536 explícitas e 219 herdadas, enquanto a contagem explícita permaneceu estável e a contagem herdada passou de 217 para 219. Esses workspaces herdados eram contas recém-criadas que ainda não haviam definido uma política, então essas contagens mudam conforme as contas são criadas. Definir uma política nunca foi uma migração, nenhum preenchimento em massa de política de workspace ou chave foi executado no lançamento, e as chaves herdadas não precisaram de alteração no cliente.

As regras de vinculação ainda se aplicam quando um workspace vincula um modelo lógico a um canal específico. A vinculação é rejeitada a menos que o canal esteja ativo, não excluído e declare um nível de entrega público ativo. Uma rota habilitada para o modelo nesse canal também deve existir. Um canal só pode ser vinculado a uma vinculação de modelo de organização enquanto sua declaração de Registro estiver ACTIVE e seu próprio registro estiver ACTIVE sem carimbo de data/hora de exclusão, portanto, um canal pausado ou aposentado não pode ser fixado.

Fixar um modelo lógico a um canal específico é como um workspace expressa "sempre Official" para este modelo sem tocar em solicitações individuais. Solicitações anteriores à política de entrega usam Auto como padrão. Nenhuma alteração no cliente foi necessária, e nenhum preenchimento em massa de política de workspace ou chave foi realizado no lançamento. Para contexto em nível de modelo, combine isso com o guia do data center de modelos.

Como verificar qual nível de entrega atendeu a uma solicitação

Quando uma solicitação termina, leia resolvedDeliveryTier no registro da solicitação; o valor é verified ou official, e um valor nulo significa que o registro é anterior ao campo. A solicitação também carrega requestedDeliveryPolicy, que registra o que o chamador solicitou e é anulável quando o padrão do workspace foi aplicado.

Para substituir o nível de uma solicitação, adicione o cabeçalho X-TokenLab-Delivery-Policy; os valores aceitos são auto, verified e official. Aqui está o cabeçalho por si só:

# Adicione este cabeçalho à solicitação do Claude Sonnet 5
X-TokenLab-Delivery-Policy: verified

Por exemplo, esta chamada cURL tem como alvo o Claude Sonnet 5 e solicita 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"}]}'

Após a chamada, o registro da solicitação para essa chamada carrega:

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

O registro da solicitação também inclui campos de uso, e o guia do Request Console mostra onde esse registro reside e os nomes atuais dos campos para uso.

Se o nível solicitado não tiver uma rota habilitada, o gateway responde com delivery_tier_unavailable e não faz fallback silencioso para outro nível. O console de solicitação mostra onde esse registro reside, e o guia do Request Console explica como encontrá-lo. Começamos por aí quando um preço ou rota parece inesperado, porque o console e as evidências da solicitação podem mostrar qual nível atendeu ao tráfego.

Quando o Auto escolhe um nível de entrega que você não esperava

Quando o Auto escolhe um nível que você não esperava, leia resolvedDeliveryTier na solicitação e compare-o com os canais que sua organização vinculou. Em seguida, vincule o modelo ao canal que você deseja ou substitua o nível para essa solicitação. Isso mantém a política padrão simples, ao mesmo tempo em que lhe dá uma maneira concreta de corrigir uma rota surpreendente.

Limitações

Os números aqui são uma leitura pontual de 11/09/2026, e eles sofrerão variações. A disponibilidade do nível de entrega depende de quais rotas estão ativas para seu modelo e organização. Uma vinculação de workspace pode ser rejeitada se o canal estiver inativo, excluído, não tiver um nível de entrega público ativo ou não tiver uma rota habilitada para o modelo. O ajuste de preço por nível de entrega depende das suas próprias regras de organização. Não podemos fornecer uma comparação universal porque os dados de origem não fornecem uma. A decisão de entrega é resolvida após a seleção da rota, portanto, o nível que você obtém depende de quais rotas estão habilitadas para sua organização naquele momento.

FAQ

O que o Auto escolhe exatamente?

Auto é a política padrão, não um terceiro tipo de rota. Ela mantém os caminhos acessíveis e estima o valor máximo que a solicitação pode custar antes do despacho. Solicitações anteriores à política usam Auto como padrão. Após o despacho, resolvedDeliveryTier registra se a solicitação foi atendida por meio de uma rota verified ou official.

Por que uma rota Verified custaria mais do que uma rota Official?

O preço pode ser ajustado por nível de entrega por meio de regras de ajuste de preço de entrega em nível de organização. O ajuste é normalizado e validado antes de ser aplicado. Portanto, a diferença depende da sua configuração, e você deve verificar o preço mostrado antes do despacho.

Preciso definir um nível de entrega em cada solicitação?

Não. A herança de política de Workspace e API-key é a configuração normal. Na leitura de produção de 11/09/2026, 5.536 workspaces tinham uma política Auto explícita, 217 herdaram o padrão do sistema e todas as 4.134 API keys herdaram de seus workspaces. A contagem herdada passou para 219 mais tarde naquela semana conforme novas contas eram criadas. Esses números vêm da leitura de lançamento do TokenLab 2.0 registrada em notas internas de ensaio de lançamento, observada em 11/09/2026; trate-os como uma leitura de produção interna, não como um benchmark público. Você pode substituir a escolha de entrega por solicitação, mas um padrão de workspace cobre o caso comum.

Como sei qual nível atendeu a uma solicitação finalizada?

Leia resolvedDeliveryTier no registro da solicitação. O valor é verified ou official, e é nulo quando o registro é anterior ao campo. requestedDeliveryPolicy mostra o que o chamador solicitou, e é anulável quando o padrão do workspace foi aplicado. O console de solicitação e o guia do Request Console mostram onde esse registro reside.

O que acontece se eu solicitar um nível sem rota habilitada?

O gateway responde com delivery_tier_unavailable. Ele não faz fallback silencioso para outro nível. Leia o registro da solicitação e, em seguida, habilite uma rota correspondente ou altere a política solicitada.

Crie uma API key e compare o nível que você obtém com o nível que esperava; o guia do Request Console mostra onde esse registro reside.