Claude Codeの /compact と /clear と /exit、トークン効率はどう違う？

Yes — natural-language hints work fine. You don’t need exact text.

How /compact <instructions> works

• The argument is focus guidance for the summarizer, not literal text to retain. Claude reads it semantically and biases what gets kept in the compacted summary.
• So /compact Ok, remember the fixing rule that we confirmed first here works as expected — the summary will preserve that rule.

Tips

• Be specific about what matters: “keep the API error handling rule we agreed on” beats “remember important stuff.”
• Reference earlier decisions by topic, not verbatim.
• For rules that must always survive compaction, put them in CLAUDE.md at the project root — those auto-reload after compaction and survive permanently. /compact arguments only affect that one summarization.

Sources:

• Claude Code Commands
• Context Window

うん——自然言語のヒントで問題なく効く。正確なテキストを入れる必要はない。

/compact <instructions> の仕組み

• 引数は要約器に対するfocus guidanceであって、保持する文字列ではない。Claudeが意味的に読んで、compact後の要約に何を残すかをバイアスする。
• なので /compact Ok, remember the fixing rule that we confirmed first here は期待通りに効く——要約はそのルールを保つ。

Tips

• 何が重要かを具体的に書く。「API error handlingで合意したルールを残して」のほうが、「大事なことを覚えていて」より効く。
• 過去の決定は逐語ではなくトピックで参照する。
• compactionを必ず生き延びさせたいルールは、プロジェクトルートのCLAUDE.mdに置く——あれはcompaction後に自動で再ロードされて、永続的に生き残る。/compactの引数はその一回の要約にしか影響しない。

Sources:

• Claude Code Commands
• Context Window

Exactly right. /compact is a best-effort hint to a summarizer LLM — it can drop, reword, or misinterpret your rule. Not reliable for anything that must survive verbatim.

For accurate, durable rules, anchor them in something the model re-reads, not something it summarizes:

• CLAUDE.md (project root or ~/.claude/CLAUDE.md) — auto-injected on every turn, survives compaction unchanged. Best for persistent coding rules.
• GitHub issue / external doc — fetch it back when needed (gh issue view, file read). The exact text re-enters context fresh.
• A file in the repo (e.g. docs/rules.md, __inbox/notes.md) — Read it explicitly when relevant.
• Slash command / skill — codify a workflow so the instructions are loaded by invocation, not by memory.

Rule of thumb: if losing the exact wording would break things, store it as text the model reads, not as conversation it summarizes.

その通り。/compactは要約器LLMに対するbest-effortなヒントで——ルールを落としたり、言い換えたり、誤解したりしうる。逐語で必ず生き残らせたいものには向かない。

正確で永続的なルールは、モデルが要約するものではなく再度読むものに固定する:

• CLAUDE.md（プロジェクトルートか ~/.claude/CLAUDE.md）—— 毎ターン自動注入され、compactionでも変わらず生き残る。永続的なコーディングルールに最適。
• GitHub issue / 外部ドキュメント —— 必要なときに取り戻す（gh issue view、ファイル読み込み）。正確なテキストがcontextに新しく入り直す。
• リポジトリ内のファイル（例: docs/rules.md、__inbox/notes.md）—— 関連するときに明示的に読み込む。
• Slash command / skill —— ワークフローをコード化することで、記憶ではなく起動経由で命令がロードされる。

Rule of thumb: 正確な文言を失うと壊れるものなら、要約される会話ではなく、モデルが読むテキストとして保存する。

B (fresh session) is more token-efficient.

Why

• /compact has to read your entire current conversation as input tokens to generate the summary — that’s a one-time cost proportional to how full the context already is. On a near-full session, that single operation can be tens of thousands of input tokens.
• A fresh /exit + relaunch pays zero summarization cost. You just send a clean prompt with the rules/issue link.
• Prompt cache state is similar after both: /compact invalidates the cache (the prefix changes), and a fresh session starts cold anyway. So no cache advantage for A.
• Going forward, a fresh session typically has a smaller working context than a compacted one (summaries are often longer than what you’d manually re-feed), so every subsequent turn is also cheaper.

When A is still worth it

• The session has lots of implicit context (file reads, tool results, decisions) you can’t easily reconstruct by hand.
• You’re mid-task and losing flow costs more than tokens.

Rule of thumb: if you can express what matters in a paragraph or a link to an issue/CLAUDE.md, B wins on tokens. If “what matters” is fuzzy and spread across the session, pay for /compact.

B（freshセッション）のほうがトークン効率が良い。

なぜ

• /compactは要約を生成するために現在の会話全体をinputトークンとして読む必要がある——これはcontextがどれだけ埋まっているかに比例する一度きりのコスト。near-fullなセッションだと、その一回の操作だけで数万input tokenになりうる。
• fresh /exit + 再起動は要約コストがゼロ。ルールやissueリンクを含むclean promptを送るだけ。
• prompt cacheの状態はどちらでも似たようなもの: /compactはcacheを無効化する（prefixが変わる）し、freshセッションはどのみち冷えた状態で始まる。なのでAにcacheの優位はない。
• 以降は、freshセッションはcompact済みのセッションより作業contextが小さいのが普通（要約は手で再投入する内容より長くなることが多い）なので、毎ターンも安くなる。

Aがまだ価値あるとき

