Estouro de US$ 1,8 milhão em custos com Claude na Amazon: como evitar que os gastos com IA saiam do controle

Introdução

Relata-se que um projeto interno da Amazon que utilizava o Claude Sonnet, da Anthropic, acumulou uma conta de US$ 1,8 milhão, excedendo o orçamento planejado em 860%, permanecendo despercebido por cinco meses e, por fim, não chegando a ser lançado.

A tarefa em si parece bastante comum: corresponder informações de autores a listagens de produtos na plataforma de comércio eletrônico da Amazon.

O caso foi noticiado pelo Financial Times depois que um engenheiro sênior da Amazon discutiu vários casos de excedente de custos relacionados a IA em uma reunião interna de funcionários. Ele serve como um alerta útil para qualquer organização que esteja fazendo a transição do uso ocasional de chatbots para fluxos de trabalho automatizados, que podem gerar milhares ou milhões de chamadas pagas a modelos todos os dias.

Defeitos de software tradicionais geralmente desperdiçam horas de engenharia ou produzem saídas incorretas. Já defeitos em fluxos de trabalho de IA metrificados podem causar ambos os problemas e continuar gerando custos de tokens, ferramentas, armazenamento e computação a cada minuto em que permanecem ativos.

A lição não é que as empresas devam parar de usar IA, mas sim que processos de IA autônomos ou de alto volume precisam de controles financeiros tão claros quanto seus controles de segurança e qualidade.

O que aconteceu internamente na Amazon

De acordo com pessoas familiarizadas com o assunto, a Amazon usou o Claude Sonnet em um projeto destinado a corresponder informações de autores a listagens de produtos em sua plataforma de varejo.

Segundo os relatos, a implantação:

• Custou US$ 1,8 milhão
• Excedeu o orçamento alocado em 860%
• Levou cinco meses para ser descoberta
• Não chegou ao ambiente de produção

Engenheiros seniores descreveram alguns erros de codificação relacionados a IA como "catastroficamente caros".

A Amazon respondeu que está experimentando, aprendendo e melhorando sua forma de usar a tecnologia, inclusive como gerenciar a eficiência de custos. A empresa também afirmou que apresentar alguns casos isolados como prática comum não reflete com precisão o uso de IA em maior escala na organização.

Ambas as afirmações podem ser verdadeiras.

Esses incidentes podem envolver apenas uma pequena parcela das equipes da Amazon, mas também revelam um problema de controle que outras organizações deveriam levar a sério.

O defeito de codificação específico ainda não foi divulgado

A reportagem inicial em chinês atribuiu o excedente a um programa sem limite de frequência de chamadas, que continuamente enviava requisições em um loop.

Essa explicação é plausível, mas ainda não foi confirmada pelos relatos públicos atuais.

O Financial Times descreveu erros de codificação, controles de gastos frágeis e atraso na detecção. Não publicou uma análise pós-incidente técnica mostrando:

• Código-fonte
• O defeito exato
• Se o processo era um loop infinito
• O número de chamadas ao modelo
• A quantidade de tokens de entrada ou saída
• Se o modelo foi acessado diretamente ou via Amazon Bedrock
• A versão do modelo
• A configuração de uso de ferramentas
• Os componentes de infraestrutura que geraram os custos

A conclusão mais segura é mais cautelosa: uma implantação malsucedida do Claude Sonnet gerou uma conta enorme, e os sistemas de controle da Amazon não detectaram o problema em cinco meses.

A menos que a Amazon publique um relatório técnico do incidente, qualquer explicação mais detalhada deve ser tratada como especulação.

Este não é o único problema de custo

Excedentes

De acordo com informações, o mesmo relatório interno também discutiu pelo menos outros dois casos.

Segundo relatos, o excedente logístico levou mais de duas semanas para ser descoberto.

Esses casos são menores do que o projeto de correspondência de autores de US$ 1,8 milhão, mas apontam para o mesmo padrão: quando nenhuma falha técnica força a interrupção do processo, sistemas de IA baseados em uso podem continuar acumulando custos.

