AIエージェントやバックグラウンド処理の完了を短い間隔でポーリングする運用では、各pollが単なる軽量な状態確認ではなく、会話コンテキストを再読する新しいモデルターンを起こすことがある。長いセッションほどキャッシュ済み入力でも処理時間とトークンが積み上がり、待機対象の実行時間以上にオーケストレーター側の生成時間を増やす。

実測では約87分の処理で30秒中心のpollを166回行い、明示的待機51分に対してモデル生成・イベント処理が約30分、キャッシュ済み入力が約2,546万トークン増えた。短周期化しても完了検知は数十秒しか改善しない一方、各pollの固定コストは回数分増える。

完了通知を受け取れる場合はイベント駆動にする。できない場合はUI更新要件が許す最大間隔（例: 60秒）で待ち、状態変化がない生存報告のためだけにモデルターンを起こさない。実行中プロセスの監視はCPUや出力更新など機械的シグナルに寄せ、LLMは完了・異常・判断が必要な変化だけ処理する。

検証は処理全体の壁時計だけでなく、poll回数、待機時間、LLM生成時間、キャッシュ済み入力増分を前後比較する。待機対象の所要時間が同じなのにpoll回数とキャッシュ済み入力が減れば、改善が効いている。