Claude Efficiency Playbook

This is the single biggest lever here. Every tool call the assistant makes (searching the web, opening a file, querying an app) is a separate step, and every step re-reads the entire conversation so far. Mixing a new, unrelated task into an old, long chat drags along everything that came before it, even though none of it is relevant anymore. The moment the task changes, start a fresh chat instead of continuing the old one. The same logic applies inside a single piece of work too: split it into a cheap, mechanical gathering step and a separate, more expensive reasoning step, and hand off between them with a short file or note instead of the whole back-and-forth that produced it.

Example

A light model pulls the key facts out of a meeting transcript into a short note (the gathering step). A separate chat, on a stronger model, reads only that short note to work out what it means for a decision (the reasoning step) — instead of one long chat that drags the whole transcript and the whole extraction conversation into the analysis.

Each message you send, especially one that triggers a tool call, is a separate step that re-reads everything so far. Five small requests sent one at a time cost more than the same five requests sent together, because the earlier ones all get re-read multiple extra times while waiting for the rest.

Example

Instead of asking “find document A,” then “now find document B,” then “now compare them,” ask once: “find documents A and B and compare them.”

The discount for re-reading cached context only holds for a short window, typically around five minutes. Go quiet longer than that mid-conversation, and the next step pays a much higher rate to reload everything, instead of the cheap cached rate.

Example

If you're dictating instructions with pauses, try to get the full thought out in one go rather than sending a sentence, thinking for a few minutes, then sending the next one.

Use Claude Haiku for reading and lookup — pulling a status from a tracker, or checking what a wiki note already says. It's fast and cheap, and the work is mechanical fetching, not judgment, so a bigger model buys nothing. Use Claude Sonnet for analysis — reading a transcript or a document and making sense of it; it's the right balance of depth and cost for most day-to-day writing and analysis. Use Claude Opus for producing comprehensive output — connecting facts spread across many notes into one coherent deliverable, where getting the judgment right matters more than the cost.

Example

Haiku: reading a ticket's status, or checking what's already written in a wiki note. Sonnet: turning a meeting transcript into a clean analysis. Opus: pulling together notes from several initiatives into one roadmap that connects the dots between them.

Separately from which model you pick, Claude lets you dial how much it “thinks” before answering. Use the low setting for routine, mechanical requests. Use medium for most everyday analysis and writing. Reach for the high setting only for genuinely ambiguous, multi-step judgment calls, where getting it wrong is costly. Claude Fable is built for running heavy multi-agent automations (Claude Code-style orchestration) — skip it for regular day-to-day work that doesn't actually involve that kind of orchestration, it costs more without adding anything on a normal task.

Example

Checking whether a note follows a fixed template: low. Turning a transcript into an analysis: medium. Deciding which of three competing project risks to escalate first: high. Running an automated multi-step pipeline across many systems: Fable, and only then.

Changing the model or the reasoning level partway through a conversation invalidates the cached version of everything said so far. The next step has to reload the whole history at the expensive rate instead of the cheap cached one. If the task genuinely needs a different model or effort level, that's actually a sign to start a new chat, not a setting to flip in the middle of an existing one.

Example

Started a chat on the fast tier for a quick lookup, and it turned into a real analysis? Take what you've learned, open a new chat on a stronger model, and continue there, rather than upgrading the same thread.

An MCP connection (to a calendar, a task tracker, a diagramming tool, a file store) adds its entire list of possible actions to what the assistant has to keep track of, and a short summary of it sits in the background even before anything is used. The moment one action is actually used, its full technical description loads in and stays for the rest of the chat. A project with a dozen MCPs connected pays for all of that even on a task that only touches one of them.

Example

If a project genuinely only uses three MCPs — say a task tracker, a diagramming tool, and a file store — keep exactly those three connected, and nothing else “just in case.”

A skill or connector that's installed but idle costs almost nothing by itself. But the moment it's actually called, its full instructions or technical menu — easily a few thousand tokens — load into the chat and sit there for the rest of it, whether or not you use it again. Keep only the ones flagged on that this specific piece of work actually needs, and switch the rest off.

Example

Working on a document review? Turn off the diagramming connector and any skill unrelated to documents for that session, instead of leaving everything on by default.

An LLM Wiki — a running, linked knowledge base built with the assistant's help — is worth setting up when an initiative runs for a couple of months or more, with recurring meetings and decisions worth finding again later. It's overkill for a one-off question that nothing else will ever reference; for those, just answer directly instead of filing them into a note with tags and links. The idea itself comes from Andrej Karpathy's LLM Wiki gist — worth reading in full if you want to set one up properly.

Example

A project running two to three quarters with weekly meetings is worth a wiki. A quick one-off calculation isn't — it doesn't need a dated, tagged note.

Turning a raw meeting transcript into a clean note is one job. Deciding what that note means for a plan or a decision is a different job. Do the first, close that chat, and open a new one that reads only the finished note, not the full transcript, to do the second.

Example

One chat files today's meeting into a note. A separate chat, opened later, reads that note to decide what changes because of it.

A project with files and folders attached long-term is worth it when there are templates, an ongoing knowledge base, or recurring deliverables you'll return to. For a single question or a short one-off analysis, a plain chat without a whole project attached is simpler and cheaper, because it doesn't drag a project's worth of files and structure into a question that didn't need any of it.

Example

An ongoing initiative with a shared set of templates and a running knowledge base deserves a persistent project. “What's the difference between these two accounting terms” doesn't.

A single project that has every app and every topic connected at once means every session inside it, even a narrowly scoped one, carries the weight of everything else that's connected. Splitting unrelated streams of work into their own projects keeps each one's baseline small.

Example

A project for legal contract review and a separate one for marketing analytics, instead of one project with both sets of connectors turned on all the time.