Repository navigation
OpenAI Responses (gpt-5.5): 500 server_error doom-loop when too many tools are enabled #33006
Closed as not planned
Description
Summary
When many tools are enabled (e.g. several MCP servers), opencode sends every tool definition in a single OpenAI Responses request. The ChatGPT/Codex OAuth backend rejects requests carrying too many tools with a generic 500 server_error. Because the retry policy has no attempt cap for 5xx, opencode then retries the same oversized request indefinitely — turning it into a multi-hour doom-loop that makes the model (e.g. gpt-5.5) effectively unusable.
Steps to reproduce
- Configure a setup with a large number of enabled tools (many MCP servers — ~870 tool definitions in my case).
- Use an
@ai-sdk/openaimodel on the ChatGPT/Codex OAuth path (e.g. gpt-5.5). - Send any prompt that triggers a model turn.
Expected
The request succeeds, or fails with an actionable error.
Actual
The backend returns a 500 server_error and opencode retries the identical request with no cap, looping for hours.
Notes on root cause
- Reproduced with 876 tool definitions: 5
server_errors and a stuck loop. The same prompt with--pure(11 tools) works, confirming tool count is the trigger — not schema, request size, or reasoning threading. - The retry policy applies to 5xx with no max-attempt cap, which amplifies the single rejection into the loop.
Environment
- Model: gpt-5.5 (OpenAI Responses, ChatGPT/Codex OAuth)
- Runtime: AI-SDK path (
@ai-sdk/openai)
Metadata
Metadata
Assignees
Labels
No labels
Activity
github-actions commentedon Jun 19, 2026
This issue might be a duplicate of existing issues. Please check:
Your issue is well-written and adds useful detail (the specific 500 doom-loop on the ChatGPT/Codex OAuth path with
gpt-5.5and ~870 tools), but please review the above issues to see if your report can be consolidated there.nexxeln commentedon Jun 21, 2026
why do you want so many tools?
Necmttn commentedon Jun 21, 2026
This needs two independent guards: preflight on tool inventory and bounded retry. Before sending, compute tool_count, tool_schema_bytes, provider/tool limit if known, and request body size, then fail with the top contributors when over limit. After a 5xx with unchanged request hash, retry should cap quickly and mark terminal_failure instead of replaying the same oversized payload for hours.
Generated with ax.
github-actions commentedon Aug 21, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.