GPT-6.1 Terra custa US$ 1 por milhão de tokens de entrada. Quanto custa uma tarefa concluída?

Diagrama editorial original de Ken Jo, baseado nas fontes listadas abaixo.

Uma fatura aparece de um lado da tela e um formulário contábil do outro. Ler o valor é uma tarefa. Escolher o fornecedor certo, preencher a moeda correta e reconhecer que o registro salvo realmente existe é uma tarefa maior. Essa diferença ganha importância quando um modelo de IA está fazendo os cliques.

A OpenAI apresentou o GPT-6.1 Terra em 26 de outubro de 2026, com preços padrão da API de US$ 1 por milhão de tokens de entrada, US$ 0,05 por milhão de tokens de entrada em cache e US$ 5 por milhão de tokens de saída. A empresa posiciona o modelo para raciocínio visual, uso do computador e escrita, e afirma que essas tarifas padrão são 50% inferiores às do GPT-5.6 Terra e do GPT-6.1 Sol. Anúncio oficial, ficha de sistema datada.

Preços menores tornam mais experimentos acessíveis. Decidir quais merecem virar um fluxo de trabalho exige outra medida: o custo de um resultado que você pode aceitar. Este guia apresenta três usos práticos, desenvolve um exemplo de custo com premissas explícitas e mostra como avaliar o modelo sem confundir uma chamada de ferramenta bem-sucedida com trabalho concluído.

O modelo escolhe uma ação dentro de um sistema que a executa

Terra é um modelo fornecido pela OpenAI, empresa responsável por ChatGPT e Codex. Selecioná-lo oferece à aplicação um conjunto específico de capacidades de linguagem e visão. A aplicação ao redor dele continua determinando qual tela pode ser observada, quais ferramentas podem ser chamadas e quais contas essas ferramentas podem acessar.

Considere a fatura como um fluxo ilustrativo. O modelo observa um formulário, propõe uma ação e recebe uma visão atualizada depois que a ferramenta a executa. Essa nova visão importa porque um clique aparentemente correto pode abrir outro painel, revelar um erro de validação ou deixar o salvamento incompleto. O fluxo precisa reconhecer o estado resultante antes de continuar.

O uso do computador passa a ser um ciclo, em vez de uma resposta isolada. Uma integração útil conecta observações, ações e verificações do estado resultante. Também define quando a tarefa deve parar, consultar uma pessoa ou informar que falta uma entrada necessária. Essas decisões fazem parte do projeto da aplicação, mesmo quando o modelo interpreta telas com competência.

A documentação de uso do computador da OpenAI, consultada em 27 de outubro, distingue os eventos de atividade do navegador do estado final de um turno completo. Ela também oferece controles para incluir capturas de tela na saída transmitida. O desenvolvedor pode usar esses eventos para tornar o progresso visível e, separadamente, verificar se o resultado solicitado existe.

Ciclo ilustrativo de uso do computador. A aplicação fornece ferramentas e permissões; a verificação de aceitação determina se o trabalho solicitado terminou. É uma explicação original, não uma captura de interface da OpenAI.

A tabela de preços é o começo do orçamento de uma carga de trabalho

As tarifas padrão do anúncio de 26 de outubro permitem uma comparação direta quando se mantêm as mesmas condições de cobrança. Entrada e saída têm preços diferentes, e a entrada em cache constitui uma categoria própria. Uma resposta longa ou um ciclo repetido de observações pode, portanto, alterar a conta mesmo que o número de solicitações dos usuários permaneça constante.

A ficha do modelo, consultada em 27 de outubro, informa condições adicionais de cobrança. Gravações no cache têm tarifas próprias, prompts acima de 272.000 tokens de entrada acionam ajustes de contexto longo e os modos de serviço podem alterar os preços. Use a tarifa aplicável à solicitação real, em vez de tratar o menor valor da tabela como uma tarifa universal.

