💸 10 Claude Code Habits That Quietly Burn Your Tokens (and How to Fix Them)

Claude Code does not usually become expensive because you asked too many questions. It becomes expensive because every new question drags an oversized context, the wrong model, unnecessary tools, and yesterday's failed attempts back through the loop. Here are the ten habits I would fix first.

---

I Thought My Prompts Were the Problem

When my Claude Code usage started climbing, I blamed the obvious thing: I must be prompting too much.

So I tried shorter prompts. I stopped saying please. I removed examples. I compressed detailed requests into vague one-liners that looked wonderfully efficient and produced wonderfully inefficient results.

Claude searched more files because I had not named the right ones. It guessed at requirements I had not stated. It implemented the wrong shape, I corrected it, it tried again, and the session accumulated both failed approaches. I had saved 40 tokens in the prompt and spent thousands repairing the ambiguity.

That was the first lesson: a short prompt is not the same thing as a cheap task.

The second lesson came from Anthropic's own Claude Code cost guidance. A long-running session sends its conversation context again on every request. Tool use can create several requests inside what feels like one turn. Prompt caching makes repeated context cheaper, but it does not make a bloated session free. A one-line follow-up late in the day can still carry the weight of everything Claude read, ran, and discussed before it.

This matters whether you pay by API token or use a Pro, Max, Team, or Enterprise subscription. API users see a direct bill. Subscribers consume an allowance rather than paying the session's displayed list-price estimate, but the engineering problem is the same: wasteful context reaches limits faster and leaves less capacity for useful work.

Anthropic says Claude Code averages roughly $13 per developer per active day across enterprise deployments, with 90% of users below $30 per active day. That is not a promise about your bill; repository size, model choice, automation, and working style vary enormously. It is evidence that cost is an operational variable worth engineering, not an invisible side effect.

After tracing the places where usage actually goes, I found ten habits that matter far more than shaving words from prompts.

---

TL;DR

1. Do not use one session as a permanent workspace. Run /clear between unrelated tasks.
2. Do not run the most capable model at maximum effort by default. Start with Sonnet at medium or high effort; promote only the hard judgment calls.
3. Do not turn CLAUDE.md into an encyclopedia. Keep universal instructions concise and move specialized workflows into Skills or path-scoped rules.
4. Do not confuse vague prompts with efficient prompts. Scope the outcome, files, constraints, and verification target.
5. Do not pour raw logs and test output into the main context. Filter them or isolate verbose work in a subagent.
6. Do not load every integration just because you installed it. Keep MCP Tool Search enabled, disable unused servers, and prefer a CLI when it does the job.
7. Do not spawn agents as decoration. Every independent agent has its own context and cost.
8. Do not accidentally destroy your prompt-cache advantage. Avoid unnecessary model switching, cache-disabling flags, and resuming giant stale sessions.
9. Do not pay a model to repeat deterministic work. Put stable transformations and mandatory checks in scripts, hooks, and code-intelligence tools.
10. Do not wait until the end to discover Claude went the wrong way. Interrupt early and give it an executable definition of done.

The principle underneath all ten is simple:

Tokens should buy decisions, not repetition.

---

First, Understand What You Are Actually Paying For

Claude Code is not a chatbot that receives only your latest sentence. A request can include:

• the system instructions and tool definitions;
• CLAUDE.md files and memory loaded for the project;
• your conversation history;
• files Claude has read;
• command and tool results;
• images or documents you attached;
• the latest prompt;
• generated reasoning and output; and
• additional requests made as Claude calls tools and continues its loop.

A useful simplified model is:

$$
\text{Task cost} \approx \sum_{i=1}^{n}
(I_iR_i + W_iR_w + C_iR_c + O_iR_o)
$$

where $I_i$ is uncached input, $W_i$ is cache creation, $C_i$ is cache reads, $O_i$ is output (including billed thinking), and each $R$ is the relevant rate for your model and provider.

You do not need to calculate this manually. The important part is the summation. A session does not pay for context once. It processes context across a sequence of requests. Prompt caching can dramatically reduce the price of repeated prefixes, but a large cached prefix still consumes usage at the cached rate, and a cache miss can force that prefix to be processed again at the uncached rate.

Before changing anything, inspect reality:

/usage
/context
/insights

/usage shows session token totals and model attribution. On subscription plans it can also attribute recent usage to Skills, subagents, plugins, and individual MCP servers, and flag behaviors such as long context or cache misses when they account for at least 10% of recent usage. Use d and w to switch between the last day and week.