Trabalhos em lote tradicionais podem falhar, esgotar a memória ou não passar nos testes.

Já processos de IA podem permanecer tecnicamente saudáveis enquanto entram em colapso financeiro.

Mesmo quando o projeto não produz mais resultados úteis, ele pode continuar recebendo respostas de API bem-sucedidas, gravando logs, chamando ferramentas, repetindo tarefas ou processando registros de baixo valor.

Por que as falhas de custo em IA se comportam de maneira diferente

Os custos de aplicações tradicionais geralmente estão atrelados a unidades relativamente conhecidas:

• Tempo de servidor
• Capacidade de banco de dados
• Armazenamento
• Transferência de rede
• Horas de trabalho humano

Já os fluxos de trabalho de IA podem acumular simultaneamente múltiplas camadas de cobrança por uso:

• Tokens de entrada
• Tokens de saída
• Contexto em cache e sem cache
• Tokens de raciocínio
• Chamadas de ferramentas
• Buscas na web
• Sessões de execução de código
• Buscas vetoriais
• Repetições de agentes
• Processos de trabalho paralelos
• Históricos de conversa longos
• Recursos de computação em nuvem
• Saídas de logs e armazenamento

Isso gera um efeito multiplicador.

Suponha que uma tarefa envie um prompt muito longo, gere uma grande quantidade de respostas, chame duas ferramentas, apresente erro e tente novamente, e passe o histórico completo para a próxima rodada. Se a aplicação processar milhões de registros, um pequeno erro de design pode se tornar extremamente caro.

Do ponto de vista operacional, a aplicação pode parecer normal. As requisições ainda retornam 200 OK. Os processos de trabalho permanecem ativos. As filas continuam diminuindo. A conta costuma ser o primeiro lugar onde o problema aparece.

Um modelo simples de custo para fluxos de trabalho de IA

Antes de iniciar um processo de IA automatizado, estime o custo por tarefa de negócio concluída.

Um modelo simplificado é o seguinte:

O indicador-chave não é apenas o custo por token.

Mas sim:

Custo total por resultado de negócio concluído com sucesso

Requisições mais baratas, se tiverem maior taxa de falhas, exigirem chamadas repetidas ou gerarem mais revisão humana, podem ainda assim resultar em um fluxo de trabalho mais caro.

Da mesma forma, um modelo mais forte, se concluir a tarefa em menos etapas, pode acabar tendo um custo total menor.

Primeiro controle: um responsável financeiro para cada tarefa de IA

Cada fluxo de trabalho de IA em produção deve ter um responsável nomeado, que responda tanto pelo comportamento técnico quanto pelos gastos.

Esse responsável deve saber:

• O volume de negócios esperado
• O modelo utilizado
• O custo esperado por item
• O orçamento diário e mensal
• O custo máximo por execução
• As condições para interromper o fluxo de trabalho
• Quem recebe os alertas
• O processo para aprovar limites mais altos

Quando um único processo de trabalho pode continuar enviando requisições indefinidamente, orçamentos vagos em nível de projeto não são suficientes.

Os orçamentos devem existir em múltiplos níveis:

Os níveis mais baixos oferecem o mecanismo de freio mais rápido e eficaz.

Definir limites rígidos dentro da aplicação

Alertas de cobrança em nuvem são importantes, mas não substituem controles em nível de aplicação.

A aplicação deve parar ou exigir aprovação ao atingir os limites definidos.

Limites úteis incluem:

• Número máximo de requisições por tarefa
• Número máximo de etapas do agente
• Número máximo de repetições
• Número máximo de tokens de entrada
• Número máximo de tokens de saída
• Comprimento máximo de contexto
• Número máximo de chamadas de ferramentas
• Número máximo de processos de trabalho paralelos
• Tempo máximo de execução
• Custo máximo em dólares por tarefa
• Número máximo de registros processados antes de revisão

Esses controles devem ser desativados por padrão.

