The basics to understand before you use Claude seriously

Anthropic's context window documentation says everything in a request counts: the system prompt, every message in the conversation (including tool results, images and documents), and your tool definitions. The reply Claude writes counts too, including any extended thinking.

Each API response reports what it used in a usage field. If you use prompt caching, the input count is split across input_tokens, cache_read_input_tokens and cache_creation_input_tokens, and all three count toward the window. To estimate a request before sending it, Anthropic provides a token counting endpoint. Chat apps such as claude.ai may also manage the window on a rolling first-in, first-out basis, according to a footnote in the same documentation.

Anthropic's prompting guidance says that setting a role in the system prompt focuses Claude's behaviour and tone, and that even a single sentence makes a difference. When you use a ready-made product, someone else wrote the system prompt. When you build a tool, or use a feature that lets you set standing instructions, you write it.

System prompts also count toward the context window and are re-sent every turn, which is exactly why repeated, stable text is a good candidate for prompt caching (part 5).

Anthropic's documentation describes the window as a kind of working memory, different from the huge body of text the model was trained on. It also warns that more context is not automatically better: as the number of tokens grows, accuracy and recall can degrade, an effect it calls context rot. That makes curating what is in context as important as how much space is available.

If input alone exceeds the window, the API returns an error. On newer models, if input plus the requested maximum output exceeds the window, the request is still accepted, and generation simply stops with a specific stop reason if it reaches the limit. For long-running work, Anthropic offers server-side compaction (beta) that summarises earlier turns, and context editing to clear old tool results. Part 6 goes deeper.

Anthropic's own cost-optimisation advice is to use Haiku for simple tasks, Sonnet for most production workloads and Opus for the most complex reasoning. It also lists a "latency" comparison: Haiku fastest, Sonnet fast, Opus moderate, Fable slower. A practical pattern is to start with the smaller model and only move up when your own test cases show it falling short.

Anthropic's documentation says that with adaptive thinking the model decides how much thinking a task needs, so harder questions get more. Thinking tokens are part of the output limit, are billed as output tokens, and count toward rate limits and the context window. On some models earlier thinking blocks are kept in the conversation by default and count as input on later turns; on others they are stripped automatically. Check the per-model behaviour in the documentation if you build on it.

Anthropic's documentation mentions web search and code execution as tools its models can use, among others. When Claude uses a tool, the tool's result is returned into the conversation and Claude carries on from there. Tool definitions and results both consume context, so a long tool list or a huge tool result has a cost. Claude Code defers loading full tool schemas for connected MCP servers until needed, which keeps idle tools cheap.

Anthropic says its latest models are less prone to hallucination than earlier ones. Its prompting guidance for coding includes a sample instruction telling Claude to read the relevant files before answering questions about a codebase and never to make claims about code it has not opened. The general principle is to ground answers in material actually present in the context and to make "I do not know" an acceptable answer.