OpenAI confirma erro na faturação de contentores da Agents API

Um utilizador do Reddit relatou uma fatura de 1 600 USD na Agents API a 18 de setembro de 2026, depois de deixar sessões alojadas inativas. A OpenAI reconheceu nesse dia que estava a cobrar valores excessivos por contentores e marcou o incidente como resolvido a 19 de setembro. A conclusão que retiro é investigar cobranças inesperadas antes de as tratar como preços normais, sem deixar de definir uma política de libertação de recursos para cada sessão. [1] [2]

O que aconteceu à fatura de 1 600 USD relatada?

O relato recebeu uma atualização importante: o autor disse que a OpenAI tinha reconhecido um problema de faturação e acrescentou uma ligação para o incidente oficial. Isso muda a minha leitura do alerta inicial. Dá motivos para investigar uma cobrança incorreta, mas não é um exemplo fiável do custo normal de sessões inativas. [1] [2]

O utilizador descreveu tarefas recorrentes que demoravam cerca de cinco minutos e custavam aproximadamente 0,20 USD em utilização do modelo depois de mudar para Luna. Tinha criado 138 sessões e mantinha-as como registo do trabalho anterior. Segundo a publicação, a utilização apresentada ultrapassou depois os 200 USD e, mais tarde, os 1 600 USD. Os montantes, a sequência temporal e os pormenores das tarefas continuam a ser o relato do autor. [2]

A página de estado da OpenAI confirma de forma independente o incidente mais geral. A 18 de setembro, a empresa anunciou uma investigação a cobranças inesperadamente elevadas por contentores alojados e disse que estava a preparar reembolsos. A 19 de setembro, comunicou uma medida de mitigação que protegia as novas sessões e marcou depois o incidente como resolvido. O aviso não confirma a fatura exata deste utilizador nem que tenha recebido um reembolso. [1]

Para quem avalia as responsabilidades que a Agents API assume, esta distinção importa. Uma fatura incorreta pode fazer um serviço parecer incomportável, mesmo quando o preço previsto é outro. Guardaria os identificadores das sessões e os registos de faturação antes de decidir se é preciso reformular as tarefas.

Quanto custa normalmente um sandbox alojado?

A OpenAI documenta duas cobranças separadas: a utilização de tokens do modelo e as tarifas dos contentores do sandbox alojado. Consultar apenas um contador de tokens deixa, por isso, parte do custo da tarefa de fora. O guia de ambientes alojados remete expressamente para a tabela de preços normal dos contentores. [3]

Na consulta de 22 de setembro de 2026, essa tabela indicava os valores abaixo. A segunda coluna mantém a unidade de 20 minutos; a última resulta da minha divisão por 20 e não significa que todas as sessões sejam faturadas ao minuto. [4]

A nota de rodapé diz que as sessões de contentor elegíveis são faturadas ao minuto, com um mínimo de cinco minutos. A página de preços não define os critérios de elegibilidade nem especifica como é contabilizado cada período de inatividade. Confirmaria esses pormenores para as tarefas em causa antes de usar a tarifa equivalente numa previsão. A tabela de preços, por si só, não permite reconstituir a fatura do Reddit. [4]

É uma questão diferente dos limites de utilização de cinco horas nas subscrições do Codex. O limite de uma subscrição controla a utilização incluída; uma aplicação que usa a API precisa de contabilizar os recursos que cria. Misturar os dois assuntos torna ambos mais difíceis de perceber.

Terminar uma tarefa liberta o seu sandbox?

Concluir a tarefa e libertar os recursos do sandbox são passos separados. A OpenAI diz que os sandboxes ligados recebem sinais de manutenção da ligação, ou keep-alives, entre turnos e podem expirar após uma hora sem atividade ou sinais de manutenção da ligação. Essa hora não é, portanto, uma promessa de que o sandbox de cada tarefa concluída desapareça exatamente 60 minutos depois. [3]

A ação documentada para libertar os recursos é eliminar a sessão quando esta deixa de ser necessária. Uma resposta 409 pode indicar que a preparação ou a execução ainda está a terminar; a OpenAI recomenda esperar e tentar novamente, com um número limitado de tentativas. Eliminar a sessão remove o recurso da API, embora a libertação física dos recursos possa continuar de forma assíncrona. [3] [5]

O cancelamento tem outra finalidade. Interrompe um turno ativo, preservando a conversa e o trabalho anterior. O guia de sessões também avisa que uma sessão inativa não comprova que a tarefa tenha terminado com sucesso: as aplicações devem inspecionar o estado final do turno e o resultado produzido. Registaria separadamente se o trabalho foi aceite e se os seus recursos foram libertados. [7]

Este é o lado operacional da preservação de contexto útil para agentes de programação. O conhecimento guardado e um ambiente de trabalho ativo respondem a necessidades diferentes. Numa tarefa recorrente, guardaria de forma deliberada o resultado aceite e o histórico necessário, decidindo depois se outro turno precisa realmente do mesmo ambiente.

O que mudaria numa aplicação com agentes?

Faria a aplicação acompanhar as sessões desde a criação até à libertação dos recursos, incluindo as tarefas que falhassem. Cada sessão teria um responsável e um prazo de retenção. Depois de guardar os resultados necessários, um processo de limpeza solicitaria a eliminação, registaria a resposta e repetiria as tentativas em caso de falhas temporárias, até um limite definido. Uma verificação periódica separada detetaria as sessões que tivessem escapado ao processo normal de conclusão.

Esta é a minha proposta para a aplicação, não uma correção que a OpenAI tenha dito ser necessária para os clientes evitarem o incidente de faturação. A sua utilidade é tornar a utilização dos recursos verificável. Se uma cobrança parecer errada, quero saber que sessões existiram, o que foi executado nelas e quando foi pedida a libertação dos recursos.

Também compararia os registos da aplicação com os dados de faturação. A OpenAI descreve as contagens de tokens por sessão e por turno como provisórias: podem estar em falta ou mudar à medida que chegam os dados de contabilização, e não constituem uma fatura final. Para estimar o custo da tarefa completa, a documentação recomenda incluir o trabalho delegado, as novas tentativas e os custos aplicáveis de ferramentas ou computação. [6]

Por fim, verificaria se a tarefa precisa sequer de um sandbox. A opção documentada environment.type: "none" pode servir para trabalho executado através de ferramentas externas, embora retire o acesso ao Bash integrado, à aplicação de patches e aos ficheiros do ambiente de trabalho. Escolhê-la-ia para tarefas cujas ferramentas necessárias continuassem disponíveis sem esse ambiente. [8]

Na próxima tarefa recorrente, analisaria em conjunto o resultado guardado e o registo de libertação dos recursos. Ambos fazem parte de uma execução concluída.