---
title: "Assinatura e API não contam a mesma história"
author: "Ricardo Pupo Larguesa"
date: "2026-10-30 17:44:00-03"
category: "Opinião"
url: "https://aintuicao.scale.press/post/2026/10/30/assinatura-e-api-nao-contam-a-mesma-historia"
---

Os modelos da OpenAI voltaram à fronteira de melhor custo-benefício de um gráfico sem que suas respostas tivessem melhorado. O que mudou foi o cálculo do MyPriors, que passou a considerar resets de limites nas assinaturas. Esse ajuste faz sentido para quem escolhe um plano individual, mas não se aplica a quem integra o modelo a um produto via API. Misturar as duas contas pode fazer um benefício comercial parecer disponível para uma aplicação que não tem acesso a ele.

O episódio apareceu em uma [publicação de Adam Holter](https://x.com/AdamHoltererer/status/2115480857586684067), criador do MyPriors, em 28 de outubro. Ele anunciou que passaria a considerar os resets de limites no cálculo de custo dos planos. Mais tarde, [reverteu a configuração padrão](https://x.com/AdamHoltererer/status/2115554610685374617). Os resets continuaram disponíveis como opção, mas deixaram de entrar automaticamente na comparação.

Concordo com essa separação. Um comparativo para quem escolhe uma assinatura individual responde a uma pergunta diferente daquela feita por quem desenvolve um produto com IA para vários usuários. Misturar as duas contas pode fazer uma vantagem comercial parecer disponível para uma aplicação que não tem acesso a ela.

Essa discussão também toca num erro que considero mais importante do que a escolha de qualquer configuração do gráfico. Muita gente decide qual IA usar pela marca. Eu prefiro começar pelos testes e pelo custo de realizar o trabalho que preciso entregar.

## O que um reset muda

Assinaturas de IA têm limites de uso. Ao atingir determinada franquia, o usuário pode precisar esperar sua renovação ou contratar capacidade adicional, conforme o plano. Um reset extraordinário renova limites antes do momento em que isso ocorreria normalmente.

Na apresentação, Holter usou a informação de que os limites do Codex haviam sido reiniciados 12 vezes em 30 dias. A aplicação da regra de resets do site resultava em um custo estimado por tarefa dividido por aproximadamente 2,75. Esse cálculo pressupõe o uso integral da franquia. A mensalidade permanecia igual.

O [MyPriors](https://mypriors.com/) usa dados de franquias de assinaturas para reestimar o custo das tarefas. Mais capacidade disponível reduz o custo unitário nesse cenário de uso integral. Não é uma medição de quanto cada assinante efetivamente gastou para realizar seu trabalho.

O gráfico combinava uma nota de qualidade no eixo vertical com custo por tarefa no horizontal. Ao considerar mais uso pelo mesmo pagamento, os pontos se deslocavam para a esquerda. A nota de qualidade permanecia igual.

A chamada fronteira de Pareto reúne as alternativas que não podem ser substituídas por outra opção melhor em um critério sem perder no outro. Nesse gráfico, interessa encontrar modelos que ofereçam mais qualidade sem custar mais, ou que custem menos sem perder qualidade. Quando aparece uma alternativa assim, a anterior deixa de fazer parte da fronteira.

Portanto, voltar à fronteira não significa necessariamente que o modelo passou a raciocinar melhor. Pode significar que uma condição de acesso ficou mais vantajosa ou que o cálculo passou a reconhecer um benefício que antes estava de fora.

O valor desse benefício depende do uso. Quem precisa continuar trabalhando depois de esgotar a franquia pode aproveitar muito um reset. Quem já fazia tudo de que precisava dentro do limite original não passa a produzir mais apenas porque recebeu capacidade adicional.

No meu caso, os planos menores, na faixa de US$ 20, chegam a limitar o trabalho. Por isso, recorro a planos mais caros. A quantidade de uso disponível tem valor concreto para mim. Mas essa é a conta da assinatura que eu utilizo, não a conta de uma solução empresarial que estou desenvolvendo.

## Minha assinatura não é a infraestrutura do meu produto

Uma coisa é contratar acesso a um assistente para trabalhar. Outra é incorporar um modelo a um sistema que atende diversos usuários, recebe solicitações de clientes e executa processos por meio de uma API, a interface pela qual o software se comunica com o serviço de IA.

Nesse segundo caso, preciso estimar quanto custa processar as tarefas da aplicação. O reset concedido a uma assinatura do Codex não se transforma em crédito para as chamadas de API desse produto.

A própria [documentação de preços do Codex](https://developers.openai.com/codex/pricing) distingue os planos de assinatura do acesso com chave de API. Há também assinaturas empresariais, contratadas por usuário. O ponto da comparação é a modalidade de acesso utilizada pela solução, não simplesmente se quem paga é uma pessoa ou uma empresa.

É preciso manter duas análises separadas. Uma compara modelos pelo custo das tarefas executadas via API, com preços e condições de processamento identificados. A outra compara assinaturas para uso individual, considerando mensalidade, limites e os benefícios efetivamente disponíveis naquele plano.

Na comparação de assinaturas, os resets têm lugar. Faz sentido mostrar quanto alteram a capacidade disponível e permitir que o usuário avalie o cenário que corresponde ao seu uso. Também faz sentido distinguir a capacidade que o plano oferece daquela que o assinante consegue consumir.

Para uma aplicação multiusuário que integra IA por API, esse benefício específico fica fora da conta. É por isso que considero melhor deixá-lo como uma opção claramente identificada, em vez de tratá-lo como condição geral de custo do modelo.

## Por que eu olho o custo por tarefa

Uso bastante o Artificial Analysis como referência. Confio especialmente no critério de custo por tarefa porque minha percepção, nos testes que realizo, costuma coincidir com o que encontro ali.

O preço por token, isoladamente, não informa quanto custará concluir um trabalho. Tokens são as unidades de conteúdo processadas e geradas pelo modelo. Dois modelos podem cobrar valores diferentes por essas unidades e também consumir quantidades muito diferentes para responder à mesma solicitação.

Um modelo com tarifa menor pode produzir uma resposta mais longa, gastar mais tokens de raciocínio ou exigir novas tentativas. Outro pode cobrar mais por token e resolver o problema com menos consumo. A tarefa permite examinar uma parte dessa diferença que a tabela de preços não mostra sozinha.

A [metodologia do Artificial Analysis](https://artificialanalysis.ai/methodology) descreve o custo por tarefa como uma média ponderada sobre o trabalho de seu índice. O cálculo combina o consumo de tokens de entrada, conteúdo em cache e saída com os respectivos preços. As ponderações seguem os benchmarks que compõem o índice.

Isso também significa que o custo agregado depende do conjunto de tarefas escolhido. Um índice com determinado peso para programação, ciência e trabalho profissional não reproduz automaticamente a distribuição de uso de um sistema de atendimento ou de análise de documentos.

Uso essa referência para selecionar candidatos. Depois, quero saber quanto custa o trabalho específico da aplicação e qual resultado cada candidato entrega.

## Uma nota geral não escolhe o especialista

Minha confiança no índice geral de inteligência é menor. Prefiro examinar os benchmarks que têm relação com a tarefa em questão e ordenar os modelos por essa visão.

Costumo usar minha assistente de IA justamente para isso. Peço que investigue quais avaliações são relevantes para determinado trabalho, examine o que elas medem e organize um ranking especializado que me ajude a escolher os modelos que vale testar.

Se a aplicação precisa extrair informações de documentos, quero avaliar se os campos foram identificados corretamente, se há informações inventadas e se o formato exigido foi respeitado. Se precisa escrever código, interessam o funcionamento da solução, os testes e o trabalho necessário para corrigir a entrega. Uma média geral pode esconder diferenças que são decisivas em cada caso.

Também não basta escolher um benchmark cujo título parece adequado. É preciso olhar as tarefas, a forma de avaliação e a configuração usada. Um resultado obtido com mais tempo de raciocínio ou ferramentas adicionais descreve aquela combinação, não qualquer chamada ao mesmo modelo.

Esse é o papel que atribuo aos rankings. Eles organizam evidências e reduzem o número de opções que preciso experimentar. A escolha final depende do comportamento na tarefa real.

## Eficiência e preço são coisas diferentes

O custo financeiro não é uma propriedade exclusiva do modelo. Ele combina o consumo necessário para executar a tarefa com o preço cobrado pelo provedor. A [tabela de API da OpenAI](https://developers.openai.com/api/docs/pricing), por exemplo, distingue preços de entrada, saída e conteúdo em cache, além de condições de processamento.

Se o provedor reduz sua tarifa, o custo por tarefa pode cair sem que o modelo passe a consumir menos. Se o modelo precisa de menos processamento para entregar um resultado equivalente, há um ganho de eficiência. Se uma assinatura recebe um reset, muda a capacidade disponível naquela contratação.

As situações têm efeitos econômicos diferentes. Uma redução de tarifa da API entra diretamente na conta de uma aplicação que usa aquela API. Um benefício da assinatura só entra na conta de quem opera por essa modalidade.

Disputa por clientes e promoções podem influenciar condições de acesso. Por isso, não usaria um benefício comercial circunstancial como medida de eficiência técnica. Para comparar o gasto, registraria o preço vigente. Para comparar eficiência, examinaria os recursos consumidos e o resultado obtido.

A preferência por preços públicos de API como referência principal, nesse contexto, vem da correspondência com a forma de contratação do produto. Não da ideia de que as tarifas estejam isoladas do mercado.

## Os testes também constroem a Engenharia de Prompt

O principal erro, para mim, é escolher a marca antes de medir o resultado. Um modelo conhecido pode ser um bom candidato. A reputação, porém, não informa se ele atenderá às particularidades do processo da empresa nem quanto custará chegar a uma entrega aceitável.

Procuro começar com uma amostra de tarefas representativas e critérios definidos antes de observar as respostas. Os testes precisam incluir os casos frequentes e situações que costumam provocar erros. A comparação deve registrar acerto, tempo, consumo e necessidade de intervenção humana, conforme o que importa para aquele processo.

Pense numa aplicação que lê pedidos recebidos por e-mail e prepara os dados para um sistema de gestão. Uma resposta bem escrita pouco ajuda se o modelo trocar a quantidade, inventar um código de produto ou preencher uma informação que deveria ter solicitado ao cliente. São falhas que precisam aparecer na avaliação.

É nesse trabalho que a Engenharia de Prompt também se desenvolve. Os testes revelam quais instruções estão ambíguas, que contexto falta e quais regras de negócio precisam ser explicitadas. Permitem descobrir quando é necessário fornecer exemplos, impor um formato de saída ou orientar o uso de uma ferramenta.

Não vejo o teste apenas como uma competição para escolher o vencedor e encerrar o assunto. Ele ajuda a construir as especificidades que a solução empresarial demanda. Modelo, instruções e ferramentas precisam funcionar juntos.

A [documentação de boas práticas de avaliação da OpenAI](https://developers.openai.com/api/docs/guides/evaluation-best-practices) recomenda testes específicos da tarefa e avaliação ao longo do desenvolvimento. É uma abordagem mais útil do que decidir que a aplicação funciona porque algumas respostas iniciais pareceram convincentes.

Ao ajustar os prompts, também é necessário verificar o resultado em casos que não foram usados para fazer aqueles ajustes. Melhorar nas mesmas perguntas que orientaram a mudança não basta para demonstrar que a solução ficou melhor no trabalho que encontrará depois.

Na conta final, o que me interessa é o custo de uma entrega correta e utilizável. Se uma tentativa barata exige repetição e correção manual, esse trabalho faz parte do custo. A média de gasto por tarefa de um benchmark e o custo por tarefa aprovada na operação respondem a perguntas relacionadas, mas não idênticas.

## A comparação precisa servir à decisão

O episódio do MyPriors é interessante porque torna visível uma escolha que costuma ficar escondida nas comparações. O mesmo modelo pode aparecer em outra posição quando mudamos a modalidade de contratação ou as condições incluídas no cálculo.

Para escolher minha assinatura, quero conhecer os limites e os benefícios que posso aproveitar. Para integrar IA a um produto, quero avaliar a qualidade e o custo das tarefas executadas pela API que vou contratar. Para escolher entre modelos, quero benchmarks relevantes e testes preliminares com resultados objetivos.

Já defendi essa lógica ao escrever sobre [a inteligência de um agente que investiga dados com ferramentas simples](https://aintuicao.scale.press/post/2026/10/22/a-inteligencia-esta-em-quem-procura). Acrescentar tecnologia ou contratar algo mais sofisticado precisa melhorar o trabalho de uma forma que justifique o custo.

Continuarei usando rankings para orientar a investigação e planos mais caros quando a franquia menor atrapalhar meu trabalho. Mas, numa solução empresarial, a escolha do modelo precisa sobreviver aos testes do processo que ele vai executar. É ali que descubro quanto custa obter o resultado necessário e quais ajustes de Engenharia de Prompt ainda faltam. A marca, sozinha, não responde a nenhuma dessas perguntas.

## Referências


- Holter, Adam. Anúncio da inclusão de resets no cálculo do MyPriors, 28 de outubro de 2026. [https://x.com/AdamHoltererer/status/2115480857586684067](https://x.com/AdamHoltererer/status/2115480857586684067)
- Holter, Adam. Reversão da configuração padrão, 28 de outubro de 2026. [https://x.com/AdamHoltererer/status/2115554610685374617](https://x.com/AdamHoltererer/status/2115554610685374617)
- Artificial Analysis. Benchmarking methodology, definição de Cost per Task. [https://artificialanalysis.ai/methodology](https://artificialanalysis.ai/methodology)
- OpenAI. Codex pricing, assinaturas e acesso por chave de API. [https://developers.openai.com/codex/pricing](https://developers.openai.com/codex/pricing)
- OpenAI. API pricing. [https://developers.openai.com/api/docs/pricing](https://developers.openai.com/api/docs/pricing)
- OpenAI. Evaluation best practices. [https://developers.openai.com/api/docs/guides/evaluation-best-practices](https://developers.openai.com/api/docs/guides/evaluation-best-practices)
- Larguesa, Ricardo Pupo. A inteligência está em quem procura. AIntuição, 22 de outubro de 2026. [https://aintuicao.scale.press/post/2026/10/22/a-inteligencia-esta-em-quem-procura](https://aintuicao.scale.press/post/2026/10/22/a-inteligencia-esta-em-quem-procura)
- MyPriors. Dados públicos e metodologia do custo por assinatura, consultados em 29 de outubro de 2026. [https://mypriors.com/api/snapshot?view=core](https://mypriors.com/api/snapshot?view=core)