Se o serviço de rastreamento de custos não estiver disponível, ou se a aplicação não puder determinar o orçamento restante, o comportamento mais seguro é pausar em vez de continuar indefinidamente.

Usar um interruptor de emergência independente do agente

Agentes autônomos não devem controlar a autoridade final de gastos de si mesmos.

Um serviço independente deve ser capaz de:

• Desativar chaves de API
• Recusar chamadas ao modelo
• Pausar filas
• Reduzir processos de trabalho a zero
• Bloquear ferramentas externas
• Revogar papéis
• Interromper tarefas agendadas
• Exigir aprovação humana antes da retomada

Mesmo que o agente entre em um loop de repetições ou produza mensagens de status enganosas, o interruptor de emergência deve permanecer acessível.

Teste antes do ambiente de produção.

Controles que nunca foram usados são apenas teoria.

Monitorar cada chamada ao modelo

Organizações que usam o Amazon Bedrock podem ativar o registro de chamadas ao modelo para invocações suportadas do bedrock-runtime.

A AWS afirma que esses logs podem incluir dados de requisição e resposta, metadados, identificadores de modelo, identificadores de requisição, informações de identidade e uso de tokens. Os destinos de log podem incluir o Amazon CloudWatch Logs e o Amazon S3.

O registro de chamadas está desativado por padrão.

A equipe deve habilitar apenas os dados necessários para a observabilidade e aplicar controles adequados de privacidade, segurança, retenção e mascaramento. Prompts e saídas podem conter informações sensíveis da empresa ou de clientes.

No mínimo, os registros de monitoramento de custos devem conter:

• Carimbo de data/hora
• Aplicação
• Ambiente
• Equipe ou centro de custo
• Modelo
• Usuário ou locatário
• Número de tokens de entrada
• Número de tokens de saída
• Uso de cache
• Chamadas de ferramentas
• Número de tentativas
• Identificador do trabalho
• Custo estimado da solicitação
• Resultado comercial
• Erros ou motivos de escalonamento

Isso permite associar a fatura a tarefas específicas, em vez de descobrir um total enorme apenas na revisão financeira mensal.

Usar o AWS Budgets para rastrear custos do Claude no Bedrock

O AWS Budgets pode rastrear custos ou uso em relação a limites definidos e enviar notificações. As ações de orçamento também podem aplicar controles, como políticas IAM ou políticas de controle de serviço, quando os limites são excedidos. Dependendo da configuração, as ações podem ser executadas automaticamente ou aguardar aprovação humana.

Um detalhe importante específico da AWS pode facilmente passar despercebido.

A documentação do AWS Cost Anomaly Detection afirma que esse serviço não monitora produtos de terceiros vendidos por meio do AWS Marketplace, incluindo modelos de linguagem de terceiros oferecidos por meio do Amazon Bedrock, como o Anthropic Claude.

Esses custos ainda aparecem no Cost Explorer e na fatura, mas a AWS recomenda usar o AWS Budgets para alertar sobre esses gastos.

Os orçamentos podem usar filtros de entidade de cobrança para rastrear com mais precisão os custos do Marketplace.

Esse é exatamente o tipo de detalhe de configuração que pode gerar uma falsa sensação de segurança. A empresa pode ter habilitado a detecção de anomalias e acreditar que todos os custos de modelo estão cobertos, mas uma categoria específica de cobrança não está incluída.

Não tratar o AWS Budgets como um disjuntor em tempo real

A documentação da AWS afirma que o status do orçamento é atualizado várias vezes ao dia.

A documentação também alerta que os custos podem continuar aumentando antes ou depois de a notificação ser entregue.

Isso significa que o AWS Budgets é útil para a governança financeira, mas, isoladamente, pode não interromper com rapidez suficiente um agente de alto throughput.

A pilha de controles deve incluir:

1. Contadores em nível de solicitação no aplicativo
2. Métricas de uso quase em tempo real
3. Limites rígidos por trabalho e por sessão
4. Alertas de orçamento na nuvem
5. Ações orçamentárias automatizadas quando apropriado
6. Revisão financeira diária para lançamentos de alto risco

