Hi everyone,
I’m running o3 deep research in background mode to generate a long-form report with charts using web_search_preview and code_interpreter tools. My input file is a CSV (uploaded to the container).
The issue I’m facing:
The container expires suddenly before the response is completed.
last_active_at is being updated frequently, so it should remain active.
When the container expires, last_active_at is still < 30 seconds from the current time (so it should not be idle-expired).
This usually happens if the deep research response takes more than ~30 minutes.
I am unable to set expires_after.minutes to more than 20 minutes, so I rely on anchor: "last_active_at".
Even with continuous activity, the container shuts down before completion.
Questions
Is there a global timeout limit for o3 deep research tool execution or per-response run?
Is there a recommended way to run long background jobs without premature container expiry?
Any best practices for generating multi-step reports or charts that take longer than 30 minutes?
Has anyone else faced this, or can someone from OpenAI clarify the intended behavior?
A code interpreter container that is getting its ‘last active’ constantly updated by model use should not and must not expire.
It could be the case that the deep research model, primarily an internet-searching AI that follows its own instructions and not yours, is not actively calling code interpreter, however then you should be able to observe a growing time since the container was last active.
So it seems like a bug. You should be able to “research for 20 minutes in the background at low priority” to the model and then, “make a code interpreter file with your findings” at the terminus without error.
Behavior was also altered, or not adequately altered, by the bug of being billed over and over for an undelivered container ID when the code interpreter tool was not called being “fixed”, and this may not have completely altered the pattern actually needed for “auto” tool use.
A difficult workaround: retrieve the background job, retrieve the chat state, get the code interpreter container ID (that should now be offered if one was created, the other bug issue that might have been overlooked by a billing patch), and then keep it active with little file uploads.
The real fix is to have intentional containers active for a far longer time than 20 minutes without expiry. The scheme seems like paying for something that is a nearly free resource, and then forcing you to pay again.
Thanks for the response. I am already using .retrieve() to keep the container active. However, despite the last_active_at being within the last 60 seconds, the container unexpectedly expires.
I’m also having this issue when using the code interpreter tool. In my case, the container expires within 3 minutes of the last-active time (which is also within 3 minutes of the start of the agent call).