Preço por token cai, mas o custo de IA sobe

Uma empresa pode reduzir o preço por token e ainda aumentar seu custo de IA. A keyword custo de IA só fica inteligível quando a conta deixa de olhar para a tarifa isolada e passa a acompanhar o workload, a tarefa concluída, a rota e o valor efetivamente desembolsado.

O preço de uma unidade caiu. A cesta comprada mudou.

O custo de IA é uma multiplicação com péssimo senso de humor: preço por token vezes tokens consumidos, mais o trabalho que a arquitetura esconde até o fechamento. Uma request mais barata pode estimular mais requests, contextos maiores, novas funções e tentativas automáticas. O preço por token não precisa subir para a fatura crescer.

A análise AI Token Price Collapse, But AI Costs Are Rising, publicada pela GTM Newsletter, serve como fonte secundária e ponto de partida. Não serve como prova primária de cada número. A tese deste artigo é mais estreita: CTOs e CFOs devem administrar custo efetivo por workload, com volume, qualidade da rota, contexto, retries, operação, moeda e contrato no mesmo quadro.

Por que o preço por token pode cair enquanto o custo de IA sobe?

O custo de IA sobe quando a redução do preço por token é menor que o aumento do trabalho enviado ao sistema ou que os custos necessários para concluir esse trabalho. A relação não é uma lei universal. Ela aparece quando o produto amplia o uso, a aplicação carrega mais contexto, a operação repete requests ou o contrato adiciona despesas fora da tabela.

O preço por token responde a uma pergunta estreita: quanto custa processar uma unidade naquela rota, naquele contrato e naquela moeda. A fatura responde a outra: quanto trabalho a empresa enviou, quantas vezes enviou e quantas tentativas foram necessárias.

A diferença deixa de ser acadêmica quando uma função de resumo passa a rodar em todas as interações. O contexto cresce. Uma segunda tentativa é habilitada para requests lentos. Cada decisão pode fazer sentido isoladamente, mas a conta observa o conjunto.

A velha ironia da eficiência aparece de novo: quando o pedágio fica barato, mais gente pega a estrada.

O preço por token menor reduz a fatura se o volume, o comportamento do produto, a rota e o contrato permanecerem estáveis. Essa é a condição. Sem medição, a empresa chama de economia o que talvez seja apenas uma expansão de compra.

O que o preço por token não mostra sobre o custo de IA?

O preço por token não mostra o volume efetivo, a composição entre entrada e saída, o tamanho do contexto, as requests repetidas, a operação ou a contratação em moeda estrangeira. Para comparar workloads, a unidade útil é o custo por tarefa concluída. Preço por token é uma dimensão da conta, não a conta inteira.

Uma equipe pode comemorar tokens de entrada mais baratos e ignorar que cada request agora carrega o histórico completo da conversa. Outra pode elevar o limite de saída para evitar respostas cortadas. A tarifa caiu. O pacote ficou maior.

O orçamento precisa separar cinco camadas:

1. Preço por token: tarifa contratada para tokens de entrada e saída.
2. Volume: requests, tokens e tarefas concluídas no período.
3. Qualidade da request: sucesso, retries, fallback e requests descartados.
4. Operação: observabilidade, cache, filas, processamento de contexto e incidentes.
5. Custo efetivo: contratação, câmbio, tributos aplicáveis, taxas e créditos capturados ou perdidos.

A terceira camada costuma ser silenciosa. Uma request que falha e é repetida aparece como consumo. O dashboard não pergunta se a primeira resposta serviu ao usuário. O orçamento deveria perguntar.

O benchmark de LLMs orientado a CFOs coloca score técnico e economia na mesma conversa. Este artigo avança por outra trilha: a melhor tarifa falha quando o sistema não mede o trabalho desperdiçado em volta dela.

A tabela é um antídoto contra a planilha que contém apenas a coluna “preço por milhão”.

Quando a queda do preço por token expande o uso?

A queda do preço por token expande o uso quando reduz o custo percebido de uma tarefa e libera produto, engenharia ou operações para enviar mais trabalho ao modelo. O efeito depende da demanda reprimida, do desenho da aplicação e do comportamento dos usuários. Deve ser medido como hipótese, nunca tratado como destino.

Um produto que usava IA apenas no fechamento de um ticket pode passar a usar IA na triagem, na busca, no rascunho e na auditoria. A tarifa permanece menor. Os pontos de consumo se multiplicam.

