この症状は、Claude Code から送ったリクエスト本文が JSON として受け付けられず、no low surrogate in string というエラーで 400 が返っているケースとして報告されています。今回渡された issue では、少なくとも #60394 と #68744 の両方で、同じ形のエラーが出ています。
まず自分のケースかどうかを見分けるには、エラーメッセージの中に次の文言があるかを確認します。
Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"The request body is not valid JSON: no low surrogate in string: line 1 column 195621 (char 195620)"},"request_id":"req_011
別の報告では、同じ文言で列番号だけが変わっています。
Error: 400 {"type":"error","error":{"type":"invalid_request_error","message":"The request body is not valid JSON: no low surrogate in string: line 1 column 301306 (char 301305)"},"request_id":"req_011
このため、少なくとも issue 上では「Claude Code が送ろうとした本文の JSON 化に失敗し、サーバー側が 400 を返した」ことまでは言えます。ただし、何が JSON を壊したのかは、渡された情報だけでは分かりません。Unicode の文字列に関係している可能性はありますが、断定はできません。
#68744 では、動的ワークフローの途中でリミットに達し、その後まとめを一度に依頼したところ、再び 5 時間制限に達したという報告もあります。ですが、貼られている実際のエラー自体は上と同じ JSON エラーです。なので、今回の症状クラスタは「レート制限そのもの」というより、少なくとも表に出ているエラーは JSON 不正です。/usage では詳細が分かりにくい、という不満もこの issue には書かれていました。
同様の件として、コメント欄では重複 issue の候補が 3 件挙げられており、#60394 は実際に重複として閉じられています。現時点では、単独の回避策がこの情報だけで確定しているとは言えません。
検証環境については、手元で取得できた情報は次の通りです。
[env_summary]
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-08T08:51:10+09:00
この環境情報は、今回の issue で報告されている症状を再現した結果ではなく、記事作成時の参照情報です。再現手順までは確認できていません。
もし同じエラーに遭遇したなら、まずはエラーメッセージ全文を残し、#60394 と #68744 を見比べるのが近道です。特に no low surrogate in string が含まれているか、request_id が付いているかを確認すると、同系統かどうかの切り分けに使えます。
OS : Linux 3.10.0-1160.76.1.el7.x86_64 (x86_64)
Python : 3.8.13
検証日時 : 2026-09-08T08:51:10+09:00