Janela de Contexto do GPT-6.1 Sol: 1.050.000 Tokens, a Linha de 922.000 e o Penhasco de 272.000

A página de modelo do fornecedor para GPT-6.1 Sol, lida em 7 de outubro de 2026, indica uma janela de contexto de 1.050.000 tokens e uma saída máxima de 128.000 tokens. A mesma página, na forma legível por máquina que você obtém ao acrescentar .md à sua URL, traz um terceiro número que a página renderizada nunca exibe: um máximo de 922.000 tokens de entrada. GPT-6 Sol, o modelo que a versão 6.1 foi lançada para suceder em 29/09/2026, publica o par idêntico de números-limite em sua própria página, e a mesma linha de 922.000 em sua própria forma markdown. Nosso próprio cartão de modelo para openai/gpt-6-sol informa a janela como 1.050.000 tokens e o limite de saída como 128.000, exibe o primeiro deles como "1M" em sua faixa de especificações, e mostra "1.1M" para o mesmo modelo em uma tabela de comparação mais abaixo na mesma página.

Então, as páginas de fato divergem, e vale a pena ser preciso quanto a como. A faixa de especificações renderizada do fornecedor fornece uma janela e um teto de saída, e nenhum teto de entrada. A documentação em markdown do fornecedor para o mesmo modelo fornece todos os três. Qualquer pessoa que dimensione uma requisição com base na página renderizada está trabalhando com uma restrição a menos do que o fornecedor publicou, e a que falta é o número que decide se uma requisição cabe.

Três números, três fontes e uma subtração que ninguém anota

Aqui está cada número com o documento de onde veio, todos lidos em 7 de outubro de 2026.

• janela de contexto de 1,050,000 — a página do modelo do fornecedor para gpt-6.1-sol, na faixa de especificações renderizada e na sua forma markdown, e o mesmo valor na página para gpt-6-sol. É também o que o nosso catálogo retorna para openai/gpt-6-sol e openai/gpt-6-luna, em que o campo está definido como 1,050,000 em vez de arredondado.

• máximo de 128.000 tokens de saída — a mesma página, as mesmas duas formas, para ambas as gerações. O campo do nosso card indica 128.000; sua exibição arredonda para "128K".

• 922.000 tokens de entrada no máximo — a forma em markdown da página do modelo gpt-6-sol do fornecedor e da sua página do gpt-6.1-sol. Não consta na faixa renderizada de nenhuma das duas páginas, nem no nosso campo de catálogo do modelo, que termina na janela e no limite de saída.

As três cifras são aritmeticamente coerentes entre si: 922,000 mais 128,000 é exatamente 1,050,000. o próprio guia de raciocínio do fornecedor descreve o mecanismo que torna a identidade significativa sem nunca efetuar a soma na página do modelo — os tokens de raciocínio, diz ele, "ainda ocupam espaço na janela de contexto do modelo", e se os tokens gerados "atingirem o limite da janela de contexto ou o valor de max_output_tokens que você definiu", a resposta volta marcada como incompleta. Uma janela compartilhada entre o que entra e o que sai é uma janela em que o teto de entrada é a janela menos a reserva de saída.

Essa leitura é corroborada, não provada, e vale a pena separar as duas coisas. O que está documentado é uma janela de 1.050.000, um limite de saída de 128.000 e uma entrada máxima de 922.000. O que é inferido é qual desses é a restrição que dispara primeiro. A inferência é válida para todo pedido que reserva a totalidade da sua cota de saída e falha para qualquer pedido que não o faça — defina max_output_tokens como 4.000 e 1.046.000 tokens de entrada não são obviamente recusados. Até que o fornecedor escreva a subtração na página onde os números residem, encare o emparelhamento como a forma do orçamento, e não como uma regra de admissão rígida, e valide junto do endpoint de contagem, em vez de junto de um post de blog.

Contexto não é um preço: o passo de 272.000 tokens

Uma janela maior é uma alegação de capacidade. Não é uma alegação de custo e, nesta família, as duas se separam num limite documentado. A página de preços do fornecedor enuncia a regra em uma frase: prompts com mais de 272K tokens de entrada são cobrados a 2x as tarifas de entrada e de cache e 1,5x as de saída para a solicitação completa. A própria definição da mesma página para suas duas colunas é "Contexto curto: ≤272K tokens de entrada. Contexto longo: >272K tokens de entrada."