O mesmo ocorre dentro de uma request. Contextos maiores reduzem o pré-processamento fora do modelo, mas transferem o trabalho para a inferência. A equipe pode aceitar essa troca quando precisão ou velocidade de desenvolvimento justificam a despesa. O orçamento precisa registrar a escolha.

A expansão costuma aparecer em quatro sinais: requests por usuário, tokens por request, requests automáticos e usuários ou casos de uso. Nenhum sinal prova causalidade sozinho.

A atribuição exige uma linha de base com data, rota, workload e volume antes da mudança. Sem essa linha, “o consumo cresceu” é observação, não explicação.

A figura técnica deste artigo organiza essa atribuição sem inventar valores de mercado: baseline, classificação, rota, contexto, retries, operação e custo efetivo aparecem como etapas da mesma conta.

Onde retries, contexto e roteamento comem o orçamento?

Retries, contexto e roteamento elevam o custo quando a empresa paga por trabalho que não melhora a tarefa concluída. Um retry pode recuperar disponibilidade. Um contexto maior pode melhorar a resposta. Uma rota mais barata pode falhar no workload errado. O diagnóstico depende de resultado, não de tarifa isolada.

Retries são o caso mais fácil de subestimar. Uma política de repetição protege contra falhas transitórias, mas precisa de limite, classificação e telemetria. Sem isso, um timeout pode gerar duas ou três cobranças, conforme a política de retry e o comportamento de faturamento do provedor.

Fallback também tem custo. Migrar uma request para outra rota pode preservar o serviço, mas a empresa precisa registrar quantas requests seguiram o caminho secundário, por qual motivo e com qual resultado. Failover é uma apólice. Apólices precisam de sinistro contabilizado.

Contexto é outra forma de inflação invisível. Instruções, histórico e documentos podem ser reenviados em requests sucessivos porque a aplicação não definiu compactação, cache ou seleção de trechos. O usuário vê uma resposta. A empresa paga a biblioteca inteira.

O roteamento por preço pode produzir falsa economia. Quando uma request sensível à latência segue para uma rota lenta, surgem timeouts, retries e abandono. A rota de menor tarifa foi escolhida; a tarefa mais cara foi fabricada.

A página do Nexforce Router descreve roteamento por custo, performance e latência, fallback automático, limites de orçamento, analytics e pagamento local. O ponto aqui não é atribuir ao produto uma promessa de economia automática. É tornar a decisão de rota observável e auditável.

Por que o custo efetivo exige uma condição brasileira?

No modo CLIENTE, a contratação direta de um fornecedor estrangeiro é uma hipótese de análise, não uma alíquota pronta. A qualificação da operação, a separação contratual, a jurisdição do beneficiário, o município e o regime do comprador definem quais linhas entram no custo efetivo. O modo de distribuidor ou revenda segue outra lógica, e seus entendimentos não migram para o cliente final.

A tarifa em moeda estrangeira não é uma taxa universal de saída de caixa. No Brasil, o comprador direto precisa classificar a operação antes de calcular qualquer tributo. Na Solução de Consulta Cosit nº 191, de 23 de março de 2017, a Receita Federal tratou, com base nos fatos apresentados pelo interessado, de autorizações de uso e acesso a SaaS e classificou aquela operação específica como serviço técnico para fins de IRRF e CIDE. Isso não transforma todo SaaS em uma categoria fiscal automática. Uma licença pura, segregada e sem transferência de tecnologia segue a exceção prevista no art. 2º, §1º-A, da Lei 10.168/2000. A classificação vence o atalho.

Classificação primeiro.

Para o modo CLIENTE, o mapa de validação começa no RIR/2018, arts. 767 e 786, para IRRF e gross-up; na Lei 10.168/2000, art. 2º, §§1º-A e 2º, para CIDE; na Lei 10.865/2004, arts. 7º e 8º, para PIS/COFINS-Importação; na LC 116/2003, arts. 1º, §1º, e 6º, §2º, I, para ISS; e no Decreto 6.306/2007, art. 15-B, XXIV, para IOF-câmbio. A aplicação depende do contrato e da regra vigente.

Este recorte descreve o regime vigente em 8 de agosto de 2026. A transição da Lei Complementar 214/2025 extingue PIS/COFINS em 2027 e substitui sua incidência pela CBS; o ISS é reduzido gradualmente de 2029 a 2032 e deixa de existir em 2033. A alíquota plena de CBS/IBS ainda depende da definição aplicável. Qualquer percentual futuro deve ser identificado como premissa de planejamento, não como alíquota vigente.

