01 · Reservar
Proteja a carteiraAntes de a requisição ao modelo ser enviada, a carteira reserva uma estimativa com base na entrada e no limite de saída solicitado, quando disponível.Metodologia de preços · atualizado em 2026-08-26
Entenda cada centavo antes de enviar uma requisição.
O Model.sale usa uma tarifa pré-paga combinada por modelo. O preço público é fácil de comparar, enquanto o ledger de uso guarda a composição detalhada de tokens e a cobrança final exata.
A resposta curta
Para uma requisição concluída, a cobrança é o valor de tokens cobrados reportado multiplicado pelo preço público atual. Um piso de reserva pode ser retido antes do envio, mas não é uma taxa final e a parte não usada é liberada:
charged_tokens = uncached_input + output + 0.4 × cached_input
charge = charged_tokens / 1,000,000 × model_price
final_charge = measured_charge
released_reservation = reserved_amount - final_chargeA versão do preço é registrada no momento em que a requisição é admitida. Uma mudança de preço posterior não pode alterar uma requisição em andamento. Se o uso final estiver ausente, a requisição permanece billing_pending para conciliação em vez de ser cobrada por estimativa.
02 · Medir
Leia o uso finalO uso em JSON e SSE é extraído do protocolo selecionado. O ID da requisição vincula a resposta ao seu registro de uso.03 · Liquidar
Libere o restanteO ledger registra uma liquidação idempotente e libera qualquer reserva não usada. Nenhuma taxa mensal por assento é adicionada.O que significa “tokens cobrados”
Os protocolos nomeiam os campos de uso de formas diferentes, então o Model.sale os normaliza em uma visão consistente do ledger:
| Campo de uso | Como é exibido | Tratamento na cobrança |
|---|---|---|
| Entrada / prompt | Tokens de entrada | Incluído uma vez nos tokens cobrados |
| Input em cache | Tokens em cache | Cobrado a 10–40% do preço do modelo |
| Output / completion | Tokens de output | Incluído uma vez nos tokens cobrados |
| Reasoning | Tokens de reasoning | Subconjunto de diagnóstico quando reportado; nunca somado ao output |
Se um protocolo não retorna o uso final, a requisição é marcada como billing_pending em vez de adivinhar silenciosamente um valor final.
Exemplos práticos
Os exemplos usam uma tarifa combinada de US$ 0,09. O piso de reserva é apenas um bloqueio temporário; a tarifa atual do seu modelo aparece na página de preços.
| Tokens cobrados | Cálculo bruto | Cobrança final |
|---|---|---|
| 10,000 | $0.0009 | $0.0009 |
| 100,000 | $0.009 | $0.009 |
| 1,000,000 | $0.09 | $0.09 |
| 2,000,000 | $0.18 | $0.18 |
Uma conversa com várias mensagens é liquidada mensagem por mensagem, a partir do uso medido em cada resposta.
Como comparar preços de forma justa
As APIs oficiais costumam publicar tarifas separadas de input, input em cache e output. Uma “economia” percentual só faz sentido para uma carga de trabalho definida, com a mesma mistura de tokens, moeda e regras de cache.
- Meça a mistura de input, cache e output nas suas próprias requisições.
- Aplique a tarifa oficial a essa mistura exata.
- Aplique a tarifa combinada da Model.sale ao total medido de tokens cobrados.
- Inclua na estimativa o comportamento de requisições com falha, retries, liberação de reserva e arredondamento.
Os preços de referência na página de comparação incluem a URL da fonte e a data de verificação. Eles não são um benchmark nem uma promessa de que modelos com nomes parecidos gerem o mesmo output.
Versões de preço e transparência
Cada tarifa pública tem uma versão vigente, um piso de reserva e um timestamp de verificação. A reserva não é a cobrança final: após o uso final, somente os tokens medidos são liquidados e o restante é liberado. A disponibilidade é separada: um modelo indisponível pode manter o preço visível enquanto a rota está sendo corrigida, mas não pode receber tráfego de clientes.
A Model.sale não armazena prompts nem corpos de resposta para cobrança. Os registros operacionais contêm metadados da requisição, contagem de tokens, cobrança, margem e classificação segura do erro.