The Claude Camp Toolkit

// 01

The Claude Stack, End to End

Current as of August 2026.

Most people are using one Claude. There are five surfaces, and picking the wrong one is the single most expensive mistake you can make with this tool. You can lose an afternoon in Claude Code doing something that was thirty seconds of work in a chat, or grind a chat thread for a week on something a scheduled task should have been doing without you.

This is the whole map, what each part is actually for, and how to tell which one you want.

The map

                        ┌──────────────────────────────┐
                        │   YOUR ACCOUNT (claude.ai)   │
                        │  connectors · account skills │
                        └──────────────┬───────────────┘
                                       │  available everywhere below
      ┌────────────────┬───────────────┼───────────────┬────────────────┐
      │                │               │               │                │
 ┌────▼─────┐   ┌──────▼─────┐   ┌─────▼──────┐  ┌─────▼──────┐  ┌──────▼───────┐
 │ claude.ai│   │   Cowork   │   │   Design   │  │ Claude Code│  │  Developer   │
 │          │   │            │   │            │  │            │  │  Platform    │
 │  think   │   │  operate   │   │  make      │  │  build     │  │  embed       │
 └────┬─────┘   └──────┬─────┘   └─────┬──────┘  └─────┬──────┘  └──────┬───────┘
      │                │               │               │                │
   projects      your local files   design system   a folder / repo   your product
   artifacts     scheduled work     assets, mocks   CLAUDE.md         API, agents
   memory        briefs, actions    publish to code .claude/          your users

The one-line rule: the further right you go, the more setup you pay and the more the work persists without you.

1. claude.ai: think it through

The chat surface. Deep research, a document you need read, a decision you need modelled, an artifact you can share.

What lives here

• Projects - instructions, knowledge files, memory, and the chat history for one body of work
• Artifacts - a thing rendered in the side panel with its own identity. Shareable by link
• AI-powered artifacts - an artifact that can call Claude itself. Since October 2025 these also get MCP access and persistent storage. Viewers sign in, and usage bills to the viewer, not you, so it is free at any scale
• Inline visualizations - rendered in the thread. No object to link, so not shareable. Ask for an artifact if you want to send it to someone

Reach for it when the output is an answer, a decision, or a document. If nothing needs to change on disk, you are probably in the right place.

2. Cowork: operate

Where work happens while you are not watching. Scheduled tasks, a daily brief, triage, actions across your connected tools.

What lives here

