Clawy / Guias / Precificar uma API de IA paga

Como precificar uma API de IA paga sem perder dinheiro

Se você revende ou encapsula GPT ou Claude a um preço fixo por chamada, um único prompt grande pode custar mais do que você cobra. Eis a conta e duas formas de resolver.

Você encapsulou um LLM, colocou atrás de um endpoint e cobra um preço fixo e limpo — digamos $0,15 por chamada. Claro para seus clientes, fácil de raciocinar. O problema: o modelo por baixo não cobra por chamada. Ele cobra por token, e os tokens escalam com o tamanho do prompt e da resposta. Numa requisição pequena você embolsa uma boa margem. Numa grande você pode pagar mais do que arrecadou — e só vai perceber quando a fatura do provedor chegar.

Por que o preço fixo vaza

Modelos cobrados por token cobram separadamente input (o prompt que você envia) e output (o que o modelo gera). Conforme as tarifas oficiais da Claude:

Seu custo por uma chamada é simplesmente:

cost = (input_tokens × input_price + output_tokens × output_price) / 1,000,000

Pegue o Opus 4.8 a um preço fixo de $0,15/chamada. Só o output custa $25 por milhão de tokens — então apenas 6.000 tokens de output custam $0,15, consumindo todo o seu preço antes de contar um único token de input. Deixe um cliente enviar um documento de 100.000 tokens como contexto e pedir uma resposta longa, e essa única chamada pode custar várias vezes o que você cobrou. Multiplique por alguns usuários intensivos e o produto "lucrativo" opera no prejuízo.

Encontre seu ponto de equilíbrio antes de lançar

O número que importa é o maior prompt que você consegue servir antes de uma chamada custar mais do que você cobra. Com o tamanho de output fixo, o tamanho de input de equilíbrio é:

break_even_input_tokens = (price × 1,000,000 − output_tokens × output_price) / input_price

Para o Opus a $0,15 com uma resposta de 800 tokens: (0.15 × 1,000,000 − 800 × 25) / 5 = 26,000 tokens de input. Acima de ~26k tokens de prompt, cada chamada perde dinheiro. Se o seu tráfego real ultrapassa isso com regularidade, o preço fixo é o modelo errado — ou seu preço está baixo demais.

Solução 1 — limite input e output

Se você quer manter o preço fixo (clientes adoram a previsibilidade), limite ambos os lados para que a chamada de pior caso não ultrapasse seu preço:

• Limite o tamanho do input. Rejeite ou trunque prompts acima de um limite de tokens/caracteres — e faça isso antes de cobrar ou chamar o modelo, para que uma requisição grande demais não custe nada a você.
• Limite o output (max_tokens). Um padrão generoso ainda limita o lado caro. A $25/1M, cada 1.000 tokens de output são $0,025.
• Dimensione os limites com a conta acima. Escolha limites onde worst-case cost < price com margem de sobra para retentativas, fallbacks e falhas de cache de prompts (reserve ~25–40% de folga).
• Anuncie os limites. Coloque os limites de input/output no seu schema de API para que os clientes se autolimitem em vez de levar rejeições surpresa.

É exatamente assim que um endpoint de preço fixo se mantém solvente: o preço é fixo, mas o trabalho por trás é limitado para que nunca opere no vermelho.

Solução 2 — preços por uso

A alternativa é parar de fingir que as chamadas são uniformes e cobrar pelo que de fato consomem: medir tokens (muitas vezes com um múltiplo de margem sobre seu custo) ou cobrar preços escalonados por tamanho de requisição. Você abre mão da simplicidade de um número redondo, mas nunca perde dinheiro numa requisição grande porque o preço acompanha o custo. Por uso é o certo quando os tamanhos de prompt variam muito ou você serve cargas de contexto grande.

Não esqueça os custos ocultos

• Retentativas e fallbacks. Uma chamada que falha e repete num segundo modelo pode dobrar o gasto de tokens de uma única requisição visível ao cliente.
• Falhas de cache de prompts. O cache corta o custo de prefixo repetido em ~90%, mas só nos hits — um invalidador silencioso (um timestamp no system prompt, JSON não ordenado) significa que você paga o preço cheio toda vez.
• Tokens de pensamento / raciocínio. Se você ativar o pensamento estendido/adaptativo, esses tokens também são cobrados como output.

Qualquer que seja o modelo escolhido, a disciplina é a mesma: conheça seu custo por chamada, conheça seu ponto de equilíbrio e limite o pior caso antes que ele chegue a um cliente pagante.