Este artigo não fixa alíquotas nem presume que uma contratação de IA tenha um tratamento fiscal único. A natureza da operação, o contrato, o fornecedor e a entidade contratante precisam ser examinados antes de qualquer cálculo de custo efetivo. A fonte oficial citada nas referências serve para consulta normativa, não substitui a análise do caso concreto.

A conta brasileira deve registrar entidade, fornecedor, natureza do serviço, contrato, moeda, data de câmbio, eventual retenção e tratamento fiscal validado. Nenhuma fatura deve receber um multiplicador fixo por atalho editorial. O enquadramento depende das premissas da operação, e referências internas de produto não substituem a fonte pública nem a validação fiscal do contrato concreto.

Qual matriz mede o custo de IA real?

A matriz correta acompanha cada workload desde a request até a tarefa concluída. Ela registra consumo, rota, qualidade e custo de contratação no mesmo identificador. Assim, a empresa separa crescimento de uso, degradação de rota, desperdício operacional e efeito cambial, em vez de atribuir toda alta ao preço do modelo.

A operação pode começar com uma unidade simples: projeto, chave, workload ou período. O importante é manter a unidade estável o bastante para comparar antes e depois.

Comece pela tarefa concluída.

A régua precisa ser estável antes da próxima mudança de preço por token. Sem isso, a equipe mede ruído e chama o ruído de economia. Quando a definição inclui sucesso, rota, contexto, retries e moeda, a comparação deixa de premiar a tarifa nominal e passa a mostrar o custo que realmente acompanha o workload.

1. Definir a tarefa concluída. Uma resposta gerada não é necessariamente uma tarefa resolvida.
2. Registrar a rota. Modelo, provedor, região, versão da política e motivo do fallback entram no mesmo evento.
3. Separar entrada e saída. Tokens de contexto e de resposta têm comportamentos diferentes.
4. Contar retries. Tentativa inicial, repetição, timeout, erro e resultado final ficam visíveis.
5. Adicionar a operação. Cache, observabilidade, filas e processamento auxiliar recebem centro de custo ou estimativa rastreável.
6. Converter para custo efetivo. A moeda de contratação e a moeda de reporte aparecem juntas, com data e premissas.
7. Comparar por workload. Preço por token é uma dimensão. Custo por tarefa concluída é a decisão.

A matriz não precisa começar perfeita. Precisa começar antes da próxima mudança de preço por token.

O que o roteamento resolve, e o que ele não resolve?

O roteamento resolve a falta de controle sobre qual request segue para qual modelo, sob quais regras e com qual resultado. Ele não transforma volume desperdiçado em eficiência nem corrige uma definição ruim de sucesso. Seu papel é tornar custo, performance, disponibilidade e limites decisões operacionais observáveis.

Roteamento importa.

Um gateway de LLM pode distribuir requests e escolher rotas por custo, latência ou performance. Também pode aplicar limites de gasto, registrar requests e acionar failover, quando essas capacidades estão documentadas na solução adotada. O valor econômico aparece quando a política é explícita e a empresa consegue comparar o resultado da rota com a tarefa concluída.

Requests de baixa complexidade não precisam consumir a mesma rota de uma tarefa que exige contexto amplo. Um caminho sensível à latência não deve ser otimizado por preço nominal se o atraso provoca repetição. Um projeto que atingiu seu limite precisa parar, alertar ou mudar de política.

O Router não deve ser usado como desculpa para apagar a complexidade. Limite de gasto sem medição de tarefa pode cortar um workload crítico. Failover sem análise de qualidade pode preservar disponibilidade enquanto degrada a resposta.

A arquitetura madura trata roteamento como política econômica aplicada em tempo real. A pergunta deixa de ser “qual modelo é mais barato?” e passa a ser “qual rota entrega esta tarefa dentro do orçamento e do nível de serviço aceitos?”

O argumento a favor do preço por token está errado?

O melhor argumento contrário diz que, se o preço por token cai e o workload permanece igual, o custo total cai. Sob essas premissas, o argumento está correto. A divergência começa quando “workload igual” é apenas uma hipótese, sem linha de base para volume, contexto, retries, rota, distribuição de entrada e saída e condição contratual.

