親: #827
何をするか
待つ間の繰り返し問い合わせ（ポーリング）をやめる。 待ち方は次の 2 つにそろえる。
run_in_background で起動し、完了の通知を待つMonitor の until で、条件が満たされるまで 1 回だけ待つ
sleep を挟んだループと、出力ファイルの繰り返しの読み直しは、規約で禁止し、hook でも止める。
例: ai-plugins の会話 58dfb551 では、サブエージェント「実装D-2 #495 」が空のタスク出力ファイル（/tmp/.../tasks/brn6s0kil.output など）を 2,229 回 Read した。どの結果も the file exists but the contents are empty だった。文脈が最大 69 万トークンまで膨らんだ状態で読み直しを続けたため、この 1 件だけで 109M（input 換算）を使った。これは 30 日間のサブエージェント全体の費用の 14% にあたる。
なぜ
#827 の実測（ポーリングの費用）:
範囲
全体の費用に占める割合
2026-09-20 以降、全プロジェクト
16%（40M）
ai-plugins、30 日間
19%（258M）
問い合わせを 1 回するだけで、その時点の文脈を丸ごと読み直す。文脈が 50 万トークンあれば、中身が空の確認 1 回に約 5 万トークン分（input 換算）がかかる。
方針（案）
development-workflow/references/agent-layers.md と parallel-work.md に待ち方を 1 つの節としてまとめ、worker への指示の雛形にも入れるPreToolUse hook で次を拒否し、代わりの待ち方を案内する
同じファイルへの Read が N 回続いたとき
sleep <秒> を含む Bash
メモ「サブエージェントは待ちで止まる」の対策（待ち方を指示に書く）が sleep ループを生んでいる可能性がある。指示の文面も見直す
受け入れ条件
実機の確認（AC11、2026-09-23、Claude Code 2.1.280）
手順: supervisor から worker（サブエージェント）を起動し、worker が codex exec --skip-git-repo-check "Reply with exactly the word PONG and nothing else." を Bash の run_in_background: true で起動した直後に、他のツールを呼ばずに応答を終えるよう指示した。
結果:
親（supervisor）には、worker が応答を終えた時点で 1 度「終わった」と通知が届き、途中の文面（「背景で起動した。完了通知を待つ。」）が結果として渡った。通知の注記は「背景の処理が残っている。再開しうる」
codex は 6 秒で終わり、その約 2 秒後に完了通知で worker が再開した。出力（PONG）を 1 回だけ読んで報告を出し直し、親に 2 回目の通知が届いた
完了通知で再開はされるが、親には 1 度完了として返る。 この結果を development-workflow/references/waiting.md に書いた（サブエージェントは背景の処理を残したまま応答を終えない。親は 2 回目の通知を待つ）。他の作業が無いまま待つときの手は cross-review / cross-refactoring をサブエージェントへ委ねると、ラウンドの待ちで応答を終えて止まる #656
実装 Pull Request #844 の本文の Test plan にも同じ結果がある。
進行
モード: standard / 作業ツリー: .worktrees/feature/issue-829-830-token-waits / 計画: issues/issue-829-830-implementation-plan.md
親: #827
何をするか
待つ間の繰り返し問い合わせ（ポーリング）をやめる。 待ち方は次の 2 つにそろえる。
run_in_backgroundで起動し、完了の通知を待つMonitorの until で、条件が満たされるまで 1 回だけ待つsleepを挟んだループと、出力ファイルの繰り返しの読み直しは、規約で禁止し、hook でも止める。例: ai-plugins の会話 58dfb551 では、サブエージェント「実装D-2 #495」が空のタスク出力ファイル（
/tmp/.../tasks/brn6s0kil.outputなど）を 2,229 回 Read した。どの結果もthe file exists but the contents are emptyだった。文脈が最大 69 万トークンまで膨らんだ状態で読み直しを続けたため、この 1 件だけで 109M（input 換算）を使った。これは 30 日間のサブエージェント全体の費用の 14% にあたる。なぜ
#827 の実測（ポーリングの費用）:
問い合わせを 1 回するだけで、その時点の文脈を丸ごと読み直す。文脈が 50 万トークンあれば、中身が空の確認 1 回に約 5 万トークン分（input 換算）がかかる。
方針（案）
development-workflow/references/agent-layers.mdとparallel-work.mdに待ち方を 1 つの節としてまとめ、worker への指示の雛形にも入れるsleep <秒>を含む Bashsleepループを生んでいる可能性がある。指示の文面も見直す受け入れ条件
sleepループを拒否し、代わりの待ち方を案内する（テストがある）実機の確認（AC11、2026-09-23、Claude Code 2.1.280）
手順: supervisor から worker（サブエージェント）を起動し、worker が
codex exec --skip-git-repo-check "Reply with exactly the word PONG and nothing else."を Bash のrun_in_background: trueで起動した直後に、他のツールを呼ばずに応答を終えるよう指示した。結果:
PONG）を 1 回だけ読んで報告を出し直し、親に 2 回目の通知が届いたdevelopment-workflow/references/waiting.mdに書いた（サブエージェントは背景の処理を残したまま応答を終えない。親は 2 回目の通知を待つ）。他の作業が無いまま待つときの手は cross-review / cross-refactoring をサブエージェントへ委ねると、ラウンドの待ちで応答を終えて止まる #656 が扱う実装 Pull Request #844 の本文の Test plan にも同じ結果がある。
進行
モード: standard / 作業ツリー:
.worktrees/feature/issue-829-830-token-waits/ 計画:issues/issue-829-830-implementation-plan.md