メッセージ数は、トークン消費を正確に比較する指標になるとは限りません。「このエラーを直して」という指示が1行の修正で終わる場合もあれば、大規模なリポジトリ調査、何往復ものデバッグ、大量の出力につながる場合もあります。OpenAI の料金と利用量の説明では、モデル、コンテキストの大きさ、推論トークン、ツール呼び出し、コード検索、キャッシュが消費に関わるとされています。入力した指示は作業の入口にすぎません。
履歴から避けられる作業を見つける
最近 Codex の制限に達したタスクを振り返ってください。同じ大きなファイルを何度も読み直していませんか。シェルコマンドでログ全文をプロンプトに流し込んでいませんか。途中で作業範囲が広がっていませんか。こうしたパターンの確認は不要な作業の特定に役立ちます。
「ログインエラーを直してコードベースを近代化して」のような指示には明確な境界がありません。代わりに、対象を絞った目標を示してください。
- 空のログインフォームを送信したときのクラッシュを再現し、条件を特定する。
- 該当ハンドラーを修正し、単体テストを実行する。
- 他に見つかった問題は報告し、依頼のない編集はしない。
明確な目標と終了条件は無関係な作業を防ぐ助けになりますが、一定の利用量削減を保証するものではありません。
推論の強度、並列サブエージェント、Fast モード
サブエージェントのドキュメントでは、個別のモデル・ツール呼び出しについて説明しています。推論の強度を上げることもトークン使用量を増やします。並列化で待ち時間が減っても、エージェント数から利用枠の倍率や節約率を固定で求めることはできません。
小さな文書更新などの日常作業では、最大の推論や複数のサブエージェントが必要になることは多くありません。強い推論は難しい根本原因の調査に使い、サブエージェントには明確な担当ディレクトリを設定してください。
Fast モードも確認してください。OpenAI の速度に関する説明では、Fast モードは低遅延のためにより多くのクレジットを消費するとされています。CLI では /fast status で確認できます。厳しい締め切りの際に使い、通常の応答時間で十分なら無効にしてください。
上限到達後の選択肢：リセットを待つかクレジットを追加する
小さな仕上げだけが残っている場合は変更を保存し、未完了の作業を記録して予定のリセットを待ちます。締め切りが迫っている場合は、必要最小限の次の手順を決めてからダッシュボードの追加クレジットを検討してください。公式料金ガイドに、通常の制限を超えて利用するための対象クレジットの説明があります。
API キーへの切り替えは別の課金経路であり、サブスクリプション利用枠のリセットではありません。認証ドキュメントでは API が従量課金であることを説明しています。新しいスレッドを開始しても、モデルのチェックポイントを変更しても、使い切った Codex の利用枠は戻りません。