One Claude Code Tip a Day: Put a Price on the Loop

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

A real failure: the bug fix that quietly became three jobs

The most expensive Claude Code sessions rarely feel expensive while they are happening. You start with one reasonable task: “fix the flaky checkout test.” Claude reads the test, edits a helper, runs the suite, sees a different failure, patches a mock, reruns, then starts explaining why the Playwright trace might be stale. Forty minutes later you have a partial fix, a noisy diff, and no clear sense of whether the session was worth the spend.

That is where `/cost` is useful. Not as guilt. Use it as a checkpoint for deciding whether the current loop still deserves more tokens, or whether you should narrow the task, clear context, switch models, or stop and inspect the evidence yourself.

The command

In Claude Code, run:

`/cost`

The exact display can vary by account and version, but the intent is simple: make the cost of the current session visible. The productive habit is not merely checking the number. The habit is using the number to change how you drive the next step.

Run `/cost` at three moments: after the first failed implementation, before second-pass debugging, and before asking for a broad review. If the cost is still small, exploration may be fine. If the cost is already high and the evidence is weak, the right move is usually not “try harder.” The right move is “make the loop smaller.”

A field workflow: price the loop before continuing

Imagine a Next.js app where checkout intermittently fails because the tax total is sometimes one cent off. You ask Claude:

`Read @apps/web/lib/pricing.ts, @apps/web/lib/tax.ts, and @apps/web/tests/checkout.spec.ts. Do not edit yet. Explain the likely source of the one-cent mismatch and name the smallest test that would prove it.`

Claude notices that one path rounds per line item while another rounds after summing. Good. You let it make the smallest change:

`Implement the minimal fix. Then run the focused checkout test and show me the git diff.`

It edits `pricing.ts`, runs:

`!pnpm test apps/web/tests/checkout.spec.ts`

The test still fails, now in a discount case. This is the fork in the road. Many developers keep prompting: “fix it,” “try again,” “look deeper.” Sometimes that works. Sometimes you are buying a longer confusion loop.

Instead, run:

`/cost`

Then give Claude a budget-aware correction:

`The first fix did not close the loop. Before spending more time, summarize what we know from the failing test, what changed in the diff, and the next single command that would most reduce uncertainty. Do not edit code.`

This prompt turns `/cost` into a forcing function. Claude has to separate evidence from momentum.

What to inspect after `/cost`

First, inspect whether the session has been mostly reading, editing, or retrying. A high-cost reading session may be acceptable if you are onboarding to an unfamiliar codebase. A high-cost retry session with no passing verification is a warning sign.

Second, inspect the diff-to-cost ratio. Run:

`!git diff --stat`

If you spent a long session and the diff touches six unrelated files, pause. Ask Claude to justify every file:

`Review the current diff. For each changed file, explain which failing test or observed bug required that change. If a change is speculative, mark it for revert.`

Third, inspect whether you are paying for the wrong model at the wrong phase. `/cost` pairs naturally with `/model`: measure first, then decide whether to stay, switch down for routine edits, or switch up for a difficult second-pass review.

Failure mode: cost-cutting instead of cost control

The wrong lesson is “spend less.” That produces shallow work: no tests, no browser verification, no log inspection, and fragile patches that look cheap only because you stopped before finding the bug.

The better lesson is cost control. Spend deliberately on the parts that reduce risk. For a frontend rendering bug, it may be worth paying for a careful pass over CSS, screenshots, and browser devtools output. It is not worth paying for five speculative edits without a screenshot or reproduction command.

A good correction prompt is:

`We are in a potentially expensive loop. Stop making changes. Build a table with: hypothesis, evidence for it, evidence against it, command or inspection to verify it, and expected result. Then recommend whether to continue, revert, or ask for human input.`

That prompt is especially useful in deployment debugging. Claude may chase local tests while Railway logs clearly show `DATABASE_URL=localhost`, a missing env var, or a worker starting before migrations complete. `/cost` reminds you to stop the loop and ask for the next evidence-producing command, not another patch.

Second-pass correction: buy certainty, not motion

After `/cost`, your second pass should be narrower than your first. Do not say:

`Keep debugging until it passes.`

Say:

`Run only the focused checkout test. If it fails, do not edit. Paste the failing assertion, identify the exact rounding path involved, and propose one-line change options with trade-offs.`

Or, for a frontend bug:

`Do not touch code yet. Use the existing screenshot/test output to distinguish CSS invisibility from missing data. Name the browser inspection that would settle it.`

The point is to buy certainty. Claude Code is excellent when you feed it evidence and ask it to reduce uncertainty. It becomes expensive when you reward motion: more edits, more files, more confident explanations.

Rule of thumb

Run `/cost` whenever a session changes from “one task” into “a loop.” If the cost is rising and confidence is not, stop editing and ask for evidence. If the cost is rising but each step is producing tighter tests, cleaner diffs, and clearer logs, keep going.

Claude Code is not free magic, and it is not a meter you should fear. Treat `/cost` like a dashboard light: it tells you when to keep driving, when to slow down, and when to pull over before the debugging trip becomes the bug.