Quanto mais rápido o fluxo de trabalho gasta dinheiro, mais próximos do ponto de chamada os controles precisam estar.

Usar a detecção de anomalias para custos dentro da cobertura do serviço

O AWS Cost Anomaly Detection usa modelos de aprendizado de máquina para identificar padrões de gastos anormais e ajudar a localizar possíveis causas raiz.

A AWS afirma que o serviço avalia os dados de cobrança processados aproximadamente três vezes ao dia.

Ele pode detectar com eficácia crescimentos inesperados em serviços AWS, contas, regiões, tipos de uso e tags de alocação de custos.

Para sistemas de IA, ele pode identificar anomalias em custos de infraestrutura de suporte envolvendo computação, armazenamento, banco de dados ou rede.

No entanto, as equipes devem lembrar da limitação do Marketplace mencionada acima e criar AWS Budgets separados para custos de modelos de terceiros quando necessário.

Usar o Service Quotas como limite de segurança, não como orçamento

O Amazon Bedrock aplica cotas de serviço à inferência de modelos, incluindo limites baseados em tokens para modelos e endpoints suportados.

As cotas podem impedir throughput ilimitado, mas não foram projetadas como orçamentos financeiros precisos.

As cotas ainda podem permitir gastos muito além dos limites projetados do projeto. Por outro lado, aumentar cotas para resolver problemas de capacidade de produção pode remover inadvertidamente um limite de segurança útil.

Portanto, alterações de cotas devem exigir:

• Justificativa comercial
• Projeção de custos atualizada
• Aprovação nominal
• Limites de alerta atualizados
• Plano de reversão
• Revisão após o aumento de tráfego

Limites de taxa e tokens devem ser tratados como parte do design de risco do sistema, e não apenas como obstáculos à escalabilidade.

Rastrear diretamente o uso e os custos da Anthropic quando apropriado

Para aplicações que chamam a Anthropic diretamente, o console da Anthropic oferece relatórios de custo e uso.

Os limites da API da Anthropic podem incluir solicitações por minuto, tokens de entrada por minuto, tokens de saída por minuto e limites de gastos associados ao nível de uso.

Esses limites podem reduzir o throughput não controlado, mas ainda devem ser complementados com controles no nível da aplicação.

Organizações com múltiplas equipes também podem implantar um gateway de LLM entre as aplicações e o provedor de modelos. O gateway pode centralizar autenticação, rastreamento de uso, orçamentos, limites de taxa, roteamento de modelos e logs de auditoria.

O gateway se torna um componente crítico de segurança e, portanto, deve ser operado e revisado com o mesmo rigor de qualquer outra camada de acesso de produção.

Começar com uma amostra pequena e representativa

Relatos indicam que um projeto da Amazon tentou executar uma tarefa de correspondência de dados em larga escala.

Um padrão de implantação mais seguro é:

1. Executar 100 registros representativos.
2. Medir precisão e custo.
3. Executar 1.000 registros.
4. Verificar erros e distribuição de tokens.
5. Testar cenários de pior caso.
6. Confirmar os controles de interrupção.
7. Estimar o gasto para o processamento completo.
8. Exigir aprovação antes de processar o conjunto completo de dados.

Não extrapole com base apenas na média dos registros.

Os documentos mais longos, registros com falha de correspondência, casos ambíguos, tentativas e loops de agentes tendem a dominar o custo total.

Use estimativas por percentil, como custo P50, P95 e P99 por tarefa.

Definir um teto máximo de custo por resultado válido

O fluxo de trabalho deve parar quando chamadas adicionais ao modelo não forem mais economicamente justificáveis.

Para um sistema de correspondência de autores, métricas úteis podem incluir:

• Custo por autor correspondido com sucesso
• Custo por registro revisado manualmente
• Percentual de registros resolvidos automaticamente
• Taxa de correspondências incorretas
• Custo das correspondências incorretas
• Economia em comparação ao processamento manual
• Número de chamadas ao modelo por resultado aceito

