Repository navigation
Conversation
github-actions
Bot
added
needs:compliance
|
Thanks for your contribution! This PR doesn't have a linked issue. All PRs must reference an existing issue. Please:
See CONTRIBUTING.md for details. |
github-actions
Bot
removed
needs:issue
needs:compliance
|
Thanks for updating your PR! It now meets our contributing guidelines. 👍 |
|
Thanks for isolating this. I hit the same failure mode locally with a very large tool surface while working on a separate stale-continuation recovery patch. I intentionally did not open a duplicate PR for the OpenAI Responses tool-count cap because this PR already covers that part. In my local validation, capping the submitted tool definitions separately from the stale-continuation/model-recovery fix was the right split: the tool cap prevents the OpenAI 500/server_error loop, while the continuation fix prevents internal retry/fallback rows from becoming the durable session model. Relevant local checks from the separated branch:
Prepared with AI assistance. |
69fa246 to
b9cc4fb
Compare
b9cc4fb to
7b6d727
Compare
7821113 to
2b4c9cb
Compare
2b4c9cb to
26933e3
Compare
|
Automated PR Cleanup Thank you for contributing to opencode. Due to the high volume of PRs from users and AI agents, we periodically close older PRs using automated criteria so maintainers can focus review time on the most active and community-supported contributions. This PR was closed because it matched the following cleanup criteria:
PRs created within the last month are not affected by this cleanup. If you believe this PR was closed incorrectly, or if you are still actively working on it, please leave a comment explaining why it should be reopened. A maintainer can review and reopen it if appropriate. Thanks again for taking the time to contribute. |
Issue for this PR
Closes #33006
Type of change
What does this PR do?
When many tools are enabled (lots of 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, and because the retry policy has no attempt cap for 5xx it loops indefinitely — which makes gpt-5.5 effectively unusable.This caps the tool set at 128 (OpenAI's documented function ceiling) for
@ai-sdk/openaimodels, right afterLLMRequestPrep.prepare. Built-in/core tools are registered first, so the slice keeps those and drops the long MCP tail, logging a warning when it trims. 128 is conservative — happy to change the number or make it provider-configurable.Note: the experimental native runtime (
openai-responses.ts) usesinput.toolsrather thanprepared.tools, so it isn't covered here — can extend if wanted. A complementary fix would be a max-attempt cap for 5xx in the retry policy so any future provider 500 can't loop forever.How did you verify your code works?
Reproduced with gpt-5.5 + 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, size, or reasoning threading). After the cap:bun typecheckclean inpackages/opencode, and running from source against the same 876-tool setup logscapping total=876 kept=128, completes a full tool round-trip, and exits withserver_errors=0.Screenshots / recordings
N/A — no UI change.
Checklist