/context shows what is occupying the current context window: memory files, tools, and conversation content. /insights analyzes your local session history and writes an HTML report about patterns and friction, not merely token totals.

Measure first. Otherwise, cost optimization becomes another form of prompt superstition.

---

1. You Keep One Session Alive for Everything

This is the biggest leak because it makes every other leak recur.

You open Claude Code to fix authentication. Then you ask about a deployment error. Then you review a pull request. Then you return to authentication. The session feels convenient because Claude “knows the project.” In reality, the context now contains several tasks, command outputs, abandoned hypotheses, and files that no longer matter.

Anthropic calls this the kitchen sink session. The longer it lives, the more irrelevant history rides along with each request. Model performance can also degrade as useful constraints compete with stale material.

The fix

Treat a session like a branch: one coherent workstream, not one repository forever.

/rename oauth-refresh-fix

# Work on the task, then before switching topics:
/clear

Naming the session lets you find it later with /resume. Clearing starts a fresh context and resets the session totals shown by /usage.

Use the right reset for the situation:

Situation	Best action
New, unrelated task	/clear
Same long task, history is becoming noisy	/compact Focus on decisions, modified files, and failing tests
One side question that should not enter history	/btw your question
Need to remove a bad branch of conversation	/rewind or double-tap Esc
Returning to a named workstream	/resume

There is a subtle cost detail here: /compact has to read the conversation it summarizes, so compacting a huge session is itself a large request. When continuity does not matter, /clear is both cleaner and cheaper.

My rule is blunt: if the next task would deserve a different git branch, it deserves a different Claude context.

---

2. You Run the Biggest Model at the Highest Effort for Every Task

Using the strongest model feels safe. If Opus or Fable is more capable, why not leave it on all day?

Because capability and effort are two separate cost multipliers, and most coding steps do not need both maxed out.

The current Claude Code model aliases make the intended roles explicit:

• haiku: fast and efficient for simple work;
• sonnet: the daily coding model;
• opus: complex reasoning;
• fable: the hardest and longest-running tasks;
• opusplan: Opus for planning, then Sonnet for execution.

Effort controls how much adaptive reasoning the model applies. Lower effort is cheaper and faster for straightforward work. Higher levels spend more tokens pursuing and checking possibilities. Anthropic warns that max can show diminishing returns and overthinking, so it should be tested rather than adopted as a universal default.

The fix

Start at the lowest model and effort level that reliably closes the task, then promote based on evidence.

/model sonnet
/effort medium

For a difficult architectural change:

/model opusplan
/effort high

For one unusually hard reasoning step, use the expensive model there, not for the surrounding mechanical work.

Work	Sensible starting point
Rename, formatting, targeted test, simple lookup	Haiku or Sonnet; low/medium effort
Normal feature implementation and debugging	Sonnet; medium/high effort
Architecture, ambiguous root cause, adversarial review	Opus; high effort
Very long, unusually difficult autonomous task	Fable; task-specific effort
Hard plan followed by routine implementation	opusplan

There is one important exception. A cheaper model grinding through repeated failed attempts can cost more than a stronger model solving the hard node quickly. The optimization target is cost per completed task, not price per token.

Ask one diagnostic question when Claude struggles:

Did it fail because it lacked capability, or because it lacked context, effort, or a verifier?

Only the first failure automatically justifies a bigger model.

Also remember that switching models mid-session is not free. Claude Code warns because the next response re-reads the conversation without the old model's cached context. Use model routing deliberately, especially late in a large session.

---

3. Your CLAUDE.md Has Become a Company Wiki

CLAUDE.md is powerful precisely because it loads automatically. That is also why it can become expensive.

Every universal coding rule, historical explanation, API tutorial, directory listing, and “nice to know” note occupies context at the start of every session. The file is then carried into work that may never need most of it.

The failure is not only token usage. Anthropic's documentation says bloated CLAUDE.md files can make Claude ignore the instructions you actually care about. More rules can produce less adherence.

The fix

Target under 200 lines per CLAUDE.md and keep only facts that must shape nearly every task:

• commands Claude cannot reliably infer;
• project-specific conventions;
• required verification steps;
• non-obvious architectural constraints;
• repository etiquette; and
• recurring gotchas.

Move everything else to the mechanism that matches its scope:

Information	Put it here
Universal project rule	CLAUDE.md
Rule for src/api/**/*.ts only	.claude/rules/ with paths frontmatter
Database migration workflow	On-demand Skill
Personal machine detail	CLAUDE.local.md
Deterministic “must always happen” check	Hook, not prose
Long reference documentation	Link or fetch on demand

Run these periodically:

/context
/doctor

/context confirms which memory files loaded. Current Claude Code versions can use /doctor to propose trims for checked-in CLAUDE.md files by removing details Claude can derive from the repository.

One trap: splitting a long CLAUDE.md into imported files with @path may improve organization, but imported content still loads at launch. It does not reduce context. Skills and path-scoped rules do because they load only when relevant.

For every line in CLAUDE.md, ask:

Would removing this cause Claude to make a recurring, expensive mistake?

If the answer is no, remove it or move it closer to the work that needs it.

---

4. You Write Vague Prompts Because They Look Short

“Improve this codebase” is a tiny prompt with an enormous search radius.

Claude has to discover what “improve” means, inspect broad parts of the repository, choose its own priorities, and guess what you will accept. That exploration fills context. If its guess differs from yours, the correction starts after the expensive part has already happened.

A specific prompt may contain more input tokens but reduce total task tokens by eliminating search and rework.

The fix

Give Claude four things:

1. Anchor: the file, symbol, error, issue, or behavior to start from.
2. Outcome: what must change for the user or system.
3. Constraints: what must not change and which pattern to follow.
4. Verification: the test, command, screenshot, or expected output that proves completion.

Instead of:

Fix the login bug.

Use:

Users are redirected back to login after an access token expires.
Start in src/auth/tokenRefresh.ts and follow the existing session pattern.
Write a failing test for refresh-token rotation, make the smallest fix,
and run the focused auth test suite. Do not change the public session API.

That prompt is longer. The task is cheaper.

The same applies to planning. Plan mode prevents costly rework on ambiguous, multi-file changes, but planning itself adds overhead. Anthropic's guidance is refreshingly practical: if you can describe the diff in one sentence, skip the plan. Use exploration and planning when the approach is uncertain, the change crosses boundaries, or the code is unfamiliar.

Efficiency is not minimal wording. It is minimal uncertainty.

---

5. You Dump Raw Logs, Test Suites, and Documentation into the Main Context

Verbose tool output is one of the fastest ways to turn a clean session into a landfill.

A 10,000-line log may contain twenty useful lines. A full test suite may produce pages of successful output when Claude only needs three failures. A documentation crawl may read ten pages before finding one relevant constraint. If all of that enters the main conversation, it remains available to be carried through later requests.

The fix

Filter before the model sees the data.

# PowerShell: keep errors and a small amount of surrounding context
Get-Content .\app.log |
    Select-String -Pattern 'ERROR|FATAL|Exception' -Context 2,5 |
    Select-Object -First 100

Prefer focused checks:

Run only the failing auth test file. Report the failed test names,
the first relevant stack trace, and the likely shared root cause.
Do not return passing-test output.

For high-volume operations, isolate the noise in a subagent:

Use a subagent to run the full test suite. Keep the raw output in that
context and return only failing tests, relevant errors, and the command used.

Anthropic explicitly recommends subagents for test runs, documentation fetches, and log processing because only the summary returns to the main conversation.

For recurring cases, make the filtering deterministic with a hook or script. A hook that extracts failures from test output spends ordinary compute to save model context on every run. That is a good trade.

There is a broader lesson here: the model should receive information, not exhaust.

---

6. You Load Every MCP Server and Tool You Have Ever Installed

MCP makes Claude Code dramatically more useful, but an integration is not free merely because you did not call it.

Claude needs enough information to know tools exist and when to use them. Modern Claude Code reduces this overhead through MCP Tool Search: tool schemas are deferred by default, only tool names and server instructions load initially, and full definitions enter context when Claude discovers and uses a relevant tool.

That optimization can be defeated by configuration or habit.

The fix

First, keep Tool Search enabled. Do not set this unless you deliberately want every schema loaded upfront:

ENABLE_TOOL_SEARCH=false

If you use a custom gateway, verify that it supports the tool_reference blocks required by Tool Search before forcing the feature on.

Second, inspect and disable integrations you do not need for the current project:

/mcp
/context

The /mcp panel can toggle a server off without deleting its configuration. /context shows whether tools are taking meaningful space.

