One Claude Code Tip a Day: Check /cost Before the Session Sprawls

This post is part of the “One Claude Code Tip a Day” series — a daily guide to using Claude Code more effectively.

The failure: a cheap bug turns into an expensive fog

The dangerous Claude Code session is not the one that spends money. It is the one that spends money while getting less certain. You start with a small frontend bug: the save button stays disabled after a form error. Claude reads a component, edits a hook, runs one test, then follows a failing lint warning into a helper rename, then inspects a route loader, then suggests changing validation copy. Thirty minutes later the diff is wider, the bug is still vague, and the thread has enough context to sound confident about almost anything.

Today’s tip is to use `/cost` as a workflow checkpoint, not as a receipt. Cost is a signal that the session may be sprawling. When the number jumps, pause the coding loop and ask whether the next token will buy evidence or just produce another plausible patch.

Run /cost before the session feels out of control

I like to check cost at three moments: after the initial read-only investigation, after the first failed verification, and before accepting any second-pass patch. In Claude Code, type `/cost` and treat the output as a prompt to re-scope the session.

A useful pattern is: `/cost`, then: `We have spent enough context on this bug to justify a checkpoint. Summarize what is proven, what is still a guess, what files changed, and the single next command that would most reduce uncertainty. Do not edit yet.`

This turns cost into engineering pressure. If Claude says it has inspected `FormPage.tsx`, `useSaveForm.ts`, and the failing Playwright spec, but cannot name the exact state transition that keeps the button disabled, the next move should not be a patch. It should be a reproduction or a focused log.

Use cost to choose the next loop, not to feel guilty

The point is not to minimize tokens at all costs. A careful read of a complicated payment flow may be worth more than a cheap blind patch. The question is whether the cost is buying a narrower model of the system. After `/cost`, ask Claude to classify the session:

Prompt: `Based on the current cost and evidence, choose one: continue, compact, switch model, clear and restart, or stop for human review. Justify the choice with concrete evidence from files, commands, logs, or the current diff.`

For example, if the session has read the right files, produced a small diff, and one focused test is failing with a new assertion, continuing is reasonable. If the thread contains three abandoned theories and two unrelated helper edits, `/compact` or `/clear` may be smarter. If the task turned from copy change into auth-state debugging, `/model` may be justified. If the diff touches five files for a one-button bug, stop and review.

A real workflow: failing UI state after an API error

Imagine the bug report says: after a 409 response, the account settings form shows the error but never re-enables Save. Start normally: ask Claude to read before editing. `Inspect the settings form, save hook, and tests. Do not edit. Identify the state machine that controls the Save button and the smallest reproduction command.`

Claude finds `AccountSettingsForm.tsx`, `useAccountSave.ts`, and `account-settings.spec.ts`. It proposes that `isSubmitting` is never reset on conflict. Before editing, run `/cost` and checkpoint: `What evidence proves this is the right seam? What have we not read?` If the answer cites the catch branch and an existing test path, allow one narrow patch. Then run `!pnpm test -- account-settings` or the project’s focused equivalent.

Now suppose the test still fails. This is where `/cost` matters. Instead of asking “fix it,” ask: `The focused test still fails. Update the checkpoint. Which assumption was wrong? What is the next cheapest command or inspection that separates a stale test fixture from a real UI state bug?` The session may discover that the mock returns 409 but never resolves the promise shape used by the hook. The second patch becomes a test-fixture correction plus a smaller production change, not another sweep through the UI.

Review the diff after the cost checkpoint

Before you accept the patch, make Claude compare the cost story to the actual diff. Run `!git diff --stat` and `!git diff`, then prompt: `Review this diff against the last /cost checkpoint. Which changes directly reduce the named uncertainty? Which changes are opportunistic? Which verification result proves the Save button recovers after 409?`

This catches a common failure mode: Claude spends a long session and then tries to justify every edit as part of the journey. Cost checkpoints should make the final review harsher, not softer. If a helper rename, copy tweak, or broad refactor did not appear in the checkpoint, revert it or ask for a separate rationale and test. The more expensive the session, the more disciplined the diff review should become.

Failure modes

The first failure mode is using `/cost` too late, when the thread is already a swamp. Check it before the second patch, not after the fifth. The second is treating cost as proof of quality. A costly session can still be shallow if it never reproduced the bug. A cheap session can be excellent if it reads the right file, makes one edit, and verifies the exact failure signal.

The third failure mode is optimizing for cheapness instead of confidence. Do not refuse necessary investigation just because the number rose. Use cost to ask whether the next step is targeted. If Claude can name the next command, expected signal, and decision that follows from each possible result, keep going. If it can only say “I’ll inspect more,” narrow the scope first.

Rule of thumb

Use `/cost` whenever a Claude Code session crosses from execution into exploration. My rule: after `/cost`, the next prompt must buy evidence. It should name one uncertainty, one command or file inspection, and one decision that will follow from the result. If the session cannot do that, do not spend the next tokens on another patch. Spend them on a checkpoint, a compact summary, a model switch, or a clean restart.