Leia a palavra full com atenção. O nível não taxa os tokens além da linha — ele reprecifica tudo, incluindo o primeiro token. E não é uma mudança da 6.1: a regra idêntica, com o limiar idêntico, aplica-se ao GPT-6 Sol, e é por isso que o cliff tem de ser atribuído ao nível, e não ao lançamento.

Execute um trabalho de contexto longo pelos dois lados, com base nas tarifas publicadas do GPT-6.1 Sol, com o prefixo já residente no cache, para que a cobrança de gravação em cache não contamine a comparação:

• 240.000 tokens de entrada (200.000 em cache, 40.000 novos), 6.000 de saída — entrada nova 40.000 a US$ 2,00 por milhão é US$ 0,080; entrada em cache 200.000 a US$ 0,10 é US$ 0,020; saída 6.000 a US$ 10,00 é US$ 0,060. Total, US$ 0,160.

• 300.000 tokens de entrada (260.000 em cache, 40.000 novos), 6.000 de saída — a solicitação agora está acima do limite, então todas as tarifas mudam: entrada nova 40.000 a $4,00 é $0,160; entrada em cache 260.000 a $0,20 é $0,052; saída 6.000 a $15,00 é $0,090. Total, $0,302.

Vinte e cinco por cento a mais de tokens de entrada compram uma fatura 89 por cento maior. Execute o mesmo par no GPT-6 Sol e a forma se mantém, com uma inclinação mais acentuada — $0,180 abaixo da linha contra $0,354 acima dela, porque a taxa em cache do cartão mais antigo, de $0,20, fica no mesmo lugar que a taxa em cache de contexto longo do 6.1. A travessia é um degrau, não uma inclinação, e a maneira mais barata de ver isso é atravessá-la por um fio. Uma solicitação totalmente sem cache de 271.000 tokens, com 1.000 tokens de saída, custa $0,552; com 273.000, custa $1,107. Sete décimos de um por cento a mais de tokens de entrada, 2,01 vezes o valor. Retire 2.000 tokens dessa solicitação e a fatura cai de $1,107 para $0,552 — menos de um por cento da entrada por metade do custo.

Nada nesta seção é sobre a janela do GPT-6.1 Sol ser grande. É sobre a janela ser grande o suficiente para alcançar um limite que custa mais do que o tamanho da janela compra.

O que realmente preenche 1.050.000 tokens

Um orçamento de contexto é composto de seis coisas, e elas não são igualmente cacheáveis. Participações aproximadas de uma requisição agêntica ilustrativa de 240.000 tokens; as proporções são nossas, as regras de cacheabilidade são do fornecedor, extraídas de seu guia de caching de prompt lido no mesmo dia.

• Conteúdo de sistema injetado pelo provedor e formatação de requisições — renderizados antes das suas mensagens, cobrados como entrada e explicitamente excluídos do comprimento mínimo cacheável. Não está sob seu controle, nem cabe a você reduzi-los.

• Suas instruções de desenvolvedor e de sistema, cerca de 6.000 tokens. Armazenável em cache. Este é o início do prefixo, portanto uma alteração aqui invalida tudo o que vem depois.

• Definições e esquemas de ferramentas, cerca de 14.000 tokens para a superfície de ferramentas hospedadas mais as suas funções. Podem ser armazenados em cache, e são a parte mais frágil do prefixo: o guia lista nomes de ferramentas, descrições, esquemas, ordenação e instruções específicas de ferramentas como elementos que deslocam o limite do prefixo.

• O corpus recuperado, cerca de 180.000 tokens. Armazenável em cache e, de longe, a maior linha. Só vale a pena armazená-lo em cache se ele for estável em bytes entre chamadas — um corpus remontado a cada requisição é um corpus de preço integral.

• O histórico acumulado — turnos anteriores e resultados de ferramentas — cerca de 30.000 tokens e crescendo. Pode ser armazenado em cache até a alteração mais recente; o resultado de ferramenta que chegou neste turno é novo e conta à taxa integral.