Third, avoid setting alwaysLoad: true on an MCP server unless its tools genuinely need to be visible on every turn. That option deliberately bypasses deferral.

Fourth, prefer a focused CLI when one exists. Anthropic's cost guide calls tools such as gh, aws, gcloud, and sentry-cli more context-efficient than equivalent MCP integrations because they do not add per-tool listings. A command can also return exactly the fields Claude needs.

Finally, control tool output. Claude Code warns when an MCP result exceeds 10,000 tokens and defaults to a 25,000-token maximum for tools without their own declared result-size limit. Treat that warning as a design signal. Paginate, filter, or change the server to return a compact result instead of raising the ceiling by reflex.

Install widely. Load narrowly.

---

7. You Spawn Subagents and Agent Teams for Work One Session Could Do

“Use five agents” sounds advanced. Sometimes it is. Sometimes it is five separate context windows solving one small problem.

Every non-fork subagent starts fresh. It needs a system prompt, task message, tools, and often CLAUDE.md context before it does useful work. Agent teammates each maintain their own context and continue consuming tokens until they exit. Anthropic estimates agent teams can use approximately 7x more tokens than standard sessions when teammates run in plan mode.

Parallelism reduces wall-clock time. It does not automatically reduce token usage.

The fix

Use a subagent when isolation creates concrete value:

• verbose output should stay out of the main context;
• an investigation is independent and can return a concise summary;
• a fresh reviewer should challenge the implementation;
• the task needs restricted tools or permissions; or
• a cheaper model can handle a self-contained operation.

Stay in the main conversation when:

• the edit is small and targeted;
• phases share a lot of context;
• you need frequent clarification; or
• the subagent would have to rediscover everything the main session already knows.

Route the model explicitly for repeatable workers:

---
name: log-triage
description: Finds root errors in verbose application logs
tools: Read, Grep
model: haiku
effort: low
maxTurns: 6
---

One current-version detail is easy to miss: the built-in Explore agent now inherits the main conversation's model rather than always using Haiku. If your main session runs an expensive model and exploration does not need it, define a focused custom explorer with model: haiku or launch the main work on Sonnet.

For teams, keep the roster small, make spawn prompts self-contained, prefer Sonnet for ordinary teammates, and shut agents down when their work is complete.

The right question is not “Can I parallelize this?” It is:

Will independent context improve quality or protect the main context enough to justify its startup and coordination cost?

---

8. You Keep Breaking the Prompt Cache

Prompt caching is one of Claude Code's most important invisible optimizations. Repeated prefixes such as system instructions, tool definitions, and conversation history can be read at a lower cached rate instead of processed as new input every time.

But caching has boundaries.

According to Claude Code's current cost documentation:

• subscription sessions normally have a one-hour cache lifetime;
• when subscription usage moves to usage credits, the lifetime drops to five minutes unless ENABLE_PROMPT_CACHING_1H=1 is set;
• API-key and cloud-provider sessions default to five minutes; and
• the first message after a longer break may miss the cache and reprocess a large context.

Claude Code also warns when you switch models in an active conversation because the next response re-reads the full history without the previous model's cached context.

The fix

Do not disable caching unless you are diagnosing a specific compatibility problem. Check your environment for these flags:

DISABLE_PROMPT_CACHING
DISABLE_PROMPT_CACHING_HAIKU
DISABLE_PROMPT_CACHING_SONNET
DISABLE_PROMPT_CACHING_OPUS
DISABLE_PROMPT_CACHING_FABLE

Batch coherent work while the context is hot. Avoid bouncing between models in a huge session. After a long break, ask whether you need the complete transcript or whether a summary or clean session would be better.

On Pro and Max plans, Claude Code can offer to resume a large stale session from a summary, which prevents later requests from carrying the full history. Use it when exact conversational detail no longer matters.

Most importantly, do not confuse “cached” with “free.” The cache makes stable context cheaper. It does not justify keeping irrelevant context forever.

The best cache strategy is still a well-scoped session with a stable prefix.

---

9. You Pay Claude to Repeat Work a Script Could Guarantee

Models are excellent at judgment under uncertainty. They are an expensive substitute for deterministic plumbing.

If Claude repeatedly reads the same giant log, rediscovers the same build command, reformats the same output, checks the same forbidden path, or reasons through the same release checklist, you are spending tokens to recreate a procedure your repository could encode once.