O steelman merece ser preservado. Operação com volume fixo, mesma taxa de sucesso, mesmo contexto e mesma contratação captura a queda do preço por token. Negar isso transforma uma tese boa em torcida.

A conta cai.

A conclusão muda quando a cesta comprada muda: o time pode abrir uma função antes bloqueada pelo orçamento, trocar um request por três etapas ou anexar mais contexto para reduzir recuperação, enquanto a equipe financeira continua comparando apenas o preço por token nominal publicado na tabela do fornecedor.

Quem consegue provar estabilidade deve capturar a redução. Quem não consegue provar estabilidade deve tratar a queda como oportunidade de investigar o workload. O argumento contrário vence no ambiente controlado; perde quando a empresa confunde preço por token com quantidade de trabalho comprado.

Perguntas frequentes sobre preço por token e custo de IA

A resposta curta é que o preço por token informa a tarifa, enquanto o custo de IA mede o trabalho concluído e tudo o que foi necessário para concluí-lo. A diferença inclui volume, contexto, retries, rota, operação, moeda e contrato. A empresa que não mede essas camadas conhece o preço de tabela, mas não conhece sua despesa real.

Token barato sempre reduz a fatura?

Não. O preço por token reduz a tarifa da request quando a rota e o contrato são os mesmos. A fatura sobe quando volume, contexto, respostas, retries ou quantidade de tarefas crescem mais rápido que a redução de preço. A única forma de confirmar economia é comparar a linha de base com o workload posterior.

Qual métrica deve entrar no orçamento?

A métrica principal deve ser o custo efetivo por workload ou por tarefa concluída. Preço por token continua útil para negociar, simular e comparar rotas, mas não mostra requests repetidas, contexto excessivo, operação, moeda ou condições contratuais. O orçamento deve manter essas dimensões separadas antes de agregá-las.

A expansão de uso acontece em toda queda de preço?

Não. A expansão depende da demanda reprimida, do produto, dos usuários e das decisões de engenharia. A análise precisa comparar requests por usuário, tokens por request, tarefas, funcionalidades e taxa de sucesso antes e depois da mudança. Sem uma linha de base, o crescimento pode ter outra causa.

Retries são sempre desperdício?

Não. Retries podem recuperar uma falha transitória e preservar uma tarefa importante. O desperdício aparece quando não existe limite, classificação ou telemetria para distinguir a tentativa que resolveu o problema da repetição que apenas gerou outra cobrança. A métrica correta combina número de retries, motivo, resultado e custo.

O câmbio muda o preço por token?

O câmbio não altera o preço por token contratado em moeda estrangeira, mas altera o custo efetivo para quem reporta em moeda local. O impacto depende de contrato, data de liquidação, spread e, no modo CLIENTE, da qualificação tributária da operação e do regime do comprador. Uma referência brasileira não deve ser aplicada automaticamente a outra operação.

Quando o roteamento ajuda de verdade?

O roteamento ajuda quando a empresa tem workloads diferentes, regras de custo ou performance, necessidade de failover e pouca visibilidade sobre as requests. Ele torna a política explícita e auditável. Não substitui a definição de tarefa concluída, a linha de base, a medição de qualidade nem a validação do contrato.

Referências e Leitura Complementar

• AI Token Price Collapse, But AI Costs Are Rising
• Nexforce Router
• Benchmark de LLMs para CFOs: custo, não score técnico
• Comparação de custos de LLMs em 2026: roteamento inteligente
• Solução de Consulta Cosit nº 191/2017, Receita Federal: classificação, no caso consultado, de autorizações de uso e acesso a SaaS como serviço técnico para fins de IRRF e CIDE
• Lei 10.168/2000, CIDE
• Lei 10.865/2004, PIS/COFINS-Importação
• Lei Complementar 116/2003, ISS
• Decreto 6.306/2007, IOF
• Decreto 9.580/2018, RIR/2018

A conta que sobrevive ao preço

O orçamento de IA precisa sobreviver a um preço por token que muda. Exige medir o workload, registrar a rota, contar retries e separar o preço por token do custo efetivo. Essa disciplina mostra quando a redução virou expansão de consumo, quando uma falha produziu requests extras e quando a contratação em moeda estrangeira alterou o desembolso local.

A empresa que mede apenas o token pergunta quanto custa uma peça. A empresa que mede o workload descobre quanto custa a máquina inteira, inclusive o parafuso que cai no chão toda vez que um retry dispara.

Preço por token é negociação. Custo efetivo é gestão.