No exemplo a seguir, suponha processamento padrão, nenhum uso de cache e solicitações abaixo do limite de contexto longo. Cada tentativa consome 10.000 tokens de entrada faturáveis e 1.000 tokens de saída faturáveis. O custo de tokens é, assim, US$ 0,01 + US$ 0,005 = US$ 0,015 por tentativa. Essas quantidades foram escolhidas para demonstrar a conta; não são medições do Terra nem de um fluxo de processamento de faturas.

Essa distinção sustenta um orçamento útil. Primeiro, determine a conta de uma tentativa sob premissas explícitas. Depois, pergunte quantas tentativas o fluxo exige, quais outros serviços utiliza e quanta revisão é necessária antes que alguém aceite o resultado.

Novas tentativas e revisão mudam o custo do trabalho aceito

Suponha um lote hipotético de 100 tarefas solicitadas. Em um cenário, o sistema realiza 100 tentativas e 90 tarefas são aceitas. Em outro, o trabalho de recuperação eleva o total a 150 tentativas e 95 tarefas são aceitas. O sucesso adicional tem valor, mas a comparação de custos mudou.

A tabela acrescenta um terceiro cenário: 30 itens recebem 20 segundos de revisão humana, a uma remuneração presumida de US$ 30 por hora. São 600 segundos, ou 10 minutos, com custo de US$ 5. Todas as quantidades de trabalho, de aceitação e de remuneração desta tabela são ilustrativas; nenhuma descreve um resultado medido do produto.

O denominador é o número de tarefas aceitas, não o de respostas geradas. Uma mensagem bem escrita anunciando a conclusão não aumenta esse denominador se o registro foi salvo incorretamente. Por outro lado, um fluxo que pede um breve esclarecimento pode entregar um resultado mais útil do que outro que continua com segurança aparente apesar de informações ausentes.

Podemos chamar esse trabalho adicional de conta da conclusão: os recursos necessários para transformar uma ação tentada em um resultado aceito. O preço de tokens é um item dessa conta. Cobranças de ferramentas, ambiente de execução, recuperação e revisão humana podem acrescentar outros. A tabela omite esses serviços adicionais para deixar a aritmética visível; uma estimativa de produção deve incluir aqueles que a integração realmente utiliza.

Nossa avaliação: o efeito mais valioso de um preço menor é abrir espaço para melhorar a conclusão das tarefas. A equipe pode comparar instruções, examinar falhas e testar um caminho de recuperação. Baratear uma resposta sem verificação tem menos valor do que usar a economia para produzir trabalho que exige menos reparos.

Comece com um registro de fatura em rascunho e um término bem definido

O primeiro cenário prático é um assistente de contas a pagar que prepara um registro em rascunho a partir de uma fatura fornecida. Use uma conta de teste e um conjunto delimitado de documentos de exemplo. Defina previamente os campos obrigatórios de fornecedor, moeda, valor e referência antes de pedir ao modelo que interaja com o formulário.

Nesse cenário, um resultado aceito é um rascunho salvo cujos campos correspondem à fonte e cujo identificador pode ser recuperado. Clicar em Salvar é um evento intermediário. O fluxo deve examinar o registro resultante ou o estado de confirmação e informar qualquer campo não resolvido, em vez de preenchê-lo com uma suposição plausível.

O teste deve conter documentos comuns e exemplos deliberadamente difíceis: uma moeda ambígua, a ausência do identificador do fornecedor ou um número de fatura já existente. Esses casos expõem modos de falha diferentes. Ler o texto corretamente, escolher a conta certa e evitar um registro duplicado são partes distintas do trabalho.

Mantenha o primeiro teste pequeno o bastante para revisar cada resultado. Se houver uma falha, identifique a primeira observação ou ação incorreta, em vez de reescrever toda a instrução de uma vez. Um diagnóstico mais específico ajuda a descobrir se o problema está na interpretação do documento, na navegação, nos dados da conta ou na verificação de aceitação.