The fix

Promote stable behavior out of the conversation:

• use a script for deterministic transforms;
• use a hook for checks that must run every time;
• use a Skill for a reusable workflow that needs model judgment;
• use CLAUDE.md for concise universal guidance; and
• use a code-intelligence plugin for symbol navigation and automatic diagnostics.

For example, do not repeatedly tell Claude to read a monorepo with grep until it finds a definition. A language-server-backed code-intelligence plugin can jump to the precise symbol and surface type errors after edits. One structured lookup can replace several searches and candidate-file reads.

Do not repeatedly ask, “Remember to run the linter after edits.” Instructions are advisory. A PostToolUse hook can run it automatically. Likewise, a PreToolUse hook can filter a 10,000-line command result before it enters the model's context.

The dividing line is useful:

Need	Best mechanism
Decide what to do	Model
Perform an exact repeatable transformation	Script
Enforce a non-negotiable check	Hook
Reuse a judgment-heavy workflow	Skill
Navigate typed code precisely	Code-intelligence plugin

Every recurring instruction is a candidate for compilation into the harness.

---

10. You Correct Too Late and Verify Too Little

The most painful token waste is work that should never have continued.

Claude chooses the wrong abstraction, starts editing the wrong package, or misunderstands the user flow. You wait because perhaps it will recover. Ten tool calls later, you explain the problem. Claude now has to understand your correction while carrying the failed approach, its output, and the files it opened along the way.

Then the task reaches the end without an executable check. Claude says it is done, you find a failure, and a second repair loop begins.

The fix

Interrupt quickly:

• press Esc to stop the current action while preserving context;
• use /rewind to restore conversation, code, or both;
• if you have corrected the same issue twice, use /clear and restart with a better prompt; and
• test incrementally so failures are discovered near the edit that caused them.

Anthropic's best-practices guide says a clean session with a more precise prompt “almost always” beats a long session polluted by repeated corrections.

Then give Claude an executable definition of done:

Implement the refresh-token fix. Run the focused auth tests and typecheck.
Do not stop until both commands exit successfully. Report the commands and
their final results, not an assertion that the change should work.

Verification saves tokens because it shortens the distance between mistake and evidence. A focused test, build exit code, linter, output fixture, or browser screenshot closes the loop without waiting for you to discover the miss later.

For unattended work, raise the strength of the gate:

• use /goal to keep the task open until a condition is met;
• use a Stop hook for a deterministic check;
• use a fresh subagent for adversarial review; or
• use a workflow when multiple independent checks are genuinely necessary.

The verifier is not extra ceremony. It is the mechanism that stops expensive rework from escaping the current loop.

---

My Low-Waste Claude Code Operating System

If you want the whole article compressed into one working routine, use this.

At the start of a task

1. Start a fresh or correctly named session.
2. Use Sonnet unless the task has already demonstrated it needs more capability.
3. Set medium effort for scoped work and high effort for genuinely complex work.
4. Give Claude an anchor, outcome, constraints, and verification target.
5. Use plan mode only when uncertainty or blast radius justifies it.

During the task

1. Watch the direction, not every keystroke.
2. Press Esc as soon as the approach is clearly wrong.
3. Run focused checks after small groups of edits.
4. Send verbose logs, docs, and broad searches to a filtered command or subagent.
5. Use /btw for disposable side questions.

Between tasks

1. Run /usage and /context when usage feels surprising.
2. Name useful sessions before clearing them.
3. Use /clear for unrelated work; do not drag yesterday's context into today's task.
4. Turn recurring discoveries into concise memory, a Skill, a script, or a hook.
5. Prune CLAUDE.md and disable integrations that do not earn their permanent context.

The default posture is not “spend as little as possible.” It is spend deeply where judgment matters and almost nothing where repetition does not.

---

A 10-Minute Token Audit

Do this before buying a larger plan or blaming the model.

1. Run /usage
2. Switch to the 7-day view with w
3. Note long-context, cache-miss, MCP, Skill, plugin, and subagent attribution
4. Run /context
5. Inspect loaded memory and tools
6. Run /mcp and disable unused servers for this project
7. Open CLAUDE.md and remove anything derivable or task-specific
8. Check /model and /effort for an expensive default
9. Identify one recurring verbose command to filter or delegate
10. Run /insights and compare its friction report with your assumptions