Um processo que custa US$ 0,02 por solicitação pode parecer barato.

Se ele exigir 50 chamadas, metade dos registros falhar e o restante for para revisão manual, a economia real pode ser muito ruim.

Roteirizar tarefas simples para métodos mais baratos

Nem todo registro exige um modelo de ponta.

Um pipeline consciente dos custos pode usar:

1. Correspondência exata
2. Junções no banco de dados
3. Regras
4. Similaridade de embeddings
5. Modelos menores
6. Modelos mais fortes apenas em casos ambíguos
7. Revisão humana para decisões de alto risco

Para projetos de correspondência de dados, software tradicional pode resolver a maioria dos casos de forma mais barata e determinística.

O LLM deve ser usado apenas quando a ambiguidade linguística realmente exigir, e não aplicado automaticamente a todas as linhas.

O próprio guia de preços da Anthropic recomenda escolher o modelo certo, usar cache de prompts para contextos repetidos, adoção de processamento em lote para trabalhos não urgentes e monitoramento dos padrões de uso.

Evitar tentativas ilimitadas

As tentativas são uma fonte comum de gastos ocultos.

Uma solicitação com falha pode ser repetida pelo aplicativo, sistema de filas, SDK, gateway, gerenciador de workers, agente ou orquestrador do fluxo de trabalho.

Quando várias camadas tentam novamente de forma independente, uma única tarefa lógica pode gerar múltiplas solicitações pagas.

Defina uma política de tentativas unificada, contendo:

• Número máximo pequeno de tentativas
• Backoff exponencial
• Jitter
• Tratamento explícito de erros não repetíveis
• Idempotência
• Fila de mensagens mortas
• Alertas para falhas repetidas
• Orçamento por tarefa que inclua todos os custos relevantes, inclusive

o número de tentativas

Erros não devem criar loops econômicos infinitos.

Separar credenciais de desenvolvimento e produção

Scripts de teste não devem herdar limites de nível de produção.

Use contas ou workspaces separados, chaves de API, papéis IAM, orçamentos, cotas, logs, fontes de dados e permissões de rede.

Os ambientes de desenvolvimento devem ter limites de gastos deliberadamente baixos.

Um protótipo que entra em loop acidentalmente deve falhar com uma fatura pequena, e não obter cotas de produção de nível empresarial.

Revisar código gerado por IA como se fosse infraestrutura financeira de produção

O incidente envolveu um projeto auxiliado por IA, mas a questão central não é se o código foi gerado por um modelo.

A questão importante é se o código pode gastar dinheiro.

Qualquer componente capaz de iniciar solicitações pagas a modelos deve passar por revisão de:

• Terminação de loops
• Comportamento de tentativas
• Concorrência
• Expansão de filas
• Contexto máximo
• Limites de chamadas de ferramentas
• Tratamento de timeouts
• Mecanismos de cancelamento
• Atribuição de custos
• Caminhos de erro
• Registro de logs
• Execução orçamentária
• Comportamento de desligamento emergencial

Os testes unitários devem incluir cenários de falha econômica.

Exemplos incluem: o modelo nunca retorna uma resposta válida, entrega repetida de tarefas, falha do worker após chamada paga, erros repetidos de limite de taxa, crescimento do contexto a cada turno devido a saídas de ferramentas e indisponibilidade do serviço de estimativa de custos.

Um caminho normal funcionalmente correto está longe de ser suficiente.

Checklist de controle de custos de IA em nível de produção

Propriedade e planejamento

• Um responsável técnico designado responde pelos gastos.

• O uso esperado e o custo por resultado bem-sucedido estão documentados.

[ ] Os ambientes de desenvolvimento, pré-produção e produção possuem orçamentos independentes.

• O processamento em escala total requer aprovação explícita.

Controle de aplicações

• Cada tarefa tem limites máximos de número de solicitações, tokens, etapas, tentativas e tempo de execução.

• Cada sessão de agente tem um orçamento em dólares americanos.