• Tokens de raciocínio — gerados, nunca armazenados em cache, cobrados como saída. Eles consomem janela e são invisíveis no corpo da resposta.

Duas notas operacionais decorrem diretamente dessa lista. Primeiro, as entradas de cache são mantidas em máquinas individuais: o guia diz que uma requisição pode reutilizar um prefixo "somente se ela chegar a uma máquina que contenha uma entrada correspondente que não expirou", e que o roteamento de overflow começa acima de aproximadamente 15 requisições por minuto. Um prefixo que é estável no seu código ainda pode não ser encontrado em produção. Segundo, o prefixo mínimo cacheável é de 1.024 tokens de entrada visíveis, e tokens de sistema ocultos não contam para isso — portanto, um pequeno prompt de sistema não é um prefixo cacheável, não importa quão grande seja a requisição ao seu redor.

O teto de saída é um orçamento separado, não uma segunda porção.

Um máximo de 128.000 tokens de saída não significa 128.000 tokens de resposta. O guia de raciocínio deixa explícito que max_output_tokens limita o total que o modelo gera, “incluindo tokens de raciocínio, tokens de saída visíveis e tokens de formatação não visíveis”, e que os tokens de raciocínio são cobrados como saída enquanto ocupam espaço na janela.

Isso faz do truncamento uma decisão de projeto, e não um caso extremo, por causa da forma como ele falha. Quando a geração atinge o limite, a resposta retorna com status incomplete e motivo max_output_tokens — e o guia adverte que isso "pode ocorrer antes que quaisquer tokens de saída visíveis sejam produzidos, o que significa que você pode incorrer em custos de tokens de entrada e de raciocínio sem receber uma resposta visível". Um orçamento que gasta toda a janela com entrada e deixa a reserva de saída ao acaso é um orçamento que pode cobrar uma requisição completa de contexto longo e não retornar nada que o chamador consiga analisar. a própria recomendação inicial do fornecedor é reservar pelo menos 25.000 tokens para raciocínio e saídas enquanto você ainda está medindo do que um prompt realmente precisa.

O GPT-6.1 Sol aprimora isto, e é uma das poucas linhas genuinamente específicas do 6.1 na versão. A sua escala de esforço de raciocínio abrange low, medium, high, xhigh e max, e as configurações none e minimal não são suportadas. O GPT-6 Sol aceita todas as seis. Portanto, não há nenhuma configuração no 6.1 que desligue o gasto de raciocínio, o padrão é medium, e o lado de saída do orçamento nunca é gratuito.

A redução pela metade da entrada em cache, lida onde a janela é mais ampla

A única tarifa no card do GPT-6.1 Sol que mudou em relação ao GPT-6 Sol é a entrada em cache: de $0,20 para $0,10 por milhão de tokens, que a página do modelo expressa como 5% da tarifa de entrada sem cache e que o guia de cache do fornecedor nomeia explicitamente como o caso 0,05x, em contraste com o 0,1x que a maioria dos modelos GPT-5.6 e posteriores usa para leitura. Entrada, gravações de cache e saída são idênticas nos dois cards, e os multiplicadores de contexto longo também são idênticos.

Para exatamente a carga de trabalho sobre a qual esta página trata, esse é o medidor certo a ter sido movido, e a razão é a composição de uma requisição longa, e não o seu tamanho. No trabalho de 300.000 tokens acima, 260.000 dos tokens de entrada são um prefixo em cache — 87 por cento de tudo o que a requisição envia. A linha em cache é, portanto, o maior medidor de entrada individual na fatura, o que é a propriedade geral do trabalho com contexto longo: quanto maior a janela que você usa, mais dela é um prefixo que você já enviou. Reduzir esse medidor pela metade vale US$ 0,052 nessa requisição.

E o penhasco tira de volta mais do que a redução pela metade concede, na mesma requisição. Se fosse precificado com as tarifas de contexto curto que teria pago abaixo da linha, o mesmo trabalho de 300.000 tokens no GPT-6.1 Sol custaria $0,166 em vez de $0,302 — um custo de cruzamento de $0,136, ou cerca de 2,6 vezes o que vale o único medidor alterado do lançamento. Acima da linha, a tarifa de cache marca $0,20, que não é um número novo nesta família: é o dobro do valor anunciado no cartão 6.1 e exatamente o que o GPT-6 Sol cobrava por uma leitura em cache abaixo da linha antes deste lançamento. Uma carga de trabalho em cache de contexto longo coleta a mudança anunciada e depois a devolve na fronteira, e a fronteira — não o modelo — é a causa.

