Preço de contexto longo: até 6.7x, invisível nos gateways

O preço exibido na página de um modelo do gateway deixa de ser o preço da fatura quando o prompt cresce. Enviamos requisições por um grande agregador multiprovedor, dos dois lados de cada limite de tamanho documentado, para nove modelos com preços por faixa. Cinco cobraram exatamente 2x o preço da página após o primeiro limite. Os três modelos da Alibaba chegaram a 3x, 3x e 6.7x no topo de suas faixas. Um modelo servido pela Azure cobrou 1.25x a tarifa anunciada para o endpoint dos dois lados do limite e depois dobrou. Nada disso aparece na página. O mecanismo é documentado pelos próprios fornecedores: Google, OpenAI, xAI, Alibaba, ByteDance e MiniMax reajustam o preço da requisição inteira, incluindo a saída, quando o input passa de 32K, 128K, 200k, 256K, 272K ou 512k tokens. Este post mostra as faturas, depois as tabelas de faixas por trás delas e, por fim, as configurações que mantêm uma requisição abaixo do limite.

TL;DR

• Nove modelos com preços por faixa cobraram de 1.8x a 6.7x após o limite do fornecedor por meio de um agregador cujas páginas mostram um único preço. O GPT-5.6 Luna via Azure cobrou 1.25x o valor anunciado.
• O qwen3.7-flash cobrou $0.03, depois $0.10 e depois $0.20 por milhão de tokens de entrada nos limites de 32K e 256K. O qwen3-coder-plus parou em 3x, enquanto o fornecedor anuncia 6x.
• Os fornecedores reajustam o preço da requisição inteira, incluindo a saída, assim que o input cruza um limite entre 32K e 512k tokens.
• Limite o input, não o output: Claude Code /autocompact, Codex model_context_window e gatilhos de compactação da API.

Os gateways cobram o preço mostrado na página?

Não quando o prompt fica longo. Para descobrir quanto será cobrado, são necessários dois dados de cada intermediário: os metadados de preço publicados pelo gateway e o custo efetivamente reportado para uma requisição de cada lado do limite.

Um grande agregador multiprovedor publica seu catálogo com um array pricing.overrides: um preço-base mais regras condicionais como min_prompt_tokens: 200000, acompanhadas das tarifas maiores. Para modelos da DeepSeek e da Tencent, também há janelas utc_start / utc_end de preços fora do horário de pico. No catálogo obtido em 2026-09-01, 60 entradas tinham overrides, incluindo os modelos Gemini Pro, Grok 4.x, qwen3.7-plus, qwen3.7-flash, qwen3-coder-plus, os modelos Seed 2.0 e toda a família GPT-5.6 no limite de 272,000. As páginas dos modelos mostram apenas o preço-base. A faixa aparece nos metadados. E esses metadados não reproduzem necessariamente todas as faixas do fornecedor: o qwen3-coder-plus tem regras em 32,000 e 128,000, mas não na quarta faixa do fornecedor, em 256K.

Por isso, enviamos requisições dos dois lados de cada limite documentado por esse agregador, com a contabilização de uso ativada. O agregador retorna na resposta o valor cobrado. Também registramos o endpoint responsável pelo atendimento, porque um único model id no agregador pode encaminhar para vários provedores upstream, cada um com seu preço. O agregador chama esses provedores de endpoints. Executamos duas medições por ponto, em 2026-09-02 e 2026-09-03:

As páginas foram capturadas no mesmo dia das faturas: um preço em destaque, uma tabela por endpoint e nenhuma faixa por tamanho em nenhuma delas. Todas as cobranças seguiram os metadados token por token. Os nove modelos mudaram de faixa no primeiro limite do fornecedor e aplicaram o mesmo multiplicador. Nos três modelos da Alibaba, a fatura seguiu uma escada que a página não menciona. O qwen3.7-flash passou de $0.03 para $0.10 em 32K e para $0.20 em 256K, 6.7x o preço exibido em uma página que mostra $0.03. O GPT-5.6 Luna também mudou de faixa e apresentou uma diferença adicional: toda execução servida pela Azure foi cobrada a 1.25x o preço anunciado para o endpoint da Azure, tanto abaixo quanto acima do limite ($0.275 contra $0.22, e $0.50 e $0.55 contra $0.40 e $0.44). Esse acréscimo não aparece na página nem nos metadados do endpoint.

A escada também pode parar antes da tabela do fornecedor. No qwen3-coder-plus, a cobrança subiu para 1.8x em 32K e 3x em 128K, mas permaneceu em $1.95 por milhão até 276k tokens. Na tabela da própria Alibaba, o input sobe para $6 e o output para $60 nesse ponto, seis e doze vezes os valores-base. Os metadados do agregador não têm uma regra em 256K, então a cobrança não mudou. Não é possível saber de fora se o agregador absorve a diferença ou compra sob outro contrato. O que podemos observar é que a fatura segue os metadados, enquanto os metadados e a página são documentos diferentes.