• セッションに暗黙のcontext（ファイル読み込み、ツール結果、決定）がたくさんあって、手で再構築するのが難しいとき。
• タスクの途中で、フローを失うコストがトークンより高いとき。

Rule of thumb: 重要なことを段落一つかissue/CLAUDE.mdへのリンクで表現できるなら、Bがトークン的に勝つ。「何が重要か」がぼんやりしてセッション中に散らばっているなら、/compactの代金を払う。

Yes, it’s actually a strong pattern — better than /compact in most ways.

Token-wise: roughly the same cost as /compact for the one-time write (Claude reads the current context to draft the issue), but cheaper afterward because the fresh session loads only the issue body — usually tighter and more focused than a /compact summary, which tries to preserve everything.

Where it actually wins (beyond tokens)

• Durable artifact. A GitHub issue survives the session, is searchable, linkable, editable, commentable. /compact summaries vanish the moment you close the session.
• Forces clarity. Writing an issue makes Claude structure the problem (repro, what’s tried, current hypothesis). That’s often higher-signal than a compaction summary.
• Multi-session reusable. Future sessions, other people, or future-you can pick it up cold. /compact only helps the current session.
• Cleaner restart. gh issue view <num> re-feeds exactly what you curated — no leftover noise from earlier dead ends.

When it’s overkill

• Trivial or throwaway debugging — the issue is just tracker noise.
• Highly stateful in-flight work (lots of unsaved file edits, half-applied patches) — the issue can’t capture all of that, so /compact (or just keep going) may serve better.
• You’ll forget to close/update it, and your tracker rots.

Verdict: for non-trivial debugging that might span sessions, “make an issue → fresh start” is strictly better than /compact. You pay similar tokens once, gain a permanent record, and run cheaper from then on.

うん、実はかなり強いパターン——多くの面で/compactより良い。

トークン的には: issue作成のための一回の書き込みは/compactとほぼ同じコスト（Claudeが現在のcontextを読んでissueをdraftする）。ただしその後が安い。freshセッションはissue本文だけをロードするから——大抵は/compactの要約より絞られて焦点がはっきりしている。/compactの要約は全部を保とうとする。

トークン以外で勝つところ

• 永続的なアーティファクト。 GitHub issueはセッションを越えて残る。検索でき、リンクでき、編集でき、コメントできる。/compactの要約はセッションを閉じた瞬間に消える。
• 明確化を強制する。 issueを書くことで、Claudeは問題を構造化する（再現、試したこと、現在の仮説）。これはcompaction要約よりシグナルが高いことが多い。
• 複数セッションで再利用できる。 将来のセッション、他の人、未来の自分が冷えた状態で拾える。/compactは今のセッションにしか効かない。
• 再スタートがきれい。 gh issue view <num>は自分がキュレーションしたものをそのまま再投入する——過去の行き止まりの残骸が混ざらない。

やり過ぎなとき

• どうでもいいデバッグや使い捨てのデバッグ —— issueはtrackerの単なるノイズ。
• 状態を強く持つ実装途中の作業（保存していないファイル編集が多数、patchが半端に当たっている）—— issueでそれ全部を捉えられないので、/compact（あるいはそのまま続行）のほうが向く。
• closeやupdateを忘れて、trackerが腐る。

Verdict: セッションをまたぎうる非自明なデバッグなら、「issueを作る → freshスタート」は/compactよりストレートに優れている。一度同じくらいトークンを払って、永続的な記録を得て、以降は安く走る。

For token cost: identical. Both start the next turn with a clean context.

Practical differences

	/clear	/exit + relaunch
Token cost going forward	same	same
Speed	instant	re-init MCP servers, hooks, settings
Shell state (cwd, env vars from prior cd)	preserved	reset
MCP connections	stay alive	reconnect
Background tasks/agents	may persist	gone
Settings/CLAUDE.md changes you just edited	not reloaded	reloaded

Use /clear for the normal case — faster, no reconnection cost.

Use /exit + relaunch when:

• You edited settings.json, CLAUDE.md, hooks, or MCP config and want them re-read.
• Something feels stuck (hung MCP, weird state) and you want a guaranteed clean slate.
• You want to drop all background tasks/agents.

So for your “consumed too many tokens, let’s restart” case → /clear is enough and quicker.

トークンコスト的には同じ。 どちらも次のターンをcleanなcontextで始める。

実用的な違い

	/clear	/exit + 再起動
以降のトークンコスト	同じ	同じ
速さ	即時	MCPサーバー、hook、settingsの再初期化
shellの状態（cwd、cdで設定したenv var）	保たれる	リセット
MCP接続	生き続ける	再接続
バックグラウンドタスク/エージェント	残ることもある	消える
直前に編集したsettings/CLAUDE.md	リロードされない	リロードされる

/clearを使うのが普通——速いし、再接続コストもない。

/exit + 再起動を使うのはこういうとき:

• settings.json、CLAUDE.md、hook、MCP configを編集して、それを読み直してほしいとき。
• 何か詰まっている感じがして（MCPがhang、変な状態）、確実にcleanな状態にしたいとき。
• バックグラウンドタスク/エージェントを全部落としたいとき。

なので「トークン使いすぎ、再起動しよう」というケースには → /clearで十分だし、こちらのほうが速い。