Esse cenário ilustra um projeto de aplicação; não afirma que o Terra inclui um conector contábil nem que um produto contábil específico foi testado para este artigo. O modelo é um componente de um fluxo cujas ferramentas e regras de negócio precisam ser fornecidas.

A correspondência de catálogo testa o julgamento visual antes da ação

O segundo cenário é relacionar uma fotografia de produto a uma entrada existente no catálogo. A ficha do modelo consultada em 27 de outubro cita expressamente esse uso pretendido para o Terra. Para um varejista, o resultado útil pode ser uma correspondência proposta com informação suficiente para que o revisor diferencie uma semelhança visual do item correto.

Monte um pequeno conjunto de avaliação com correspondências fáceis, embalagens parecidas e fotos com detalhes ausentes. Mantenha os identificadores esperados do catálogo separados das instruções dadas ao modelo. Peça um identificador proposto e as características visíveis que sustentam a escolha, com uma opção explícita de não resolução quando a imagem for insuficiente.

Um resultado não resolvido pode ser o resultado correto. Se duas embalagens diferem apenas por uma informação que não aparece, o fluxo precisa de outra fotografia ou de um identificador não visual. Uma descrição fluente da embalagem não cria evidência ausente na entrada.

Comece com propostas de correspondência antes de permitir alterações no catálogo. Isso facilita a inspeção da regra de aceitação e produz um conjunto de erros que a equipe consegue entender. Se a aplicação acrescentar uma etapa de escrita posteriormente, avalie se a descrição em rascunho preserva os fatos verificados do catálogo, em vez de incluir detalhes não confirmados com base na semelhança visual.

Um portal legado torna a recuperação parte da tarefa

O terceiro cenário é preparar uma atualização em rascunho em um portal interno com interface de navegador. A tarefa pode envolver localizar um registro, alterar uma descrição fornecida e deixá-lo pronto para aprovação por uma pessoa. O benefício vem da ligação entre uma solicitação de negócio compreensível e uma sequência de ações na interface.

Os casos difíceis frequentemente envolvem o estado do sistema. Uma sessão pode expirar, um campo obrigatório pode surgir após uma seleção anterior ou uma página pode demorar mais que o esperado para atualizar. Uma avaliação útil registra como o fluxo reage a essas condições, em vez de contar apenas o caminho mais simples de navegação.

Defina um limite de recuperação antes do teste. Por exemplo, a aplicação pode permitir mais uma observação após um salvamento incerto e parar para revisão se o resultado continuar pouco claro. Essa é uma escolha ilustrativa de política, não um limite do Terra. Ela oferece à equipe um comportamento delimitado para testar e uma forma de evitar que um ciclo improdutivo consuma recursos.

Também diferencie falhas de integração de falhas do modelo. Uma ferramenta que não alcança a página pretendida, uma conta sem permissão de edição e um modelo que escolhe o controle errado exigem soluções diferentes. Manter essas categorias visíveis torna estimativas de custo e melhorias de qualidade mais úteis.

A disponibilidade indica por onde começar, não o que toda conta pode operar

O lançamento de 26 de outubro anuncia o Terra no ChatGPT Work e no Codex para Plus, Pro, Enterprise e Edu, além do identificador de API gpt-6.1-terra. Esses são caminhos de acesso ao modelo. As ferramentas e permissões disponíveis em determinado fluxo continuam dependendo do produto, da conta e da integração utilizados.

Para desenvolvedores, a ficha consultada em 27 de outubro especifica a Responses API para chamadas de ferramentas e o esforço de raciocínio padrão medium. Registre o modelo e a configuração de raciocínio escolhidos durante a avaliação para comparar duas execuções de forma significativa. Alterar simultaneamente modelo, instruções e ambiente de ferramentas dificulta a interpretação de diferenças nos resultados.

Para uma equipe que usa Work ou Codex, comece por um fluxo já suportado e examine os controles disponíveis. Em uma aplicação própria, use a documentação atual de integração de uso do computador para configurar o ambiente de execução e as ações permitidas. O identificador do modelo, sozinho, não cria uma conexão autenticada com as aplicações da empresa.