A falta de transparência não está entre os metadados e a fatura. Está entre a página e ambos. O valor em destaque na página é a tarifa do endpoint mais barato da tabela abaixo, não necessariamente a tarifa do endpoint que atenderá à requisição. Nenhum dos valores inclui a condição de tamanho. Um card de modelo com preço único não informa a faixa, qual endpoint atenderá à próxima requisição nem se a sua conta tem acesso ao endpoint cujo preço está sendo consultado.

A regra prática é simples. Consulte o preço em formato legível por máquina para o modelo usado, no nível do endpoint, e procure uma condição de tamanho. Depois, envie uma requisição de cada lado do limite com a contabilização de uso ativada e compare o custo reportado. Se a cobrança muda onde a página não mostra mudança, o gateway está repassando uma regra do fornecedor sem informá-la. Se a cobrança permanece estável onde o preço do fornecedor muda, o gateway está servindo o modelo por um provedor com preços diferentes ou absorvendo a diferença. Apenas a primeira hipótese tende a ser estável.

Onde ficam os limites e como as faixas são aplicadas?

Seis fornecedores publicam limites de tamanho. Em todos os modelos que documentam a regra, a tarifa mais alta é aplicada a todos os tokens da requisição, incluindo o output. A maioria dos primeiros limites dobra o preço, mas as escadas vão além: 3x no único limite do qwen3.7-plus, 6.7x no input da terceira faixa do qwen3.7-flash e 6x no input e 12x no output da quarta faixa do qwen3-coder-plus. Os preços são por milhão de tokens e foram obtidos nas páginas dos fornecedores em 2026-09-01.

Há dois detalhes de fronteira que precisam entrar no código de billing. As duas páginas do Google divergem por um token: a nota do Vertex diz “maior ou igual a 200K”, enquanto a tabela de preços da Gemini API diz “prompts > 200k tokens”. A Alibaba também define K com precisão: 128K equivale a 128,000 tokens e 256K equivale a 256,000, não a potências de dois.

A faixa é determinada apenas pelo tamanho do input e vale para a requisição inteira, incluindo todos os tokens de output. Por isso, o custo marginal do token que cruza o limite inclui todo o acréscimo aplicado aos tokens anteriores. No Gemini 2.5 Pro, um prompt de 199,999 tokens gera $0.25 de cobrança de input. Com 200,001 tokens, passa a $0.50, e uma resposta de 4,000 tokens sobe de $0.04 para $0.06. Um token a mais acrescenta $0.27.

No qwen3.7-plus, o salto é de 3x: pela tarifa oficial, um prompt de 255,029 tokens custa $0.102; um prompt de 257,332 tokens custa $0.309. No qwen3-coder-plus, o mesmo mecanismo se acumula em quatro faixas. Um prompt de 260k tokens paga seis vezes a tarifa por token de um prompt de 30k, e o output paga doze vezes.

A regra aparece em uma fatura real, não apenas na tabela do fornecedor. No qwen3.5-plus, cujas faixas oficiais são $0.40 e depois $0.50 por milhão de tokens de input em 256K, o valor por token de input em nossa fatura do gateway diferiu em exatamente 1.25x entre dez execuções abaixo do limite (243k tokens) e 24 execuções acima dele (256k a 321k), sem mudança no preço do output. A requisição de 259k não pagou 1.25x apenas nos últimos 3k tokens. Pagou 1.25x em todos eles.

Em um agente que acumula histórico, o limite é cruzado no meio da sessão e sem aviso. O turno que ultrapassa a linha paga o acréscimo sobre todos os turnos anteriores enviados junto. Cada turno seguinte continua pagando até que o contexto seja reduzido.

A capacidade do modelo muda no mesmo limite?

Não. Medimos isso porque é fácil confundir uma faixa de preço com um limite de capacidade, mas são coisas diferentes. Em dois modelos Qwen com limite em 256K, inserimos um needle com salt, uma informação de uma linha contendo um código aleatório por execução, em cinco profundidades. Com o thinking desativado, os dois modelos recuperaram a informação 30 de 30 vezes em 243k, 269k e 320k tokens. A latência cresceu de forma contínua com o tamanho, sem salto no limite: medianas de 15.2 s, 17.0 s e 20.5 s no qwen3.7-plus. Uma tarefa mais difícil, contar K ocorrências raras espalhadas pelo log inteiro, piorou com o tamanho. No qwen3.7-plus, a fração encontrada caiu de 74% em 128k para 60% em 192k, 58% em 243k e 45% em 320k. A queda começa muito antes do limite de preço, e os pontos dos dois lados seguem a mesma tendência.

A documentação da própria Anthropic dá nome a esse efeito gradual: conforme o número de tokens aumenta, a precisão e o recall pioram, “um fenômeno conhecido como context rot”. O efeito é real e contínuo, sem relação com o ponto em que o preço muda.

Como manter uma requisição abaixo do limite?

