Claude Code prompt caching: test the 20x claim

Why it matters

Working with AI on substantial documents involves pauses. You inspect a table, check a calculation, collect corrections, and return with the next instruction. Those gaps are part of producing reliable work, and they can affect how efficiently previously processed context gets reused.

Macks Wendhell’s video describes moving established Claude projects from browser chat into Claude Code. His example is a statistical reporting workflow, but the decision applies more broadly to technical research, recurring business reports, and document production. A useful migration preserves the working process while improving its economics.

My take is that the workflow deserves a measured trial. The headline’s “20x” combines a cache pricing relationship with an account of subscription usage. Those are different measurements. I would judge the move on usage, accepted output quality, and the human time needed to correct the result. The procedure below is a proposed evaluation method, rather than a claim that Luiz has independently reproduced the savings.

Key points

• 01:41 Your review schedule affects the economics. The cache explanation makes timing a practical workflow concern. A process involving substantial human review needs an environment that accommodates those pauses without making every return unnecessarily expensive.
• 05:04 Reproducibility belongs in the acceptance criteria. Saving scripts and source data makes it possible to check how a report was produced. For technical work, a polished chart should come with enough evidence to reconstruct its underlying calculation.
• 07:49 Accumulated corrections are part of the project. Preferences learned during earlier conversations may never have reached the main instructions. A migration needs to identify those decisions and determine which ones still apply.
• 10:05 The project has several dependencies. Instructions, reference files, memories, and reusable skills all contribute to the outcome. A missing formatting example or supporting script can change the result even when the central prompt survives.
• 17:16 Setup completion needs an execution test. Creating the expected files shows that preparation finished. Running a familiar task reveals whether the migrated workflow still meets the original approval criteria.
• 21:44 The reported improvement remains an individual observation. The author compares two and a half sessions with less than 40% of one session. That supports investigating the workflow, while leaving questions about comparable settings and the contribution of caching unanswered.

How to apply

Claude Code prompt caching: interpret the multiplier

Keep cache lifetime, context capacity, and subscription usage limits separate. Cache expiration does not erase the conversation; it removes the opportunity to reuse that processing on the next request. The mechanism is described in Claude Code’s caching documentation.

As checked on October 27, 2026, the documented default is one hour for the main conversation on a Claude subscription within included usage. Usage credits, API keys, and cloud providers default to five minutes. A move into Claude Code therefore does not guarantee an hour under every billing setup. Cache lifetime rules.

For a concrete API example, the Sonnet 4.6 pricing table lists $6 per million tokens for one-hour cache writes and $0.30 for cache reads. That is a 20:1 relationship for that input component. New input, generated output, and tools contribute to task cost. These prices do not directly determine subscription capacity. Official API pricing.

The session comparison is another calculation: 2.5 divided by 0.4 is 6.25. Since the reported second figure is below 0.4, its nominal ratio would be higher. However, those session estimates are not a controlled measurement of task cost.

1. Pick a deliverable with a known answer

I would start with a completed monthly report, spreadsheet analysis, or technical proposal. Save its original input, approved output, and review criteria. Define the conventions that matter to the actual audience: date format, currency, decimal notation, and treatment of missing values.

For a workflow serving Brazilian clients, explicitly check day/month ordering, decimal commas, and BRL formatting. For a US audience, use the conventions required by that deliverable. Migration is a good opportunity to make these expectations explicit.

Write five acceptance checks before changing environments: correct totals, traceable references, expected formatting, preserved intermediate files, and no unsupported statements. This gives the new setup a target that can be checked independently of writing style.

2. Map each dependency to a location and a check

Here is a suggested starting structure. The folder names are organizational choices:

| Material | Suggested destination | Verification | | --- | --- | --- | | Recurring instructions | CLAUDE.md | Ask the agent to explain the workflow | | Templates and references | references/ | Reproduce a familiar table | | Previous decisions | decisions.md | Check an established correction | | Reusable procedures | .claude/skills/ | Run each required procedure | | Inputs and deliverables | runs/ | Identify files consumed and produced |

Use CLAUDE.md for persistent project instructions. I would keep essential rules and pointers there, with larger reference material elsewhere, following the guidance on concise instructions in the memory documentation.

For local project skills, the documented layout is .claude/skills/name/SKILL.md together with supporting files. Check what actually loads before treating the installation as complete. Skills documentation.

3. Make the migration produce evidence

This is an original starter prompt for this article, rather than the downloadable prompt mentioned in the video:

Inspect this folder and inventory its instructions, references, recorded decisions, and skills. Preserve the originals. Prepare a project structure that reproduces the documented workflow, identifying the source of each rule. Record missing dependencies and conflicting instructions. Finish by proposing an acceptance test using the supplied input and previously approved output.

Read the resulting instruction file yourself. A temporary preference from an old task may have become an inappropriate permanent rule. If you also use Codex, put its corresponding project guidance in AGENTS.md, which Codex recognizes. Official Codex instructions.

4. Run a comparison with consistent inputs

Execute the task in browser chat and in the migrated environment. Keep the model, files, objective, and acceptance criteria as consistent as the interfaces allow. Repeat the comparison on three representative jobs, separating initial setup effort from recurring execution cost.

Record reported usage, elapsed time, correction rounds, and minutes spent reviewing the output. With API billing, record actual charges as well. Where available, cache_creation_input_tokens and cache_read_input_tokens show cache writes and reads. Monitoring cache performance.

My preferred decision metric would be cost per approved deliverable. A run that consumes fewer credits but needs forty extra minutes of cleanup may be a poor trade. Add the value of review time to billed usage when estimating operating cost. For work purchased in another currency, retain both the provider’s charge and the amount actually paid locally.

5. Set a threshold for expanding the move

I would expand the migration after three consecutive deliverables pass the original checks and show lower usage or a clear time saving. If results vary substantially, investigate missing dependencies, changed instructions, or skipped review steps before moving more work.

Add browser automation and other integrations after establishing that baseline. You can then measure their contribution separately and decide which additions improve the workflow you actually use.