Do not change all ten variables at once. Pick the largest source, change one habit for a week, and compare. Cost optimization without a baseline is just vibes with a calculator.

---

The Three Mistakes I Would Fix First

If you only remember three things, make them these:

1. Clear between unrelated tasks

This removes stale context from every future request in the new workstream. It is the highest-leverage habit because the saving compounds across turns.

2. Match model and effort to the node, not the importance of the project

An important project still contains mundane edits. Spend Opus or Fable on architecture, ambiguity, and hard verification—not on every file read and formatting change.

3. Filter before context

Do not make Claude find twenty useful lines inside 10,000 lines if a command, hook, or subagent can return the twenty directly.

These three changes address the repeated context, the per-token rate, and the volume entering the context. Together, they attack the whole cost equation.

---

FAQ

Does a shorter prompt always use fewer tokens?

It uses fewer prompt tokens in that one message. It may use far more task tokens if ambiguity causes broad exploration, incorrect implementation, and repair. Optimize for the shortest path to a verified result, not the shortest sentence.

Does /clear delete my code changes?

No. It resets conversation context, not your working tree. Name the session first with /rename if you want to resume its conversation later.

Should I use /compact instead of /clear?

Use /compact when one coherent task must continue and old detail can be summarized. Use /clear when changing tasks. Compaction itself reads the conversation, while clearing starts fresh at no context-summarization cost.

Is prompt caching automatic?

Yes, Claude Code uses it automatically. Environment variables can disable it globally or by model family. Cache lifetime varies by authentication and billing path, so a large session resumed after a break can still cause a cache miss.

Are MCP servers still expensive now that Tool Search exists?

They are much more context-efficient because full tool schemas are deferred by default. There is still startup metadata, tool-search overhead, and potentially large tool output. Disable unused servers, avoid unnecessary alwaysLoad, and use compact tool responses.

Are subagents cheaper because they keep the main context clean?

Not automatically. They can reduce repeated pollution in the main context, but each non-fork subagent starts its own context and consumes tokens. Use them when isolation, specialization, or cheaper model routing creates more value than the startup cost.

Does switching from Opus to Sonnet restore my subscription limit?

Not generally. Subscription windows are shared across usage, although model-specific limits can behave differently. Model choice still matters for API billing, usage credits, and how quickly work consumes available capacity. Think of routing as efficiency, not a loophole.

What is the best default setup?

There is no universal one, but Sonnet with medium or high effort is a sensible baseline for normal coding. Keep CLAUDE.md concise, Tool Search enabled, sessions task-scoped, and verification explicit. Promote model or effort only when the task provides evidence that the baseline is insufficient.

---

Final Take: Stop Optimizing Prompts. Start Optimizing the Loop.

The token problem is rarely that you said too much once.

It is that Claude Code keeps carrying too much, at too high a price, through too many turns.

A stale session repeats irrelevant history. An oversized CLAUDE.md repeats instructions that do not apply. A vague request buys exploration you did not need. An unfiltered log buys attention for noise. An unnecessary agent creates another context. A missing verifier buys a second implementation loop.

None of those are solved by removing “please” from your prompt.

The best Claude Code users I know are not stingy with context. They are deliberate with it. They provide rich detail when it removes uncertainty, then aggressively prevent irrelevant detail from becoming permanent. They use capable models for hard judgment and cheaper models for routine execution. They let scripts handle certainty and models handle ambiguity. They verify early enough that wrong work dies young.

That is the mental shift:

Do not count prompts. Count repeated context, unnecessary reasoning, and avoidable loops.

Tokens should buy a better decision, a hard diagnosis, or a verified result. If they are buying the same stale history for the twentieth time, the model is not the thing that needs optimizing.

Your workflow is.

---

Sources and Further Reading

• Anthropic: Manage Claude Code costs effectively
• Anthropic: Claude Code best practices
• Anthropic: Model configuration, effort, and context
• Anthropic: How Claude remembers your project
• Anthropic: Connect Claude Code to tools via MCP
• Anthropic: Create and use Claude Code subagents
• Anthropic: How Claude Code uses prompt caching
• Anthropic: Monitor Claude Code usage with OpenTelemetry

---

About the Author

I am Suraj Khaitan, an AI and cloud engineer focused on production agents, Claude Code, MCP, RAG, and serverless architecture. I write practical deep dives for engineers who want to move past demos and build AI systems that are reliable, observable, secure, and economically sane.