Como dimensionar um orçamento de contexto

Como procedimento, na ordem em que as restrições se aplicam:

• Conte a requisição, não a estime.Envie via POST o payload exato — ferramentas, imagens, arquivos e tudo o mais — para o endpoint de contagem de tokens de entrada da API Responses. O guia é direto sobre o porquê: a contagem inclui tokens de formatação para papéis de mensagem e limites que nunca aparecem no texto que você pode tokenizar localmente, e estimativas locais como caracteres divididos por quatro são imprecisas para imagens, arquivos e esquemas.

• Reserve primeiro o lado da saída. Escolha max_output_tokens lembrando que ele cobre raciocínio, saída visível e formatação em conjunto, e comece pelo buffer de 25.000 tokens do fornecedor, em vez de começar do zero. Seu orçamento de entrada é a janela menos essa reserva, e o número novecentos e vinte e dois é a versão do fornecedor da mesma subtração.

• Calcule o preço do pedido nos dois lados de 272.000 antes de enviá-lo. O salto é grande o suficiente para que um pedido pensado para ficar logo abaixo da linha e um pedido pensado para ficar logo acima dela sejam produtos diferentes.

• Ordene o prefixo por estabilidade. Instruções, depois esquemas de ferramentas, depois o corpus, depois a transcrição. Tudo o que muda entre chamadas pertence ao fim, onde custa uma correspondência de prefixo em vez do cache inteiro.

• Limpe 1.024 tokens de entrada visíveis antes de esperar um cache. Abaixo desse mínimo, nada é armazenado em cache, e tokens ocultos do provedor não contam para isso.

• Verifique se a reutilização é plausível. Um prefixo deve ser reutilizado dentro do tempo de vida de 30 minutos do cache e deve chegar à máquina que contém a entrada; ambos estão descritos no guia e nenhum deles é uma propriedade do seu código.

• Meça novamente após qualquer alteração de modelo ou configuração. Mudar para o GPT-6.1 Sol elimina a posição de raciocínio desativado, o que altera a contagem de tokens de raciocínio e, portanto, o lado da saída do orçamento — e uma alteração no esforço de raciocínio, nas ferramentas, no esquema de saída estruturada ou no gerenciamento de contexto também pode deslocar um limite de prefixo e custar-lhe totalmente a tarifa de cache.

• Decida o que acontece quando a tarefa não encolher. A compactação é a saída documentada: uma solicitação do Responses pode definir context_management com um limiar de compactação, e o servidor substitui o conteúdo anterior da conversa por um item de compactação opaco que carrega o estado essencial adiante em menos tokens. É uma decisão de orçamento, e não um corte gratuito, porque o guia observa que a compactação "pode impedir a reutilização a partir do primeiro token alterado em diante" — uma passagem de compactação invalida o prefixo por trás dela.

A aritmética nesta página parte da geração que o GPT-6.1 Sol substitui, e esse degrau é o que pode ser chamado hoje: nosso cartão para openai/gpt-6-sol reporta uma janela de contexto de 1.050.000 tokens com 128.000 tokens de saída máxima nos preços de tabela da OpenAI com 0% de markup — o preço do fornecedor é o preço na página, e uma mudança do fornecedor chega lá no mesmo dia, e não na renovação. Nosso cartão não traz um campo próprio de entrada máxima, então o número de 922.000 tokens para esse modelo tem de vir da própria documentação do fornecedor, que é o que esta página tem usado em todo o texto. Para o que o cartão é útil é para dimensionamento: a janela e o teto de saída que ele de fato publica são os dois números que o procedimento de orçamento acima subtrai um do outro, e o degrau abaixo é aquele contra o qual você pode realmente executar esse procedimento enquanto o 6.1 ainda é novo. Ele está em https://www.orcarouter.ai/models/openai/gpt-6-sol.