invalid_request_error\ が出るときにまず見る場所この症状クラスタに含まれる 2 件の issue は、見え方は違いますが、どちらも「リクエストの中身が大きすぎる／重なりすぎる」方向の問題として読めます。
ただし、実際に invalid_request_error\ というエラー文字列が本文中にそのまま出ている issue は、今回渡された情報の中にはありません。そこは断定できません。検索用の文字列としてタイトルには入れていますが、報告内容ベースで確認できるのは以下です。
まず、 #37793 では、MCP サーバーを多数ユーザー側で設定していると、サブエージェントが開始直後に prompt is too long: 209117 tokens > 200000 maximum で失敗すると報告されています。しかも TUI には Done (0 tool uses · 0 tokens · 44s) と出て、ユーザーにはエラーが見えにくかった、とあります。
この報告だけを見ると、サブエージェントに渡るプロンプト量が上限を超えたケースです。invalid_request_error\ という見た目のエラーになっていなくても、実質的には「要求が大きすぎて送れない」系の失敗として扱うのが近いです。
もう 1 件の #70025 は、単純なリポジトリ調査のはずなのに cache reads / writes が異常に増え、$94.46 の請求になったという報告です。報告者は、何度も失敗して再試行しているような挙動、あるいは bug の可能性を疑っています。こちらはエラー文言の直接報告ではなく、コストと cache 使用量の異常です。
つまり、あなたが見ている症状が「いきなり拒否される」「やり直しが繰り返される」「トークンや cache が想定外に増える」のどれかなら、この 2 件のどちらかに近い可能性があります。
切り分けの起点は単純です。
サブエージェント開始前に失敗していて、しかも MCP サーバーを多く使っているなら #37793 側を疑います。
一方で、明確なエラー表示は乏しいのに cache の読み書きや料金だけが膨らむなら #70025 に近いです。
手元で確認できる一次情報は、環境の概略だけです。
[env_summary]
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-24T08:51:55+09:00
この情報だけでは、原因を再現したり、回避策の実効性を確認したりまではできません。
少なくとも今回の issue 群から言えるのは、「invalid_request_error\ に見える失敗」は、実際にはプロンプト過大や tool schema の肥大化、あるいは再試行の連鎖として現れている可能性がある、ということです。逆に、どの経路でそうなったかは、報告だけではまだ特定できません。
もし自分のケースを照らすなら、次の順で見れば十分です。MCP サーバー数が多いか、サブエージェントが即死していないか、そして cache 読み書きや料金が不自然に増えていないか。そこが一致するなら、この症状クラスタにかなり近いです。
一致しないなら、現時点では別件の可能性があります。
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-24T08:51:55+09:00