• A Cowork session can point at a local folder or scope directly to one of your chat projects (the composer's Project-or-folder dropdown lists them)
• Scheduled tasks run in the cloud on a cadence you set
• Live Artifacts - a dashboard that re-renders against fresh data

The thing nobody tells you: Cowork projects live on your machine with no cloud sync. That is exactly why Cowork is not on mobile - there is nothing on a server for a phone to open. What you get on the phone is Dispatch, which drives your awake desktop from one synced thread.

Reach for it when the deliverable is a brief, a draft, a triaged inbox, or an action across tools, and you want it to happen on a schedule rather than because you remembered.

3. Claude Design: make

A design system first, then everything generated from it: assets, mocks, slides, prototypes, marketing pieces.

Two on-ramps

• Create here - a company blurb, optionally seeded from a repo, a local frontend folder, a Figma file, or reference assets
• Create using Claude Code - highest fidelity, needs real React components to read

Reach for it when you need something to look like it came from one company rather than five different afternoons.

⚠️ Generating a design system takes several minutes. Start it before you need it.

4. Claude Code: build

An agent that works in a folder. Reads, writes, runs commands, and iterates against what it observes.

No setup required. Claude Code runs inside the Claude app pointed at a local folder. No terminal, no IDE, no git, no GitHub. Those are preferences, not prerequisites. This is the single most common reason people bounce off it, and it has not been true for a while.

Three surfaces, and they differ

Verify a command on the surface you will actually be using. The docs describe the CLI.

Reach for it when files need to change in a real project, or when you want a reusable layer (skills, commands, config) that persists across sessions.

5. Developer Platform: embed

Claude inside your own product, for your own users.

• Messages API - one call, one response. Vision, tools, structured output. An AI feature is usually smaller than people expect
• Agent SDK - you host the loop
• Managed Agents - Anthropic hosts the loop, the sandbox, and the tools. "The Agent SDK without the servers." Sessions fire from an API call or a schedule. Memory stores persist across sessions; dreaming re-curates them

The discriminator: you schedule it against your repo → Routine. Your users trigger it inside your product → Agent SDK or Managed Agent.

Which surface? The honest decision

They are not mutually exclusive, and Claude Code can technically do what the others do. The question is what you are paying in setup versus what you need to persist.

Do files need to change in a real project?
   yes ─────────────────────────────► Claude Code
   no
   │
   Does it need to happen without you there?
   │  yes ──────────────────────────► Cowork (or a Routine, if the output is a PR)
   │  no
   │
   Is the output a visual or a brand artifact?
   │  yes ──────────────────────────► Claude Design
   │  no
   │
   Is it going inside a product for other people?
   │  yes ──────────────────────────► Developer Platform
   │  no  ──────────────────────────► claude.ai

Where does X live?

The question that costs people the most time.

The rule that makes this stick: anything in ~/.claude/ is machine-local and does not travel. Anything committed to the folder travels with the project.

Skills are per-surface. Connectors are account-wide.

This surprises everyone once.

So downloading an account skill into .claude/skills/ is the right move if you want it locally. Connectors, by contrast, follow your account everywhere - connect once, available across surfaces.

What to actually do first

1. Open claude.ai and turn on the capability toggles. Several of the best features are off by default
2. Connect every tool in the directory you genuinely use. Not two or three
3. Set read-only tools to always-allow and leave writes on ask. That one setting is the difference between useful and nerve-wracking
4. Make one project that holds your real working context, and put actual documents in it
5. Only then open Claude Code, pointed at something real

Verify before you rely on it. Claude ships constantly and this document is a snapshot. Anything here that would cost you real time if wrong is worth thirty seconds of checking on your own machine, on the surface you are using. That habit is worth more than any file in this toolkit.

// 02

CLAUDE.md: The Contract

Current as of August 2026.

One file in your repo root, loaded in full at the start of every session. It is the difference between a teammate who knows your stack and one who improvises confidently in the wrong direction.

The thing almost everyone gets wrong

The instinct is to describe the project: the stack, the folder structure, the dependencies. Claude already infers nearly all of that by reading the repo. Everything you write that Claude could have worked out is rent you pay on every turn, forever.

A good CLAUDE.md says what the code does not say.

The test for every line: would Claude get this wrong without me? If no, cut it.

That is also why /init is a trap. It scaffolds a file by describing your codebase, which is the redundant half. Useful as a starting skeleton; a bad final artifact.

How to actually write one

Do not write it first. Write it from failures you watched.

1. Give Claude a real task in your repo. Something small that genuinely ships
2. Watch where it guesses wrong, asks you something the code should have told it, or does the thing you have to undo
3. Those are your lines. Nothing else is
4. When you have it, cut it again

A prompt that does this well:

Look back over what we just did. Write me a CLAUDE.md for this repo, but only include things you got wrong, had to ask me about, or guessed at. Be specific enough that I could check each line against the codebase. Leave out anything you could have worked out by reading the files.

Then cut whatever survived that you do not actually care about. It will name more than you have time for.

Scopes, and how they combine

Four levels, concatenated broadest-first, not overridden:

It also walks up the tree, so a file in a parent directory still applies. That is how a monorepo gets shared conventions plus per-package specifics without repetition.

The rule underneath all of it: anything in ~/.claude/ is machine-local. Anything committed travels.

Imports

@path/to/file expands and loads at launch, in full.

• Relative, absolute, or ~/ paths
• Maximum 4 hops of nesting
• Ignored inside code fences, so backtick a path you are only mentioning
• A project-root CLAUDE.md survives /compact and gets re-injected

Import for things that must always be true. For everything else, use docs/ and let Claude read on demand, or use path-scoped rules.

.claude/rules/: the conditional half

Topic files that load at the same priority as CLAUDE.md, with one crucial addition: a paths: glob in frontmatter makes them load only when Claude touches matching files.

---
paths: ["src/db/**", "migrations/**"]
---
 
# Database conventions
 
- Every query goes through the service layer. Never call the client directly from a route
- Migrations are append-only. Never edit one that has run
- Prefer a new nullable column over altering an existing one

This is the highest-leverage change most people can make. Your window stops carrying database rules while you are editing CSS.

Rule of thumb: always true → CLAUDE.md. True in one area → a path-scoped rule. Might be needed → docs/.

The shape

Keep it under 200 lines. Sections that consistently earn their place:

# Project: <name>
 
## What this is
One or two sentences. What it does and who uses it.
Only if it is not obvious from the README.
 
## Tech stack
Only the parts that are surprising or that constrain decisions.
Skip anything visible in package.json.
 
## Conventions
The ones you would correct in code review.
"Server components by default." "Every query goes through the service layer."
 
## Always do
Specific, checkable, earned from a real mistake.
 
## Never do
The highest-value section. Every line should come from something
that actually went wrong once.
 
## Gotchas
The load-bearing weirdness. The thing that looks like a bug and is not.
The script you must run after changing X.

"Never do" is where the value concentrates. It is the section Claude cannot derive, and the one that saves you the most rework.

A worked example

Generic, and near-worthless:

## Tech Stack
- Next.js 15 with App Router
- TypeScript
- Tailwind CSS
- PostgreSQL with Drizzle

Claude reads package.json. It knows.

Earned, and worth its place:

## Never do
- Do not add a dependency without asking. This app is deployed to a
  size-constrained environment and every package is a decision
- Do not touch `migrations/`. They run against production on deploy
- Do not use `useEffect` for data fetching. Server components or the
  query layer, nothing else
- Do not write to `generated/`. It is rebuilt by `pnpm codegen` and your
  edits will vanish silently
 
## Gotchas
- `pnpm dev` needs `.env.local`. Copy `.env.example` first or the errors
  are misleading
- The seed script is not idempotent. Reset the database before rerunning

Every one of those is a mistake that happened once. That is the whole method.

Starting points by stack

Take the shape above and fill it from your failures. These are the lines that tend to be genuinely non-obvious per stack, as prompts rather than answers:

Web app - rendering boundaries (what is server, what is client), where data access is allowed to live, which UI primitives are canonical versus legacy.

API service - the error envelope, auth handling, which layer owns validation, what is safe to log.

Data pipeline - idempotency guarantees, what is safe to rerun, where schema lives, which steps touch production.

Monorepo - what may import what, which package owns shared types, what must be rebuilt after a change.

Mobile - which surfaces are shared with web, native module constraints, what breaks the build in CI but not locally.

Keeping it honest

• Revisit after any session where Claude got something wrong twice
• Delete lines that no longer bite. A stale rule is worse than no rule
• If it passes 200 lines, the excess is almost always describing rather than constraining
• Ask Claude to audit it: "Read this CLAUDE.md against the actual codebase. What is redundant, what is stale, what is missing that you had to guess at?"

// 03

Context and Memory

Current as of August 2026.

Two things called memory, owned by different people, stored in different places, with opposite rules. Confusing them costs weeks.

First: how Claude Code actually finds things

It greps and reads files, the way you would. There is no vector database, no embedding step, no semantic index.

That matters more than any prompt technique:

• A clear folder structure genuinely makes Claude smarter
• Naming files what they are beats any retrieval trick
• If you cannot find something in your repo in ten seconds, neither can Claude

RAG is for large external knowledge bases. Your codebase is not one, and treating it like one is a common expensive detour.

The context window

Everything Claude knows in a turn: your message, the conversation, CLAUDE.md, imported files, whatever it has read, tool results.

Run /context. It shows what is loaded right now. Most people discover something enormous is always loading that they never think about.

The mental model: anything auto-loaded is rent you pay on every single turn. It is worth paying for what is always relevant, and it is a bad deal for anything conditional.

The highest-leverage move in this document: take the conditional half of your CLAUDE.md and move it into .claude/rules/ with a paths: glob. Your window stops carrying frontend conventions while you are editing the database layer.

/compact vs /clear vs a new session

/clear on task change is hygiene. /clear as a nervous habit throws away a warm cache and costs you money.

The two memory systems

Both can involve a file called MEMORY.md. They are unrelated. Say this out loud once and it stops confusing you.

1. Native auto memory: Claude writes it

• On by default
• Lives at ~/.claude/projects/<repo>/memory/MEMORY.md
• Machine-local. Never committed. Does not travel
• Only the first 200 lines or 25KB of the index load. Topic files sit beside it and load on demand
• Toggle with /memory

Claude files things there on its own: facts about the project, facts about you, corrections you gave it. The filing scheme it uses is its own emergent habit, not a specification - do not build process around the exact shape, because another machine may look different.

2. A committed memory doc: you write it

• Lives in the repo, committed, reviewable in a PR
• Usually @-imported from CLAUDE.md, so it loads in full
• Travels with the project and applies to everyone

The distinction that matters: native memory is automatic and local. A committed doc is shared and reviewable. If a fact needs to survive a laptop, a teammate, or a code review, it belongs in the committed one.

CLAUDE.md, in one paragraph

Four scopes, concatenated broadest-first rather than overridden: managed policy, your user file at ~/.claude/CLAUDE.md, the project file at ./CLAUDE.md or ./.claude/CLAUDE.md, and a gitignored CLAUDE.local.md. It walks up the tree, so a file in a parent directory still applies. Subdirectory files load on demand. Target under 200 lines. Full detail in CLAUDE.md: The Contract.

Cost, since context is the meter

• A cache read costs roughly 10% of base input. A five-minute cache pays for itself after one read, a one-hour cache after two
• Caching is prefix-based: stable content first, and editing CLAUDE.md mid-session invalidates everything after it
• None of this is metered on a Max subscription, which is flat with usage limits. It applies to the Developer Platform and API

The five-minute audit

1. Run /context. Note the largest thing you did not expect
2. Open CLAUDE.md. For each line ask: would Claude get this wrong without me? If no, cut it
3. Move anything that only matters in part of the repo into .claude/rules/ with a paths: glob
4. Check whether native memory is on, and read what Claude has been keeping. It is often the most honest description of your project anywhere
5. Decide, once, which facts belong in a committed doc because they must survive your laptop

// 04

The Reusable Layer

Current as of August 2026.

In a chat you get answers, and they evaporate. In a folder you accumulate artifacts that persist and compound: skills, commands, connectors, config.

There is a second reason this matters more than it looks. A natural-language ask runs differently every time. A code artifact runs the same way every time. Building the reusable layer is converting the things you keep asking for into things that just run.

Four building blocks

Custom commands and skills have converged: .claude/commands/x.md and .claude/skills/x/SKILL.md both give you /x.

What goes where

The single most common source of confusion. The two questions that resolve it:

1. Is it a fact, a behavior, an action, or access?

fact about the project ─────────► CLAUDE.md
how to do something ────────────► skill
a task you invoke ──────────────► command
reaching another system ────────► MCP / connector
reference material ─────────────► docs/
permissions, model, hooks ──────► .claude/settings.json

2. Is it always relevant, or only sometimes?

always ────────────► CLAUDE.md (loads every session, in full)
in one area ───────► .claude/rules/ with a paths: glob (loads on match)
occasionally ──────► docs/ (loads when read or @-mentioned)

Get both right and your context window stops being full of things that do not apply.

Skills

A folder with a SKILL.md describing a behavior in plain language. No special syntax required.

# Brand voice
 
When writing anything customer-facing:
 
- No em-dashes. Use a period, a colon, or a spaced hyphen
- Never say "student". The audience are working professionals
- Lead with the outcome, not the mechanism
- If a sentence could appear in any company's marketing, cut it

Where each surface reads them from (this surprises everyone once):

So pulling an account skill down into .claude/skills/ is the right move for local use. Connectors behave the opposite way - they follow your account everywhere.

Write the skill after you have done the thing twice by hand, not before. A skill you have never run is a guess. Create it, then immediately use it once.

Commands

A markdown file whose content becomes the prompt.

.claude/commands/critique.md:

Review the current diff as a skeptical senior engineer.
 
Look for: logic that only works on the happy path, error cases that
are swallowed, anything that will be confusing in six months, and
naming that does not match the rest of the codebase.
 
Rank by how much it would cost to fix later. Be specific about
files and lines. Do not comment on formatting.

Now /critique runs the same review every time, instead of a slightly different one depending on how you phrased it.

Good candidates: a review pass you always do, a release checklist, a PR summary in your format, a repeated refactor.

MCP

one question, every tool, over MCP

you ask

“Which of our top accounts are about to churn?”

Claudethe MCP clientfans out 4 tool calls in parallel, then reasons over what comes back

live pulls over MCP

1

Postgres

product usage server

returns

Acme logins down 60% in 14 days

2

Stripe

billing server

returns

Globex: payment failed x2

3

Notion

CRM server

returns

Acme: 2 open support tickets

4

Resend

email server

returns

Acme email opens down 40%

Claude synthesizes 4 sources

↓

grounded answer

1. 1Acme high risk: usage down 60%, opens down 40%, 2 open tickets
2. 2Globex watch: 2 failed payments, usage still healthy

Three systems pointed at Acme, one at Globex. The ranking is the reasoning, not a guess: each line traces back to a real number Claude pulled live.

no bespoke integrations: one open protocol, every tool speaks it

The protocol that lets Claude reach systems you did not build for it. It is the reason "which accounts are about to churn?" can be answered from live data rather than guessed.

Two ways in, both active at once:

This is why your connectors "just work" in the terminal with no config - they are account connectors, not files.

.mcp.json declares servers. .claude/settings.json (enableAllProjectMcpServers, enabledMcpjsonServers) approves them. In the app, /mcp opens the connector GUI and will not list file-based servers, though the agent still loads them.

Connect everything in the directory that you actually use. Not two or three. The value is combinatorial: one connector answers a question, four connectors answer a question nobody could answer before.

Permissions. A new connector returns nothing until its tools are approved. That prompt is the feature, not a bug. Set read-only tools to always-allow and leave writes on ask - that single configuration is the difference between useful and nerve-wracking.

Plugins

Marketplaces of prepackaged skills, commands and configuration.

/plugin marketplace add <owner>/<repo>
/plugin install <name>@<marketplace>
/reload-plugins

Convenient and worth knowing. Read what you are installing. A plugin can carry instructions that change how Claude behaves everywhere, and "I installed something and now it acts strangely" is a genuinely hard thing to debug after the fact.

Building it, in order

1. Do the thing by hand. Twice
2. On the second time, notice what you re-explained
3. That is your skill. Write it and run it once
4. Notice what you re-invoke. That is your command
5. Notice what you had to go look up in another system. That is your MCP connection
6. Every few weeks, reread CLAUDE.md and cut what no longer bites

The layer compounds. Two months in, a session starts already knowing your conventions, already able to reach your systems, with your reviews one keystroke away. That is the actual difference between someone who uses Claude and someone who operates it.

// 05

Claude Code Cheat Sheet

Current as of August 2026.

⚠️ The command set differs by surface. The Claude app shows a subset of the terminal CLI's commands, plus a few the CLI reference does not list. Cloud sessions differ again. Everything below is marked where it matters. Verify on the surface you are actually using rather than trusting a doc page, including this one.

Session control

These act on the session itself. Most cannot be asked for in prose, which is the real reason to know them.

/clear vs /compact vs a new session

• /compact - same task, less window. You are continuing
• /clear - unrelated task. Nothing from before is worth carrying
• new session - the current one is polluted. Compacting carries the confusion forward with it

The reusable layer

The /init caveat. It writes a CLAUDE.md by describing your codebase - structure, language, dependencies. Claude infers nearly all of that on its own, so most of what it produces is context-window rent. The CLAUDE.md worth having says what the code does not say: the conventions, the constraints, the things you had to correct. Write that one from failures you actually watched. Run /init twice and you get redundant information, which is its own documented failure.

/ultrareview - cloud multi-agent bug hunt across your branch. Takes roughly five to ten minutes and costs real money per run. Worth knowing it exists; worth knowing the price before you fire it.

Where configuration lives

your-project/
├── CLAUDE.md              the contract. Loads every session, in full
├── .mcp.json              MCP servers, project scope, committed
├── docs/                  reference material, pulled on demand
└── .claude/
    ├── settings.json      permissions, hooks, env, model
    ├── settings.local.json  same, gitignored, yours only
    ├── rules/             topic rules, optionally path-scoped
    ├── skills/            behaviors
    ├── commands/          your own slash commands
    └── agents/            subagent definitions

~/.claude/                 machine-local. Does NOT travel with the project
├── CLAUDE.md              applies to everything you do
├── settings.json
└── projects/<repo>/memory/MEMORY.md    what Claude keeps on its own

The rule: in ~/.claude/ is machine-local. Committed to the folder travels.

Permission modes

Shift+Tab cycles default → acceptEdits → plan.

Deny rules and explicit ask rules still apply in every mode, including bypass. That is the safety property worth remembering.

Context, in one page

Claude Code searches your repo the way you would - it greps and reads files. There is no vector database and no embedding step. That is why a clear folder structure and a real CLAUDE.md beat any retrieval trick.

• CLAUDE.md loads in full, every session. Target under 200 lines
• Native auto memory loads only the first 200 lines or 25KB of its index. Topic files load on demand
• @path/to/file in CLAUDE.md pins a file into every session. Max 4 hops of nesting
• @-mentioning a file in a prompt pulls it into that turn only
• .claude/rules/*.md with a paths: glob in frontmatter load only when Claude touches matching files. This is the fix for a context window that is always full

Cost levers

• Effort is usually the better lever than switching models
• Prompt caching: a cache read costs about 10% of base input. A five-minute cache pays for itself after one read; a one-hour cache after two
• Caching is prefix-based - stable content goes first, and editing CLAUDE.md mid-session invalidates everything after it
• None of this is metered on a Max subscription, which is flat with usage limits. It applies to the Developer Platform and API

Ten things worth doing today

1. Run /context and look at what is actually loaded
2. Cut your CLAUDE.md to what Claude got wrong, not what it can already see
3. Move anything conditional into .claude/rules/ with a paths: glob
4. Set read-only tools to always-allow, writes to ask
5. Use plan mode before anything that touches more than a couple of files
6. Turn one repeated instruction into a skill, then actually run it once
7. Turn one repeated action into a slash command
8. Connect one real system through MCP
9. Ask Claude to explain a part of your codebase you inherited. The gaps in its answer are your CLAUDE.md
10. Read The Claude Stack and check you are in the right surface at all

// 06

Agents and Automation

Current as of August 2026.

The through-line: agent management is context management. Your main thread is finite. Skills, subagents, teams, workflows and scheduled work all exist so the work happens somewhere else and only the answer lands in your window.

That single idea turns an intimidating feature list into one argument.

The ladder

Each rung delegates a bigger unit of work.

you type it            ──────────►  a message
you describe the task  ──────────►  a subagent, in its own context
you describe the team  ──────────►  agent teams, sharing a task list
you describe the plan  ──────────►  a workflow, a script holds the plan
you describe the goal  ──────────►  a routine or a managed agent, no you required

Subagents

A specialist that runs in its own context window and reports back a summary.

Defined in .claude/agents/*.md. Only a name and description are required; tools and model are optional.

---
name: design-reviewer
description: Reviews UI changes against the design system
---
 
Review the current changes against the tokens in src/styles/tokens/.
 
Flag: hardcoded colors or spacing that should be tokens, components
that duplicate an existing primitive, and anything that will break
at 375px. Be specific about files and lines.

Invoke by asking ("use the design-reviewer subagent") or with an @-mention. There are built-ins too, including Explore and Plan.

Reach for one when: you want a specialist opinion without polluting your main thread, you want several perspectives in parallel, or you want something read-only looking at your work.

The context argument: a subagent reading forty files and reporting three sentences costs you three sentences of window. Doing it inline costs you forty files.

Agent teams

Experimental. A lead plus teammates sharing a task list and a mailbox, able to message each other.

Enabled with an env var in .claude/settings.json:

{ "env": { "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1" } }

Start with three to five. Token cost is meaningfully higher. Verify it runs on your machine before you plan a demo around it - experimental features are gated and can be absent without explanation.

Dynamic workflows

A script holds the plan rather than the model. Deterministic control flow: loops, conditionals, fan-out. Up to sixteen agents concurrently.

Three ways to invoke: the built-in /deep-research, a saved workflow file run by name, or describing one in natural language.

Reach for one when the shape of the work is known and repeatable and you want it executed the same way every time. If the plan itself is the uncertain part, you want an agent, not a workflow.

Who holds the plan?

The question that picks the right tool.

Routines vs Cowork tasks

Both run in the cloud. The old "local versus cloud" framing is dead and will mislead you.

The real axis is what the deliverable is.

The decision that survives: is the deliverable a change in a code repo? Yes → Routine. No → Cowork.

For "pull some data on a schedule and post a summary," either works and it is mostly preference.

Routines can be created conversationally with /schedule (alias /routines), or from the desktop sidebar with no command at all. The sidebar path is the reliable one, since the command is gated in some environments.

Managed agents

Anthropic hosts the loop, the sandbox and the tools. The Agent SDK without the servers.

Four objects: an agent, an environment (a cloud sandbox), a session, and a stream of events. A session fires from an API call or a scheduled deployment.

Memory stores are the part worth understanding. A workspace-scoped set of text files mounted into the sandbox, which the agent reads and writes with ordinary file tools, and which persist across sessions. Versioned, so you can audit and roll back. One shared read-only store plus per-user read-write stores is a genuine team-brain pattern.

Dreaming is the honest version of "it gets better over time": an async job reads a memory store plus past session transcripts and produces a new, reorganized store - deduplicated, stale entries replaced, new insights surfaced. The input is never modified; you review the output and keep or discard it. The memory improves and gets curated. The model does not retrain.

Reach for one when the agent is a feature inside your product, triggered by your users, doing multi-step tool work you do not want to host.

The discriminator against Routines: you schedule it against your repo → Routine. Your users trigger it inside your product → Agent SDK or managed agent.

Choosing, quickly

Need a second opinion without polluting your thread? ──► subagent
Need several perspectives at once? ───────────────────► subagents in parallel, or a team
Same multi-step process every time? ──────────────────► dynamic workflow
Should produce a PR on a schedule? ───────────────────► Routine
Should produce a brief or act across tools? ──────────► Cowork task
Lives inside your product, fired by your users? ──────► managed agent

Where people go wrong

• Reaching for a fleet when one good subagent would do. More agents is more coordination cost, not more intelligence
• Using an agent where a workflow belongs. If you already know the steps, encode them. Determinism is a feature
• Forgetting the stop condition. An agent loops until something says stop: the goal is met, the tests pass, a step limit is hit, or you say so. Decide which one before you start it
• Automating something you have never done by hand. You cannot specify what you have not watched fail

A first automation worth building

Pick something you do every morning and dislike.

A daily brief is the usual winner: pull from the two or three systems where your reality actually lives, rank what needs you, draft the replies you would have written, and note what it ignored. Run it manually first. Read the output. Fix the instructions. Run it manually again. Only then put it on a schedule.

Scheduled work you have not validated by hand is a machine for generating confident noise.

// 07

Models, Effort and Cost

Current as of August 2026. Model names and prices move faster than anything else in this toolkit. Check the pricing page before you build a budget on these numbers.

The models

Context window: 200K.

⚠️ Models from 4.7 onward use a newer tokenizer that produces roughly 30% more tokens for the same text. Per-word cost is therefore not comparable across generations, and a naive price comparison against older numbers will mislead you.

Effort is usually the better lever

Before switching models, try changing effort.

Raising effort on the model you have often beats dropping to a cheaper one, because a cheap model that gets it wrong twice costs more than an expensive model that gets it right once - in tokens and in your time.

The useful heuristic: switch models when the task category changes. Change effort when the difficulty changes.

Prompt caching, properly

Four price buckets, not two. Using Opus 5 as the worked example:

A cache read costs about 10% of base input. So:

• A five-minute cache pays for itself after one read
• A one-hour cache pays for itself after two

Caching is prefix-based. A breakpoint caches everything from the start of the prompt up to that point. Two consequences that actually bite:

1. Stable content goes first. Your long-lived context should sit at the front, and volatile content at the back
2. Editing CLAUDE.md mid-session invalidates everything after it. If you are iterating on config, expect to repay the write

This is also the real economics under /clear versus /compact. Clearing discards the cache. Clear on a genuine task change; do not clear as a nervous habit.

The subscription caveat that saves confusion

None of the above is metered on a Max subscription. Max is flat monthly with usage limits, not per-token billing.

Token prices apply to Developer Platform and API work: things you build, agents you host, features inside your product.

So "which model is cheaper" is a live question when you are building something, and mostly a non-question when you are using Claude Code on a subscription. What binds you there is the usage limit, not the bill - which is why Pro often runs out partway through a heavy hands-on day and Max generally does not.

Managed agents

Priced as $0.08 per session-hour, plus standard token rates. Worth knowing before you leave one running on a schedule.

Practical cost discipline

1. Do not optimize before you measure. Most people's real cost is one runaway loop, not their model choice
2. Put stable context first so caching can do its job
3. Match the model to the task category, and use effort within it
4. Watch for repeated work. If you are re-answering the same question weekly, that is a skill or a command, and the cheapest token is the one you never spend
5. Cheap models are for volume, not for hard things. A Haiku answer you have to check twice was not cheap

Verifying this page

These numbers change. The habit that keeps you correct:

• Check pricing on the platform pricing page before committing to a budget
• Check model availability in the picker on the surface you are using, since they do not all offer the same set
• Treat any figure in a blog post, including this one, as a snapshot rather than a fact

Your own account beats any documentation for what you can actually run today.