OpenAI confirms an Agents API container billing bug

A Reddit user reported a $1,600 Agents API bill on 18 September 2026 after leaving hosted sessions idle. OpenAI acknowledged container overbilling that day and marked the incident resolved on 19 September. My takeaway is to investigate unexpected charges before treating them as normal pricing, while still giving every session a cleanup policy. [1] [2]

What happened to the reported $1,600 bill?

The report acquired a material update: its author said OpenAI had acknowledged a billing problem, then linked the official incident. That changes how I read the original warning. It is evidence for investigating a faulty charge, rather than a reliable example of what ordinary idle sessions cost. [1] [2]

The user described recurring jobs that took about five minutes and around $0.20 in model usage after switching to Luna. They had created 138 sessions and kept them as a record of previous work. According to the post, displayed usage later rose above $200 and then $1,600. Those amounts, timing and workload details remain the author’s account. [2]

OpenAI’s status page independently confirms the broader incident. On 18 September, the company announced an investigation into unexpectedly high hosted-container charges and said it was preparing refunds. On 19 September, it reported a mitigation protecting new sessions, then marked the incident resolved. The notice does not confirm this user’s exact invoice or a completed refund. [1]

For somebody evaluating what the Agents API takes over, that distinction matters. A broken bill can make a service look unaffordable even when the intended price is different. I would preserve the session identifiers and billing records before deciding whether the workload itself needs redesigning.

What does a hosted sandbox normally cost?

OpenAI documents two separate charges: the model’s token usage and the hosted sandbox’s container rates. Reading a token counter alone therefore leaves part of the task cost out. The hosted-environment guide explicitly points to the standard container rate card. [3]

As checked on 22 September 2026, that card lists the following amounts. The second column preserves its 20-minute unit; the final column is my division by 20, not a claim that every session receives per-minute billing. [4]

The footnote says eligible container sessions are billed by the minute with a five-minute minimum. The pricing page does not define eligibility or specify how every idle period is metered. I would confirm those details for the actual workload before using the equivalent rate in a forecast. The rate card alone cannot reconstruct the Reddit bill. [4]

This is a different issue from the five-hour usage limits in Codex subscriptions. A subscription allowance controls included usage; an API application needs to account for the resources it creates. Mixing the two makes both discussions harder to follow.

Does finishing a task release its sandbox?

Task completion and sandbox cleanup are separate steps. OpenAI says connected sandboxes receive keep-alives between turns, and can expire after an hour without activity or keep-alives. The hour is therefore not a promise that every completed task loses its sandbox exactly 60 minutes later. [3]

The documented cleanup action is to delete the session when it is no longer needed. A 409 response can mean setup or execution is still finishing; OpenAI advises waiting and retrying with a bounded number of attempts. Session deletion removes the resource from the API, while physical cleanup may continue asynchronously. [3] [5]

Cancellation has a different purpose. It stops an active turn while retaining the conversation and previous work. The session guide also warns that an idle session does not establish a successful result: applications should inspect the turn outcome and output. I would record whether work was accepted separately from whether its resources were released. [7]

That is the operational counterpart to keeping useful context for coding agents. Saved knowledge and a live workspace serve different needs. For a recurring job, I would store its accepted output and necessary history deliberately, then decide whether another turn actually needs the same environment.

What would I change in an agent application?

I would make the application track sessions from creation through cleanup, including failed jobs. Each session would have an owner and a retention deadline. After saving the required outputs, a cleanup worker would request deletion, record the response and retry temporary failures within a limit. A separate periodic check would find sessions the normal completion path missed.

This is my proposed application design, not a fix OpenAI says customers needed to prevent its billing incident. Its value is making resource use inspectable. If a charge looks wrong, I want to know which sessions existed, what ran in them and when cleanup was requested.

I would also compare the application’s records with billing data. OpenAI describes session and turn token counts as provisional: they can be missing or change as accounting arrives, and they are not a final bill. Its guidance says to include delegated work, retries and applicable tool or compute charges when estimating the whole task. [6]

Finally, I would check whether the task needs a sandbox at all. The documented environment.type: "none" option can suit work performed through external tools, although it removes built-in Bash, patching and workspace files. I would choose it for jobs whose required tools remain available without that environment. [8]

For the next recurring job, I would review its saved result and its cleanup record together. Both belong to a completed run.