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

概要

Claude Codeのセッション管理まわり、/compact <hint>の引数の効き方とか、/compactと/exit+再起動と/clearがトークン的にどう違うのか、あと「GitHub issue作って新セッションで再開」のパターンが本当にお得なのか、みたいなのをClaude本人と話したログ。

会話ログ

Takazudo

Claude Code has slash-compact feature. we can pass the arg for this. as the result, how does this rule work? for example, we did many things in a session, then do

slash-compact Ok, remember the fixing rule that we confirmed first here

this kind of copmact works? or do I need to input exact the text I want you to momorize?

Claude

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

Takazudo

good. but in fact, how it summarize is up to the LLM’s decision. so the accurate ruling must be feeded by text or something like github issue, right?

Claude

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.

Takazudo

Q: which is effective for token consumption?

• A: do slash-compact with proper summarize or text feeding like this
• B: slash-exit and relaunch Claude Code with fresh session, then feed the proper info

Claude

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.

Takazudo

I often do like this.

Well, we’ve consumed pretty huge token here. So we’ll continue debugging on the new session. So please make issue for it. We’ll start with that issue.

Is this worthy? Or if we do this, it might have the recording to somewhere benefit, but as the token consumption and rememberance of the session, it’s almost same?

Claude

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.

Takazudo

well, what about these 2 difference?

A: slash-clear -> feed the proper prompt B: slash-exit, launch again -> feed the proper prompt

maybe same?

Claude

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

Practical differences

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.