Claude Code の利用上限と、当たらなくする方法

Claude のサブスクリプションは利用量で計られ、メッセージ数では計られません。同じ週に同じ数のプロンプトを送った 2 人が、まったく違う結果になりえます。片方は毎回リポジトリを丸ごと添えて質問し、もう片方はそうしていないからです。

上限が数えているもの

おおまかに言えば、カウンタはモデルで重み付けされた処理済みトークンの上を走ります。つまり 3 つのことが言え、3 つ目は意外に思われます。

• →長いセッションは 1 ターンあたりのコストが短いセッションより高くなります。毎回、記録全体が送り直されるからです。
• →同じ作業でも、大きいモデルは小さいモデルよりトークンあたりのコストが高くなります。
• →ファイルを読むことは無料ではありません。1 行の質問に答えるために 6 つのファイルを開くエージェントは、1 行の質問ぶんの枠を 6 回使ったことになります。

上限が、静かな週の終わりよりも生産的な一日の午後に来やすいのはこのためです。ここでの生産的とは長いセッションのことで、長いセッションは二次的に効いてきます。各ターンがそれ以前のすべてのターン分を払うからです。

なぜいつも作業の途中で来るのか

高くつくターンが中盤にあるからです。セッションの最初のターンは安い。20 ターン目は 19 ターンぶんの記録に加えて、途中で読んだすべてのファイルと、すべてのテスト出力を抱えています。計画中に切られることはなく、仕上げの最中に切られます。

本当に効く 4 つの習慣

一週間で見たときの効き目の大きい順に:

• →作業ごとに新しいセッションを開く。これが最大です。この一覧の他のどれも及びません。
• →ファイルを説明せずに名指しする。探索はエージェントがする最も高価なことです。
• →機械的な作業は小さいモデルに。改名、整形、単一ファイルの編集。
• →うるさいコマンド出力を履歴から遠ざける。届く前に絞り込む。

働き方を変えずに実現する

上の習慣は有効ですが、毎ターン規律を要求します。人が水曜日にはやめてしまう類のものです。もう一つの道は、コンテキストに上限を置き、自動でそれを守らせることです。

$npm i -g @penra/capsul

$capsul ask '失敗している認証テストを直して' --budget 3000

すでに当たってしまったら

ウィンドウの途中でセッション上限をお金で回避する方法はなく、リセットするオプションもありません。できるのは、次のウィンドウを前回より長くもたせることであり、それは何ターン回すかではなく、各ターンが何を抱えるかの問題です。