What you will be able to do
- Structure a request so Claude gets complete context in one message instead of in fragments
- Use Projects so material you reuse is uploaded once and benefits from caching
- Recognise when a long conversation is costing more than it returns, and start fresh
- Keep a working setup lean by switching off tools and servers the task does not need
- Make a fix persistent so the same problem is not re-solved in every session
Key concept
Usage has several drivers — How fast you use up your allowance depends on more than how much context you send and carry forward. The model, the effort level and the features you switch on matter too. An efficient workflow gives Claude complete context once, reuses it through a Project, drops context that no longer helps, and keeps models, effort and tools matched to the task. When usage is a problem, check where it actually goes before changing habits.
1.Give complete context in one well-structured message
Many inefficient workflows start with a habit that feels economical: send a little, see what comes back, then add more. Anthropic's usage-limit guidance recommends the opposite. Put everything Claude needs into the first message, structured so it is easy to use. For editing, the guide says to "Send entire texts for editing in one message rather than breaking them up." For data work: "Provide all relevant data in a single, well-structured message."
It is a mistake to treat this as only a usage tip. A message that holds the whole picture is also a better prompt. If Claude sees fragment three without fragments four to eight, it has to guess, and every guess you then correct costs another turn. The guide applies the same rule to each kind of work. State the requirements, the audience and the key points up front, and define the research question before the research starts.
| Type of work | Put this in the first message |
|---|---|
| Coding | Provide complete context about your coding environment in your initial message; include entire relevant code snippets in one message for reviews or debugging |
| Writing | Outline requirements, target audience, and key points comprehensively; send entire texts for editing in one message |
| Research | Clearly define your research question and focus areas initially |
| Data analysis | Provide all relevant data in a single, well-structured message |
The Claude Code best-practices guide teaches the same idea through before-and-after prompts. The vague "fix the login bug" becomes a prompt that names the symptom, the likely location and what "fixed" looks like. A specific first request avoids the round trips spent finding out what you meant.
Some context is the same for every conversation on a topic: a tone, a role, key guidelines. Repeating it in each first message is wasted effort. In claude.ai, project instructions hold it once, and Claude uses them for all the chats within the project. The support guidance says what belongs there: "Keep your project instructions concise and focused on essential information." Use them for general context around your project, key guidelines and Claude's role. Task-specific instructions do not belong there. The same article says to "Reserve task-specific instructions for the chat itself." So the split is: standing lines that apply every time go in project instructions, kept short, and the details of today's task go in a complete first message.
Checkpoint 1 of 8· Check yourself
An editor wants Claude to tighten a 4,000-word report. Which approach matches the usage-limit guidance?
The guide says to send the whole text for editing in one message. Splitting it up means more turns and leaves Claude without the full picture.
“Send entire texts for editing in one message rather than breaking them up.”Source: support.claude.com
Checkpoint 2 of 8· Exam question
An analyst begins every chat in her weekly reporting project by typing the same six lines about house style, the sections required and how figures should be rounded. What is the most effective first change?
Correct answer: A — Move those standing lines into the project's instructions so every chat there starts with them.
- A. Correct. A requirement repeated in every chat of the same project belongs in the project instructions, where it applies automatically and stops depending on her remembering it.
- B. A note reduces typing but still relies on her pasting it correctly every single time.
- C. Asking Claude to recall earlier style is unreliable and does not make the requirement durable.
- D. Uploaded documents are background knowledge; a standing rule about how to work belongs in the instructions.
2.Upload once, reuse often: Projects and caching
Front-loading fixes a single conversation. Work you come back to needs a home that lasts. The guidance is plain: "Use projects for anything you'll reference multiple times." It adds that you should upload your core working documents to the project knowledge section when you start the project. Reuse is cheaper too, not only more convenient: "The more you use the same content, the more benefit you get from caching." Content in a Project is cached, and when you reference it again while it is still cached, cached portions count less against your limits than new content.
There is a caveat. Caches expire after a period of inactivity, so if you come back to a project after a long break, your first message counts that content in full again. The saving is real, but it depends on steady use. Keep the Project itself lean as well: the length guide advises shortening project instructions to essentials and regularly removing project files you are no longer actively using.
Projects also handle large knowledge bases. On paid plans (Pro, Max, Team and Enterprise), when project knowledge approaches the context window limit, Claude automatically switches to retrieval-augmented generation (RAG). In this mode Claude uses a project knowledge search tool and does not load every file at once. Instead, "Claude intelligently searches and retrieves only the most relevant information needed to answer your questions." This expands a project's capacity by up to 10x.
Checkpoint 3 of 8· Check yourself
A team's Project keeps growing until its knowledge nears the context window limit. What happens on a paid plan?
Close to the limit, Claude switches to RAG mode. It uses a project knowledge search tool, which expands capacity by up to 10x.
“When your project knowledge approaches the context window limit, Claude will automatically enable RAG mode to expand your project's capacity by up to 10x”Source: support.claude.com
3.When the conversation itself is the cost
Length limits come from the context window, which the support article describes as "Claude's working memory". With code execution enabled, Claude manages long chats itself: "When your conversation approaches the context window limit, Claude summarizes earlier messages to continue the conversation seamlessly." Being able to continue does not make it cheap. The article tells you what to do when the two collide: "Try starting a new conversation if you're approaching your usage limit in a longer chat." This matters most when the next task is unrelated. A long thread brings no useful context to the new task, and it costs more.
Claude Code's documentation explains why, and gives finer controls. Claude Code sends the full conversation with every request, so "a one-line question in a session that has been open all day still draws usage for the whole conversation". Its cost guide warns: "Stale context wastes tokens on every subsequent message." Caching lowers the rate at which that history is read, but it does not make it free. There are two remedies, and they cost different amounts. /clear resets context between unrelated tasks, and when you want a fresh start rather than continuity it costs nothing. /compact keeps continuity, but it reads the conversation it summarizes, so compacting a large context is itself a large request. These are Claude Code commands, but the choice behind them is the same everywhere: carry context forward only when the next task needs it.
Before you change habits, find out where the usage is going. Conversation length is only one driver. The usage-limit guide also lists message length, file attachment size, tool usage such as Research and web search, model choice, effort level, artifact creation and multi-step tasks like running code or browsing. On Pro, Max, Team and seat-based Enterprise plans, go to Settings > Usage to see progress bars for your five-hour session and your weekly limits, including when the weekly limit resets. Compare that with what you did that week. Organization admins have a similar view: the Enterprise consumption guide points them to cost per session by type of output and to the most expensive sessions, to see where spend concentrates. Measuring first tells you which fix to apply, whether that is starting fresh, trimming tools, lowering effort or something else.
Checkpoint 4 of 8· Check yourself
In Claude Code, a developer finishes a long debugging session and moves to unrelated work. They do not need any earlier context. Which option is cheapest?
/compact has to read the whole conversation to summarize it. /clear simply starts fresh, which is right when continuity isn't needed. Staying in the session is not free either: caching only lowers the rate, and the whole history still draws usage on every request.
“When you want a fresh start instead of continuity, /clear costs nothing”Source: code.claude.com
Checkpoint 5 of 8· Exam question
A four-person team runs out of its weekly Claude allowance every Thursday and work stalls until the limit resets. What should they do first?
Correct answer: B — Look at which tasks are actually consuming the allowance before changing plans or habits.
- A. Forcing the fastest model on everything trades quality away without knowing what actually consumed the allowance.
- B. Correct. Until the team knows where the allowance is actually going, every remedy is a guess; checking which work is consuming it points at the habit or task to change.
- C. Short messages can cost more overall if they cause long back-and-forth exchanges to reach the same result.
- D. Upgrading may be the right answer eventually, but paying to avoid a diagnosis usually hides the real cause.
4.Keep the working setup lean
Context also comes from your setup, not only from the messages you send. Claude Code's context-window walkthrough shows this before any prompt is sent: "Before you type anything: CLAUDE.md, auto memory, MCP tool names, and skill descriptions all load into context." Each tool you leave connected takes up room in every session, whether or not the task uses it. The cost guide's advice is to "Disable unused servers: Run /mcp to see configured servers and disable any you’re not actively using." It also prefers command-line tools such as gh where available, because they are "more context-efficient than MCP servers because they don’t add any per-tool listing".
claude.ai has matching controls, and the length-limits article lists them. Turn off tools you don't need: switch off connected apps when a conversation doesn't need them, and ask Claude not to search the web when you don't need current information. The article notes that tools and connectors are token-intensive, so managing them helps both your context window and your usage limits. It also advises turning extended thinking off when a task doesn't need enhanced reasoning, and choosing a lower effort level for routine tasks, since higher effort uses more tokens. Finally, remove project files you no longer use. (The "Search and tools" menu advice in the connectors article is framed around security, but the length-limits article supplies the usage reason.)
Choosing a model is also part of the setup. Match it to the job. The Enterprise consumption guide says "Sonnet is the default and handles most tasks well", and to use Opus only when Sonnet is not getting you there. The usage-credits guide likewise recommends the most efficient Haiku model or the most recent Sonnet model for most tasks, at lower token cost than Opus. Reaching for the largest model is not a substitute for a clear prompt. In Claude Code, "each model has its own cache", so switching models mid-session reprocesses the whole request. Pick the model at the start of the task rather than switching back and forth. Removing a tool on purpose mid-session, for example by disabling its server in /mcp, also invalidates the cache, so trim your setup at the start of a session rather than partway through.
Checkpoint 6 of 8· Check yourself
Why does Claude Code's cost guide prefer CLI tools such as gh over an equivalent MCP server when both are available?
MCP servers put their tool listings into context. A CLI tool that Claude runs directly does not.
“more context-efficient than MCP servers because they don’t add any per-tool listing”Source: code.claude.com
5.Avoid rework, then make the fix stick
The most expensive output is one you throw away and generate again. Claude Code's guidance tackles this in three ways. First, plan before acting. Plan mode has Claude propose an approach for your approval, "preventing expensive re-work when the initial direction is wrong." Second, give Claude a way to check its own work. When you include test cases or expected output, Claude "catches issues before you need to request fixes." Third, move in small steps: "Write one file, test it, then continue. This catches issues early when they’re cheap to fix." The best-practices guide turns this into a sequence: explore, then plan, then implement against the plan, then commit.
Checkpoint 7 of 8· Check yourself
Claude Code keeps heading down the wrong path on a large change, and each wrong attempt is regenerated from scratch. Which habit from the guidance addresses the cause?
Plan mode has Claude propose an approach for approval, which prevents expensive re-work when the initial direction is wrong. Testing in small steps catches problems early, so skipping tests or batching fixes does the opposite.
“preventing expensive re-work when the initial direction is wrong”Source: code.claude.com
The last step is closing the loop. When you have worked out how Claude should handle a recurring kind of task, store that answer somewhere it is reused automatically, so you are not re-explaining it every session. In Claude Code, durable instructions go into CLAUDE.md, and repeatable procedures go into a skill like the one below. In claude.ai, the equivalents are project instructions for a Project, and standing instructions that apply to every Cowork session. The best-practices guide says to leave "Information that changes frequently" out of CLAUDE.md. The monorepo guide treats instructions as living documents: review CLAUDE.md edits in pull requests "so conventions track the code", and revisit them after major model releases, because "instructions that worked around an older model’s limitation may become overhead".
Making a fix persistent for a team follows the same discipline as the rest of this lesson. First write down the steps that worked, as a skill or shared instructions. Then test them before you rely on them, in small steps against real cases, since the cost guide says testing incrementally "catches issues early when they’re cheap to fix". Give the process verification targets such as test cases or expected output, so Claude can check its own work. Only then roll it out widely. The Enterprise consumption guide describes the payoff: packaging repeated work as a shared skill gets the whole team a consistent result faster, and once it is rolled out you can track its cost and return. Repeated friction and rework loops are the signal that something is worth packaging.
---
name: api-conventions
description: REST API design conventions for our services
---
# API Conventions
- Use kebab-case for URL paths
- Use camelCase for JSON properties
- Always include pagination for list endpoints
- Version APIs in the URL path (/v1/, /v2/)Checkpoint 8 of 8· Exam question
A coordinator has been running a Claude-assisted intake process successfully on his own and now wants twelve colleagues to use it. What should he do first?
Correct answer: C — Write down the steps that actually worked and run them on two recent real cases to confirm.
- A. Training people in a procedure that has not been written down or re-tested spreads the gaps as well.
- B. A guide written from his description records what he thinks he does, not what actually worked.
- C. Correct. What works in one person's hands is often partly undocumented habit; writing the steps down and re-running them on real cases is what turns it into something twelve people can repeat.
- D. Twelve personal adaptations produce twelve different results and no shared practice to improve.
Exam traps
Each one states something that sounds right. Open it to see what is actually true.
1.Sending material in small pieces over several messages is lighter on usage than one large message.Why is that wrong?
The usage-limit guide says the opposite: put the whole text or dataset into one well-structured message.
Covered in Give complete context in one well-structured message
2.Because Claude automatically summarizes long chats, it is free to keep running unrelated tasks in one very long conversation.Why is that wrong?
Automatic context management lets the chat continue, but those longer conversations use more of your limit. Near the limit, start a new conversation.
Covered in When the conversation itself is the cost
3.Pasting the same reference documents into each new chat works as well as keeping them in a Project.Why is that wrong?
Material you reuse belongs in a Project, and reusing the same content gets more benefit from caching.
4.Once content is cached in a Project, it stays cheap no matter how long you are away.Why is that wrong?
Caches expire after inactivity, so the first message after a long break counts that content in full again.
5.Once standing instructions are written, they can be left alone.Why is that wrong?
Instructions need maintenance. Review them alongside the code, and revisit them after model releases, because workarounds can turn into overhead.
Covered in Avoid rework, then make the fix stick
Sources
Every claim above is drawn from one of these pages, quoted as it was written on the date shown.
- 1.
“Send entire texts for editing in one message rather than breaking them up.”
↩︎ Give complete context in one well-structured message“Outline requirements, target audience, and key points comprehensively.”
↩︎ Give complete context in one well-structured message“Use projects for anything you'll reference multiple times.”
↩︎ Upload once, reuse often: Projects and caching“Caches expire after a period of inactivity.”
↩︎ Upload once, reuse often: Projects and caching“navigate to Settings > Usage to view progress bars showing how much of your five-hour session and weekly usage limits”
↩︎ When the conversation itself is the cost“Provide all relevant data in a single, well-structured message.”
↩︎ Exam trap 1“The more you use the same content, the more benefit you get from caching.”
↩︎ Exam trap 3“Caches expire after a period of inactivity.”
↩︎ Exam trap 4 - 2.
“Keep your project instructions concise and focused on essential information.”
↩︎ Give complete context in one well-structured message“Reserve task-specific instructions for the chat itself.”
↩︎ Give complete context in one well-structured message“Regularly clean up files you're no longer actively using in your projects.”
↩︎ Upload once, reuse often: Projects and caching“Try starting a new conversation if you're approaching your usage limit in a longer chat.”
↩︎ When the conversation itself is the cost“Tools and connectors are token-intensive”
↩︎ Keep the working setup lean“Turn off this feature when you don't need Claude's enhanced reasoning for a particular task.”
↩︎ Keep the working setup lean“Your usage is affected by several factors, including the length and complexity of your conversations, the features you use”
↩︎ Key concept“Try starting a new conversation if you're approaching your usage limit in a longer chat.”
↩︎ Exam trap 2“Longer conversations that trigger automatic context management consume more of your usage limit.”
↩︎ Prediction - 3.https://support.claude.com/en/articles/11473015-retrieval-augmented-generation-rag-for-projectsOfficial docs
“Claude intelligently searches and retrieves only the most relevant information needed to answer your questions.”
↩︎ Upload once, reuse often: Projects and caching“When your project knowledge approaches the context window limit, Claude will automatically enable RAG mode to expand your project's capacity by up to 10x”
↩︎ Checkpoint - 4.https://code.claude.com/docs/en/costsOfficial docs
“Stale context wastes tokens on every subsequent message.”
↩︎ When the conversation itself is the cost“/compact reads the conversation it summarizes, so compacting a large context is itself a large request”
↩︎ When the conversation itself is the cost“Disable unused servers: Run /mcp to see configured servers and disable any you’re not actively using.”
↩︎ Keep the working setup lean“preventing expensive re-work when the initial direction is wrong”
↩︎ Avoid rework, then make the fix stick“Write one file, test it, then continue. This catches issues early when they’re cheap to fix.”
↩︎ Avoid rework, then make the fix stick“When you want a fresh start instead of continuity, /clear costs nothing”
↩︎ Checkpoint“more context-efficient than MCP servers because they don’t add any per-tool listing”
↩︎ Checkpoint - 5.
“Most expensive sessions. See where spend concentrates.”
↩︎ When the conversation itself is the cost“Sonnet is the default and handles most tasks well.”
↩︎ Keep the working setup lean“Packaging repeated work as a shared skill gets the whole team a consistent result faster.”
↩︎ Avoid rework, then make the fix stick - 6.https://code.claude.com/docs/en/context-windowOfficial docs
“Before you type anything: CLAUDE.md, auto memory, MCP tool names, and skill descriptions all load into context.”
↩︎ Keep the working setup lean - 7.https://code.claude.com/docs/en/prompt-cachingOfficial docs
“each model has its own cache”
↩︎ Keep the working setup lean“disabling its server in /mcp”
↩︎ Keep the working setup lean - 8.https://code.claude.com/docs/en/large-codebasesOfficial docs
“Review in pull requests: treat CLAUDE.md edits like any other documentation change so conventions track the code”
↩︎ Avoid rework, then make the fix stick“Revisit after major model releases: instructions that worked around an older model’s limitation may become overhead”
↩︎ Exam trap 5 - 9.
“You can give Claude standing instructions that apply to every Cowork session.”
↩︎ Avoid rework, then make the fix stick