Compare configurações usando as mesmas tarefas aceitas

Um primeiro teste útil é pequeno o bastante para ser examinado e variado o suficiente para incluir as condições que o fluxo encontrará. Escolha a regra de aceitação antes de ver os resultados gerados. O procedimento abaixo é uma proposta de avaliação, não um resultado de benchmark.

1. Escolha uma tarefa delimitada. Defina a saída necessária e quem decide se ela é aceitável. No primeiro teste, prefira uma ação em rascunho ou em ambiente de teste.
2. Prepare um conjunto fixo de casos. Inclua entradas comuns, informações ausentes e interrupções relevantes da interface. Mantenha os resultados esperados fora das instruções do modelo.
3. Registre a configuração. Guarde o identificador do modelo, o nível de raciocínio, as instruções, a versão das ferramentas e as permissões relevantes da conta.
4. Defina regras de parada e recuperação. Especifique quando outra observação é permitida, quando uma nova tentativa ajuda e quando uma pessoa deve resolver a incerteza.
5. Capture resultados observáveis. Registre resultados aceitos, incorretos e não resolvidos, tentativas, tempo decorrido e uso faturado. O estado de uma operação de ferramenta é apenas parte desse registro.
6. Acrescente os custos operacionais reais. Inclua cobranças aplicáveis de ferramentas e ambiente e o tempo de revisão medido. Divida pelas tarefas aceitas, usando definições consistentes.
7. Altere uma variável relevante. Compare uma instrução revisada ou outro nível de raciocínio nos mesmos casos e examine quais falhas mudaram antes de ampliar o teste.

Modelo de custo proposto: some os recursos realmente consumidos pelo fluxo e divida pelas tarefas aceitas. Os componentes formam um método de avaliação, não medições operacionais publicadas do Terra.

O registro resultante é útil mesmo quando o primeiro teste decepciona. Ele identifica se a melhoria deve focar interpretação visual, desenho do fluxo, confiabilidade das ferramentas ou quantidade de reparo humano. É uma base muito melhor para decidir o que automatizar depois do que apenas o custo médio de uma solicitação.

O uso mais barato do computador importa quando concluir o trabalho fica mais acessível

Os preços padrão menores do Terra criam uma oportunidade para testar com mais cuidado e realizar mais trabalho dentro do orçamento. A pergunta de negócio é se uma integração específica consegue transformar essa oportunidade em resultados aceitos com esforço administrável de revisão e recuperação.

Um modelo capaz de ler uma tela e escolher um clique é útil. Um fluxo que mostra o que mudou, reconhece quando terminou e contabiliza o esforço necessário para chegar lá é algo que a equipe consegue avaliar e melhorar.

Fontes

• Apresentação do GPT-6.1 Terra, OpenAI, 26 de outubro de 2026: posicionamento, preços padrão de lançamento e caminhos de acesso.
• Ficha de sistema do GPT-6.1 Terra, OpenAI, 26 de outubro de 2026: lançamento datado e contexto das avaliações.
• Ficha do modelo GPT-6.1 Terra, consultada em 27 de outubro de 2026: identificador, endpoint para ferramentas, configuração de raciocínio e condições de cobrança.
• Documentação de integração de uso do computador, consultada em 27 de outubro de 2026: atividade do navegador, capturas de tela e mecânica da integração.

Os três cenários de fluxo, as entradas de custo e o procedimento de avaliação são ilustrativos. Os cálculos em dólares usam as tarifas padrão indicadas e premissas escolhidas explicitamente; não são medições de latência, precisão ou custo operacional.

---

Recomendação do Telli.sh: Mantenha as anotações dos testes, os materiais de referência e as decisões por trás de cada revisão do fluxo fáceis de consultar. Crie uma conta no Telli.sh para organizar suas anotações de avaliação.