• Serviços não relacionados a agentes podem interromper fluxos de trabalho.

• As tarefas são pausadas quando não é possível ler o orçamento restante.

• O trabalho duplicado é evitado por meio de idempotência.

Monitoramento

• Cada chamada de modelo é atribuída a equipe, projeto, usuário e tarefa.

• O uso de entradas, saídas, cache, ferramentas e tentativas é registrado.

• Alertas são definidos tanto para a taxa de gastos quanto para o gasto total.

• Uma revisão diária é habilitada durante o lançamento inicial em produção.

• As equipes estão cientes dos itens de custo não cobertos pela detecção de anomalias.

Qualidade e economia

• O custo é medido por resultado de negócio bem-sucedido.

• Código comum e modelos menores são usados quando apropriado.

• Os custos de pior caso e de alto percentil foram testados.

• Os custos de revisão humana estão incluídos.

• O fluxo de trabalho é interrompido quando chamadas adicionais não agregam mais valor.

Governança

• O código gerado por IA passa por revisão humana.

• Aumentos de orçamento e cotas exigem aprovação.

• O interruptor de emergência foi testado.

• A resposta a incidentes inclui partes interessadas financeiras e técnicas.

• As equipes revisam os gastos após cada mudança significativa de modelo ou prompt.

Lições da resposta da Amazon

Segundo relatos, engenheiros da Amazon estão construindo salvaguardas automatizadas para futuros projetos de IA.

Essa é a direção certa.

Mas a automação precisa existir em múltiplas camadas.

Um sistema de controle maduro deve combinar limites rígidos no nível do aplicativo, limites de modelo e gateway, orçamentos em nuvem, ações automatizadas, registros de uso, painéis financeiros, aprovações humanas e revisões periódicas.

A empresa também removeu um ranking interno que incentivava os funcionários a maximizar o uso de sua ferramenta de desenvolvimento Kiro. Segundo o Financial Times, o ranking incentivava o “tokenmaxxing”, no qual os funcionários aumentavam o consumo de tokens para subir no ranking.

Isso é um lembrete útil: incentivos podem minar o controle de custos.

Se os funcionários são recompensados por usar mais IA, em vez de criar valor comercial mensurável, o uso aumentará mesmo que a produção não melhore.

As organizações devem recompensar problemas resolvidos, melhorias de qualidade, tempo economizado, receita gerada, risco reduzido e redução do custo por unidade de produção.

A contagem de tokens é uma métrica de entrada, não uma métrica de produtividade.

Perguntas frequentes

A Amazon realmente gastou US$ 1,8 milhão no Claude Sonnet?

O Financial Times noticiou que um projeto interno da Amazon que usava o Claude Sonnet gerou uma conta acumulada de US$ 1,8 milhão. O projeto, que visava combinar informações de autores com listagens de e-commerce, estourou o orçamento em 860% e não foi lançado.

Por que o estouro de custos não foi detectado por cinco meses?

De acordo com relatos públicos, a Amazon não tinha controles de gastos adequados, e erros de codificação foram um dos fatores que contribuíram para o problema. A Amazon ainda não publicou uma análise post-mortem técnica para identificar as falhas específicas ou falhas de monitoramento.

O problema foi causado por loops infinitos de IA?

Essa explicação apareceu em algumas reportagens secundárias, mas ainda não foi confirmada nas principais reportagens. O número exato de solicitações, a lógica de tentativas, o volume de tokens e os defeitos no código-fonte não foram divulgados.

A Amazon teve outros casos de estouro de custos com IA?

Sim. Aparentemente, a mesma apresentação interna também incluía custos inesperados de aproximadamente US$ 541 mil em um projeto de auditoria financeira e US$ 134 mil em um projeto de logística.

O AWS Cost Anomaly Detection consegue monitorar os custos do Claude no Amazon Bedrock?

A documentação da AWS indica que o Cost Anomaly Detection não monitora produtos de terceiros no AWS Marketplace, incluindo os modelos Anthropic Claude no Bedrock. A AWS recomenda o uso do AWS Budgets para gerenciar esses custos e, quando aplicável, filtros de entidade de cobrança.