Limite o input, não o output. A faixa é escolhida pelo tamanho do input da requisição, então max_tokens, que limita o output, não ajuda. É preciso configurar o que restringe o conteúdo enviado pelo cliente. Há controles em quatro camadas.

A tabela abaixo mostra as configurações que limitam o prompt em cada camada. “Abaixo da faixa?” identifica as opções que aceitam um número absoluto de tokens e podem ser configuradas logo abaixo de um limite de preço. As opções relativas ao context window apenas evitam ultrapassar a janela do modelo, que é outro valor.

A tabela leva a duas conclusões. Em um agente de código usando um modelo com faixas, o compaction window é o controle que troca o salto de preço por uma sumarização. Ele deve ser configurado em tokens absolutos, logo abaixo do limite, e não como fração de uma janela de 1M. Além disso, duas configurações de segurança muito comuns, truncation: "auto" do Responses e o middle-out do agregador, protegem apenas contra o limite da janela. Elas atuam no context window do modelo, que é 1M nos modelos Gemini e GPT-5.6 com faixas, e não nos 200,000 ou 272,000 tokens em que o preço muda. Evitam a falha da requisição, mas ainda permitem cruzar o limite de preço.

Não conte com o cache para ficar abaixo do limite. Prompt caching reduz a fatura, mas não evita a mudança de faixa nos modelos do Google, onde as leituras de cache seguem as mesmas faixas por tamanho. Um prefixo em cache de 150k somado a 60k de contexto novo forma um prompt de 210k e é cobrado como tal. Capacidade provisionada elimina essa questão, pois provisioned throughput units (PTUs) são cobradas por hora, independentemente dos tokens. Se cruzar o limite fizer sentido, faça isso de propósito. As medições acima mostram que o modelo não piora nesse ponto. A decisão depende apenas de saber se o contexto marginal compensa um multiplicador de 2x, 3x ou, nas faixas mais altas, 6.7x sobre a requisição inteira.

Como a Synthorai trata essas faixas

Uma faixa por tamanho é uma condição de preço, então o gateway a trata dessa forma. O card de preço de um modelo pode conter uma lista de faixas indexadas pelo limite de tokens de input. Cada requisição é precificada pela faixa selecionada pelo tamanho do próprio prompt, aplicada a todos os tokens, da mesma forma que o fornecedor cobra. Esse foi o mecanismo usado na fatura do qwen3.5-plus acima. O registro de uso guarda o número de tokens do prompt e a versão do preço junto com o custo calculado. Assim, é possível decompor a fatura e identificar que determinada requisição cruzou o limite. A faixa usada na cobrança pode ser consultada no registro de uso, não apenas em uma tabela de preços.

Perguntas frequentes

A tarifa maior de contexto longo incide apenas sobre os tokens que ultrapassam o limite?

Não. Todos os fornecedores que documentam a regra reajustam a requisição inteira: Google (“todos os tokens (input e output) são cobrados pelas tarifas de contexto longo”), OpenAI (“para a requisição inteira”), xAI (“para todos os tokens da requisição”) e Alibaba (“todos os tokens da requisição são cobrados pelo preço unitário da faixa correspondente”). Um prompt apenas um token acima do limite paga o acréscimo sobre todos os tokens anteriores.

Os gateways de API repassam as faixas de preço de contexto longo?

Sim, nas nossas medições. Em um grande agregador, nove modelos com faixas foram cobrados pela tarifa mais alta do fornecedor após o limite definido por ele, embora as páginas dos modelos exibissem um único preço. A faixa aparece nos metadados de preço do gateway, não na página. Os metadados também podem omitir uma faixa do fornecedor, como ocorreu com o qwen3-coder-plus acima de 256K.

max_tokens mantém uma requisição abaixo de uma faixa de preço?

Não. max_tokens limita o output, enquanto a faixa é determinada pelo tamanho do input. As configurações úteis são as que limitam o prompt: um compaction window ou limite de tokens no agente, como Claude Code /autocompact e Codex model_context_window, um gatilho de compactação na API ou truncamento no cliente antes do envio.

A qualidade do modelo cai no limite de preço?

Não nas nossas medições. Em dois modelos Qwen com faixas, o recall do needle foi perfeito dos dois lados do limite de 256K. Uma tarefa de contagem piorou gradualmente com o tamanho, sem mudança brusca no limite. A faixa é uma regra comercial. A perda de capacidade com contextos maiores existe, mas é contínua.

Preços e regras citados das páginas dos fornecedores consultadas em 2026-09-01; configurações de agentes e APIs obtidas na documentação vinculada em 2026-09-02; medições de fatura executadas de 2026-09-01 a 2026-09-03, com thinking desativado, prompts com salt e duas execuções por ponto no agregador. Os preços mudam; consulte a fonte vinculada antes de fixar um limite no código de billing.

Relacionado: guia de unidades de cobrança (a camada de modificadores detalhada neste post), anatomia do uso de tokens, como funciona o prompt caching, medição dos mínimos de cache.

← Voltar ao blog