Responses API charges Code Interpreter, even if not used

Hi Markus von Staden

Sorry for the inconvenience.

If you are setting tool type as code interpreter with mode

 "container": {"type": "auto"}

the Responses API eagerly creates a container for the turn, even if the model never issues a code_interpreter_call in its output items. That container creation is billable.

Community reports indicate the API may create a new (billable) container per turn until the model finally decides to use the tool and returns a code_interpreter_call item exposing the container_id. Only then can the same container be reused; before that, each turn can still be charged.

This behavior deviates from Assistants API, where CI sessions were only billed when actually used.

Suggestions

1. Don’t include CI unless you need it on that turn
   • Only add tools: [{ "type": "code_interpreter", "container": {"type": "auto"} }] on requests that you expect will actually require Python execution.
   • For pure chat/QA turns, omit the CI tool completely to prevent eager container creation (and the charge). [community.openai.com]
2. Use tool-choice to discourage CI
   • When supported for your model/SDK, set tool_choice: {"type":"none"} (or avoid passing any tools) on turns that shouldn’t touch CI.
   • Note: Some GPT‑5 model/SDK combinations restrict tool choices to 'auto' for certain tools, so this lever is model/SDK‑dependent. Track the SDK issues for current constraints. [github.com]
3. Gate CI behind intent detection
   • Do a first pass with no tools, ask the model “Please go with code interpreter if you need apython tool?” (or do your own heuristic).
   • If the answer is yes, issue a second request with CI enabled; if no, continue without CI.
   • This “two‑step” keeps CI containers from being created on non-compute turns.
4. Prefer explicit reuse once CI is actually used
   • After you see a code_interpreter_call item, capture the container_id from that item and reuse it in subsequent turns (instead of relying on auto). This reduces repeated container setups. (If your SDK doesn’t expose explicit container reuse primitives, track the maintainers’ guidance/workarounds in the issues.) [github.com]

           
           
           container = client.containers.create(name="test-container")
           
           response = client.responses.create(
               model="gpt-4.1",
               tools=[{
                   "type": "code_interpreter",
                   "container": container.id
               }],
               tool_choice="required",
               input="use the python tool to calculate what is 4 * 3.82. and then find its square root and then find the square root of that result"
           )
     

5. Audit your billing and logs
   • Correlate turn-level request logs with Code Interpreter line items to quantify where containers are created without a call. This will help you verify the impact of mitigation #1 and #3 over time. (The MS Q&A thread you referenced is consistent with this audit outcome.

Reference used

1. https://community.openai.com/t/responses-api-excessive-charges-due-to-repetitive-container-creation-when-using-code-interpreter/1364328
2. https://platform.openai.com/docs/guides/tools-code-interpreter

https://learn.microsoft.com/en-us/azure/ai-foundry/openai/how-to/responses?tabs=python-key#code-interpreter

Hope it helps.

Thank you.

Do I understand this correctly: This isn’t a bug but the intended behavior? That’s a massive downgrade from the Assistants API and really, really bad!

Markus von Staden

Sorry for the experience. will check with team internally and update you.

Thank you.

Update for everyone interested:
This really was a bug and at least OpenAI has deployed a fix. I don't know if Azure will deploy a fix too and if we get the falsely billed containers refunded.
Source: https://community.openai.com/t/horrible-code-interpreter-bug/1366600/9