O AWS Budgets consegue interromper imediatamente gastos descontrolados com IA?

Somente ele não. A AWS afirma que as informações de orçamento são atualizadas várias vezes ao dia e que os custos podem continuar aumentando antes e depois do período de notificação. Aplicações de alto tráfego precisam de limites rígidos no nível de solicitação e um interruptor de emergência independente.

Limites de taxa são o mesmo que limites de gastos?

Não. Limites de taxa controlam a taxa de transferência, enquanto controles de orçamento gerenciam o custo aceitável. Um fluxo de trabalho pode operar dentro dos limites de taxa e ainda assim exceder drasticamente o orçamento planejado ao longo de semanas ou meses.

Qual é o controle mais importante para agentes de IA?

Definir um orçamento rígido para cada sessão de agente incluindo solicitações, tokens, ferramentas, tentativas e tempo. Aplicar esse orçamento fora do agente e ter uma forma testada de interromper imediatamente o fluxo de trabalho.

Ferramentas relacionadas

• AWS Budgets: permite rastrear custos e uso em relação a limites e acionar notificações ou ações de orçamento configuradas.
• AWS Cost Anomaly Detection: detecta padrões incomuns de gastos na AWS em categorias de cobrança suportadas.
• AWS Cost Explorer: ajuda as equipes a analisar custos e uso históricos em serviços da AWS e dimensões de cobrança.
• Amazon Bedrock 模型调用日志: registra chamadas de modelo suportadas e metadados relacionados no CloudWatch Logs ou Amazon S3.
• Amazon Bedrock 服务配额: exibe limites de modelo e endpoint que podem restringir a taxa de transferência de inferência.
• Anthropic Console: oferece chaves de API, relatórios de uso, relatórios de custo, workspaces e controles em nível de conta para uso direto da API da Anthropic.

Links relacionados

• Financial Times: Amazon AI 支出超支: reportagem principal sobre o projeto de US$ 1,8 milhão e estouros adicionais de custos internos.
• AWS Budgets 文档: guia oficial sobre como rastrear custos e uso da AWS em relação a orçamentos.
• AWS Budget Actions: explica ações executadas automaticamente ou que exigem aprovação humana quando os limites são excedidos.
• AWS Cost Anomaly Detection 限制: documenta o monitoramento de anomalias e a exclusão de cobranças de modelos de terceiros no Marketplace.
• Amazon Bedrock 调用日志

com/bedrock/latest/userguide/model-invocation-logging.html): Guia oficial de configuração e tratamento de dados para registro de invocações do Bedrock.

• Relatórios de custo e uso da Anthropic: Apresenta relatórios de custo, uso, tokens, modelos, espaços de trabalho e limites de taxa no Console da Anthropic.
• Limites de taxa da API da Anthropic: Descreve limites de número de solicitações, tokens de entrada, tokens de saída e níveis de uso.

Resumo

Segundo relatos, um projeto interno da Amazon usando Claude Sonnet custou 1,8 milhão de dólares, excedendo o orçamento em 860%, passou cinco meses sem ser detectado e nunca chegou a ser colocado em produção. Outros projetos de IA teriam gerado despesas inesperadas de centenas de milhares de dólares.

Os registros públicos não confirmam que o evento principal foi causado por um loop infinito de solicitações. O que os registros confirmam é a lacuna entre a velocidade dos gastos dos fluxos de trabalho de IA e a velocidade com que as organizações detectam problemas.

As empresas devem combinar rastreamento de solicitações individuais, orçamentos em nível de tarefa, limites de tokens e ferramentas, novas tentativas controladas, roteamento de modelos, orçamentos de nuvem, ações automatizadas e interruptores de emergência que agentes não possam desativar.

**

A regra mais segura é simples: nenhum processo de IA deve operar por cinco meses sem provar repetidamente que ainda é útil, está dentro do orçamento e foi autorizado a continuar.