Search a lesson

157 lessons.

Chat, Cowork, Claude Code, three tools, three usesChoosing the right way in
Each Claude environment answers a different need, none replaces the other two.
Cowork, the default mode for a non technical userChoosing the right way in
Cowork acts directly on connected folders and breaks work into small passes rather than a single giant treatment.
Setting up the computer for long sessionsChoosing the right way in
Keep the computer active before any long task, otherwise the session stops without warning.
Understanding the token and the context windowNever running out of tokens
Every word read or written consumes a token, and reopening an old session reloads, and therefore repays, its whole context window.
What to do when the limit is reachedNever running out of tokens
A reached quota blocks the sending of new messages until an event that depends on the type of account, and the only reliable action in the meantime is to know in advance who to contact within your organisation.
The right habits for savingNever running out of tokens
Several short sessions attached to a project make Claude reread far less material than a single session dragged out from one day to the next.
The project, a container for contextKeeping the thread from day to day
A project groups files, instructions and sessions in a single place that persists from one time to the next, a task handled outside any project stays an isolated session that keeps nothing after it closes.
Turning on memory, distinct from historyKeeping the thread from day to day
Memory keeps a chosen selection of what has been said, history keeps every conversation as it happened without a new session rereading it on its own.
Resuming a session without losing everythingKeeping the thread from day to day
Opening a fresh session attached to the same project and asking it to resume the context costs less and moves faster than extending a session that has already grown heavy.
What Cowork sees and what it does not seePutting Claude to work on real files
The files Cowork reads and modifies are those in the folders you have connected, but its view does not stop at files: depending on how you open it, it also sees your screen.
Working on a copy, never on the originalPutting Claude to work on real files
A file opened directly by Claude in a connected folder is modified in place, not on an invisible copy you would find afterwards.
Skills and plugins, specialisation on demandPutting Claude to work on real files
A skill is a specialisation loaded to handle a specific domain, a plugin bundles several of them into a single installable package.
Connectors, a direct link to a piece of softwarePutting Claude to work on real files
A connector links Claude to an external service after explicit authorisation, and that authorisation holds beyond the current conversation, right up to scheduled tasks.
What calls for particular caution before having a document processedPersonal data, the mandatory caution
Identity, health and personal-situation data are protected categories, and a secret must never pass through a conversation, even briefly.
What the organisation account guarantees, and what it does not guaranteePersonal data, the mandatory caution
On an organisation account, Anthropic does not train its models on conversations, but the organisation remains solely responsible for the processing of the data it passes through it.
Handling a first real case from start to finishInto practice, and finding your own way
A deliverable produced by Claude is not settled until you have reread it yourself, an announcement of success or a document's clean appearance is never proof of substance.
The reference glossaryInto practice, and finding your own way
Nine words keep coming up in conversations about the tool: agent, token, context window, project, skill, plugin, connector, scheduled task, subprocessor.
Predicting the next word, nothing moreWhat a language model is, without the jargon
A language model does only one thing: predict the most probable fragment of text to follow what it has already read, and a made-up answer comes out of the same calculation as an accurate one, with no internal signal telling them apart.
The token and the window, what the model actually seesWhat a language model is, without the jargon
The model sees tokens stacked inside a window with a fixed ceiling, not whole words taken one by one, and a conversation approaching that ceiling changes content before it even reaches its maximum cost, since Claude then summarises the oldest exchanges.
The myth of the magic settingWhat a language model is, without the jargon
Two different answers to the same question do not signal a fault: they come from an internal setting, temperature, which adjusts the risk taken in choosing the next word, and this setting does not fix a poorly phrased request, the request itself can.
One family of models, a choice between speed and depthWhat a language model is, without the jargon
The models within the same family share the same base training and really only differ in the trade-off between how fast the answer comes and how deep the reasoning applied before answering goes.
Meaning without a dictionary, and why order mattersWhat a language model is, without the jargon
Claude opens no dictionary, it associates each word with words of similar meaning and weighs each one against all the others at the moment of answering, which means the place of an instruction in the message changes its real weight in the answer.
How Claude learned to answer, and up to whenWhat a language model is, without the jargon
Claude goes through three training stages before any conversation, a broad reading of the world, an adjustment into a useful assistant, then self correction grounded in written principles, and the resulting knowledge stops at a date that varies by model.
The three blocks of a requestWriting a request that works
A request that works separates three blocks, what Claude must be, what has already been said, and what is being asked now, and an explicit instruction gives a more reliable result than a vague instruction left to Claude's judgement.
Being clear, direct, and giving the whyWriting a request that works
Claude behaves like a brilliant new employee with no implicit context about your habits, so a request benefits from stating the why and who will read or hear the response, not just the task to carry out.
Assigning a roleWriting a request that works
A one-sentence role, placed at the start of a conversation or a project, shapes Claude's tone, vocabulary and priorities, and a single sentence is already enough to make that difference.
Separating data from instructionsWriting a request that works
Mixing instructions and data in a single block of text creates confusion, whereas a clear boundary, an XML tag, a heading, a code block or a marking line, removes it.
Formatting the output and speaking on Claude's behalfWriting a request that works
Specifying the exact format expected, down to explicitly forbidding any opening sentence, removes unnecessary preambles and malformed output, whereas the historical technique of writing the very first character of Claude's response yourself is no longer available on current models.
Making Claude reason before concludingWriting a request that works
Asking Claude to write out its reasoning before its conclusion improves accuracy on multi-step questions, whether that reasoning is invited by a sentence in the request or is already active as a standalone mode, and both versions consume extra tokens.
Showing the target rather than forbiddingWriting a request that works
Three to five input to output examples anchor a format or a tone better than a long list of rules, and a positive instruction gives a clear target where a purely negative instruction leaves Claude guessing what to replace it with.
Composing a complex request without inventingWriting a request that works
A complex request is composed piece by piece, who Claude should be, the context, the data to process, what is being asked, an example, the expected format, then a final line that allows Claude to say I do not know rather than invent an answer.
Making a working request last and reusing itWriting a request that works
A request that works is refined in small touches rather than started over from scratch, and then fixed into a reusable template where only the part that changes from one task to the next gets replaced.
A green result proves nothing until it has itself been provenChecking what it gives back
A check that has never been made to fail by a case it is actually supposed to catch has proven nothing, in the strict sense that proving requires a precise command to have run and its output to have been read: a broken detector returns zero problems, and that reads exactly like a success.
Test the checker before trusting its verdictChecking what it gives back
A check that returns a plausible number is not the same thing as a check that returns a correct number, and a faulty check rarely fails loudly, it returns a result that looks right.
The remedy against invention can invent tooChecking what it gives back
A verification device is a deliverable like any other, produced by the same kind of mechanism as what it checks: replaying that mechanism a second time does not make it independent, only a genuinely different method proves it.
Where you look determines what you findChecking what it gives back
A review pointed at the latest change tells you where you looked, never where the defects actually are: without having examined the rest with the same care, no conclusion about the relative danger of recent code versus old code holds up.
A very rigorous review can still see nothingChecking what it gives back
The more disciplined a review method is, the more it gives the illusion of having covered everything, because it can only judge what already exists, never what is entirely missing.
Proven, or simply not yet refutedChecking what it gives back
Proven means a precise command has run and its output has been read; not yet refuted only means that nothing has caught a problem so far, a far weaker claim.
A form check never sees a false valueChecking what it gives back
An automated check measures form, encoding, the presence of a keyword, never truth, and validating a screenshot or an intermediate step never proves what the person will actually open.
Reopen every source before believing itChecking what it gives back
A research agent reports what an index shows, not what a live page contains today, and presents a dead link with the same confidence as a live one: any source meant to support a conclusion gets reopened before being cited.
Count the whole population, and name the measure for what it capturesChecking what it gives back
Measuring the few cases noticed by chance rather than the whole population produces a conclusion that is confident and yet wrong, and that same conclusion stays wrong if the name given to the result says something other than what the instrument actually captured.
Chaining promptsTechniques that change the result
Breaking a complex task into a chain of short prompts, where the output of one becomes the input of the next, makes each link verifiable on its own instead of judging a single opaque block.
Giving Claude handsTechniques that change the result
Tool use lets Claude request the execution of a function you have defined, but the model never executes anything itself: it is your application, or for some tools provided by Anthropic its own servers, that actually carries out the operation, and the clarity of the tool's description determines how accurate the arguments it sends are.
Composing a system prompt from several sourcesTechniques that change the result
Merging the best rules from several system prompts works like an ordinary piece of writing, provided each imported rule is rewritten for its own context rather than copied as is, and the rules already in force settle any conflict.
Citing sources and not beating about the bushTechniques that change the result
A useful citation fits in an inline bracket right after the sentence it proves, one source per bracket, with no separate section at the end of the message, and a direct answer states the fact instead of announcing it and then closing with a polite question.
Structured outputs and guardrailsTechniques that change the result
Forcing an exact schema on an output and checking that output before using it are two halves of the same reflex, one forces the form upstream, the other controls it downstream, and both matter more when the action that follows cannot be undone.
Checking a prompt the way you check a resultTechniques that change the result
An eval is a fixed set of tests that scores a prompt, and meta-prompting uses Claude to improve an existing prompt, but in both cases the result stays a draft to test, never a final answer.
Asking several times, and contradicting yourselfTechniques that change the result
Asking for several independent answers and keeping the majority filters out the noise of a single answer, and asking Claude to play devil's advocate against its own answer finds errors a single pass misses, provided you always run a final synthesis to sort the valid objections from the noise.
The model landscape, one family of predictorsChoosing your model and your tool
Claude, GPT, Gemini and open-weight models are all next-word predictors trained differently, and a prompt template written for one carries across to the others with barely any change.
Route by task, not by brandChoosing your model and your tool
Choosing a model is decided by the nature of the task, its stakes and its novelty, not by brand loyalty, and a more honest framing of a request often unlocks more than switching models does.
Composing a system prompt across several providersChoosing your model and your tool
When a prompt has to work across several providers, take each one's strongest rule, merge them without contradiction, and rules written by the prompt's owner generally outrank a provider's defaults, except when they would conflict with the safety limits that provider sets for itself.
Local model, custom-built, or simply a better promptChoosing your model and your tool
An open-weight model run locally involves no cost charged per call and sends no data outside, a custom-built model costs a lot to construct and is only worth it at very high volume or for a fixed format, and in the vast majority of cases a better-written prompt solves the problem faster than either.
Opening Cowork and setting up your first workspaceCowork, the digital colleague
Cowork is a desktop agent that requires a paid plan and, to reach your local files, the Claude Desktop application open and connected; a Cowork project groups together folders, instructions and a memory that belong to it alone.
What Cowork can reach, and what it must never touchCowork, the digital colleague
Cowork's access breaks down into three distinct layers, connected folders, direct use of your applications and screen, and an isolated network that blocks internal addresses by default; in all three cases, permanently deleting a file always asks for your confirmation.
Writing a brief Cowork can execute, then reading its plan before it startsCowork, the digital colleague
A good brief names a result, its source, its destination and the workspace concerned, as if for a colleague starting that same day; Cowork answers with a plan that needs reading, because a wrong assumption spotted before execution is corrected at no cost, spotted after it can mean undoing writes already made.
Choosing your approval level, step by stepCowork, the digital colleague
Cowork offers three approval modes, Manual which has you validate every action, Automatic which lets Claude review itself before acting, and No approval which no longer checks anything: permanently deleting a file stays confirmed in all three modes, a task can be stopped at any time, and on a Team or Enterprise account an administrator can remove Automatic mode from the selector.
Rebuilding a real spreadsheet or report, not a draft to fixCowork, the digital colleague
Cowork delivers finished files, a workbook with formulas that genuinely recalculate, a laid out slideshow, a formatted document, not just raw text to pick up from there: naming the exact structure expected or supplying a template to copy brings the result closer to what will actually be used, and a figure that displays correctly in a cell never proves that the formula which produced it is correct.
Connectors: what they actually read and writeCowork, the digital colleague
A connector's capabilities are checked service by service: as recorded on 2 September 2026, the Google Workspace Gmail connector can send, reply to and forward messages directly, with approval requested by default before each send, which on a Team or Enterprise plan an organisation owner can allow members to lift, while the Microsoft 365 connector for Outlook can also send, but only once an administrator of the account has switched on that capability for the whole organisation.
Scheduled task or Computer Use: the order Cowork triesCowork, the digital colleague
Cowork first tries a connector, then the browser built into the desktop application, then as a last resort direct control of the screen, always in that fixed order, including for a scheduled task that runs unsupervised.
Cowork everywhere, who can do what, and the trail left behindCowork, the digital colleague
Cowork moved from desktop only to web and mobile on 7 July 2026 and remains in beta on these two surfaces, with cloud sessions that keep running with no device switched on at all; on an Enterprise account, custom roles bound access team by team, and Cowork's activity turns up in a technical export, not in the chat transcript itself, except for a session running locally on the machine, whose history stays only on that computer.
Recipe: sorting your mail without ever sending anything by mistakeRecipes for everyday work
A prompt injection attack requires two conditions at once, reading untrusted content and being able to act on it: for mail, the real barrier is no longer an inability to send, it lies in the approval setting in force on your workspace, to be checked before trusting your own proofreading alone.
Recipe: turning scattered notes into a clean document or spreadsheetRecipes for everyday work
Cowork produces structured documents and spreadsheets with working formulas from raw notes: on a large batch, explicitly asking for a plan and then each section separately gives a more reliable result than a single big instruction launched over the whole folder.
Recipe: building a text in separate steps rather than in one goRecipes for everyday work
An important text is broken into named steps, each with a single role, an approved plan first, then the drafting, then aligning the tone as a step in its own right, then a reread handed to an editor role rather than a simple request to rewrite.
Recipe: organising the team's shared memory without duplicating itRecipes for everyday work
A good shared memory rests on four moves, gathering, spotting duplicates even when the wording differs, linking what belongs together, and finding things quickly through a light contents page rather than by searching the whole folder every time.
Recipe: producing the same document in several languages without it divergingRecipes for everyday work
A single locked source drives every translated version, and a consistency check then compares the figures and key terms between each language, so that a correction made in one version is not forgotten in the others.
Recipe: sharing a document as a single file that opens everywhereRecipes for everyday work
A document meant to be sent by email or messaging must fit into a single file with no external link or dependency, validated by reopening it offline before sending, so that it displays the same way for everyone without any installation.
Claude Code and the agent loopFundamentals and the agent loop
Claude Code chains reflection, a real tool call and reading the result in a loop until the goal is reached, it does not answer once like a chat.
CLAUDE.md, the project's memoryFundamentals and the agent loop
CLAUDE.md is read automatically at the start of every session on the repository where it sits, and its rules are read as context, with no guarantee of strict enforcement.
The essential slash commandsFundamentals and the agent loop
A small set of slash commands drives an entire Claude Code session, the project's memory, the conversation's context and the active extensions, without ever touching the repository's code.
Permissions and plan modeFundamentals and the agent loop
The permission mode decides which actions Claude Code carries out without asking, and since version 2.1.228, in an interactive terminal or VS Code session, the mode that greets a new session on the Pro, Max and Team plans is no longer default mode but auto mode, which acts broadly under the background watch of a second model.
Interrupting and redirecting mid-taskFundamentals and the agent loop
Esc interrupts the current turn, reflection or tool call, without losing the accumulated context, whereas Ctrl+C answers a different question and, pressed a second time when nothing is running, ends the Claude Code session itself.
Pointing to files with @Fundamentals and the agent loop
The @ symbol opens a menu that points to a real file or folder on disk, filters as you type, and clearly separates the moment a path is inserted into the message from the moment that message is sent.
Running shell commandsFundamentals and the agent loop
The Bash tool runs real commands on your machine, Claude reads the output actually produced to continue its reasoning, and a permission prompt appears before every new command.
Reading and approving a diffFundamentals and the agent loop
A diff is read line by line before being approved, and approval itself is now done through a menu of named options rather than a free keystroke.
The task list and the status lineFundamentals and the agent loop
On the most recent models, the task list stays empty by default, with Claude managing multi step work without exposing it, while a status line configured by a script shows the active model, the context window and the session cost live.
The map of a structured setupA structured installation
A Claude Code setup that holds up over time reads as a map of seven elements, the engine, the CLAUDE.md constitution, file based memory, the git transport, hooks, skills and the scheduled heartbeat, rather than as a pile of settings with no plan.
Installing, signing in and the first launchA structured installation
The native Claude Code installer updates itself, signing in happens through a Pro, Max, Team, Enterprise or Console subscription rather than an API key forgotten in the environment, and claude doctor returns a read only diagnosis before any fix.
The global CLAUDE.md, a constitutionA structured installation
The global CLAUDE.md now targets a length in lines rather than in kilobytes, and it does not override the other CLAUDE.md files by overwriting them: the four scopes, managed, user, project, local, are concatenated in the context from the broadest to the most specific.
Wiring file based memory to gitA structured installation
A memory folder versioned by git, with a private remote and a merge rule that keeps both contents rather than forcing one over the other, remains a technique to build yourself, distinct from the native automatic memory, which never leaves the local machine.
Hooks and heartbeatA structured installation
Lifecycle events trigger hooks on three distinct cadences, SessionStart and SessionEnd form the natural pair for automating the memory protocol, and nightly consolidation remains an operating system scheduled task you build yourself, not a Claude Code mechanism documented under that name.
Curating your skills and closing out the setupA structured installation
A skill is installed one at a time, against a need you have already encountered, never in a batch, and closing out the setup means proving each of the module's seven map elements with an executable action rather than assuming it is in place.
Skills: teaching Claude a workflowExtending: skills, MCP, subagents, hooks, plugins
A skill encapsulates a reproducible workflow in a SKILL.md file, invoked by an explicit slash command or by automatic matching on its description.
Creating a skill that is also a commandExtending: skills, MCP, subagents, hooks, plugins
A custom command and a skill are now the same mechanism: a .claude/commands/name.md file and a .claude/skills/name/SKILL.md folder both produce the /name command with the same behaviour, and for a personal or project skill, it is the folder's name, not the frontmatter's name field, that becomes the command's name.
Discovering, curating and stacking skillsExtending: skills, MCP, subagents, hooks, plugins
Skills are discovered in two public libraries maintained by Anthropic, and several skills declared for distinct needs can load together on the same task, but a poorly chosen description never triggers, whether alone or stacked.
MCP: the connection protocolExtending: skills, MCP, subagents, hooks, plugins
MCP is the open standard that connects Claude to external tools and data around three primitives: the tools it can call, the resources it can read, the reusable prompts it can offer.
Connecting an MCP server, and what changedExtending: skills, MCP, subagents, hooks, plugins
An MCP server connects via OAuth or a key, is verified with claude mcp list, and the protocol itself changed at its core on 28 July 2026, a fact independent of any Claude Code version.
Building your own MCP serverExtending: skills, MCP, subagents, hooks, plugins
A homemade MCP server launches as a child process over stdio transport, declares a JSON schema in inputSchema that the server itself must validate, and a precise description decides when Claude calls it.
Subagents: delegating in an isolated contextExtending: skills, MCP, subagents, hooks, plugins
A subagent handles a task in an isolated context window and returns only its conclusion, which keeps the main conversation clean and allows several to run in parallel.
Hooks: automating the lifecycleExtending: skills, MCP, subagents, hooks, plugins
A hook is an action the harness executes itself on a precise lifecycle event, never a preference entrusted to the model in the hope that it remembers.
Hook events, from trigger to messageExtending: skills, MCP, subagents, hooks, plugins
PreToolUse can prevent a call from happening, PostToolUse can only react after the fact, and a hook's decision travels through precise JSON fields, never a sentence written to standard output.
Plugins: bundling skills, hooks, MCP and agentsExtending: skills, MCP, subagents, hooks, plugins
A plugin bundles skills, hooks, MCP servers and commands into a single versioned directory, installable and shareable in one go, with a single manifest that lives apart from everything else.
settings.json in depthExtending: skills, MCP, subagents, hooks, plugins
Five levels of settings.json follow one another from strongest to weakest, a scalar key common to two files is decided by the highest-priority level, but most lists, including permissions.allow and permissions.deny, merge across levels instead of overwriting each other.
Skill routing fails silentlyExtending: skills, MCP, subagents, hooks, plugins
Claude decides whether to invoke a skill by comparing the request's vocabulary against that skill's description field alone, and a mismatch of language or jargon between the two causes automatic invocation to fail with no visible signal in the response.
Debugging and fixing a bugEveryday moves
A precise reproduction command and a complete stack trace steer the diagnosis towards the real cause of a bug, and the fix is only declared closed once a regression test reproducing the faulty case has been run and its output read.
Building and refactoring with tests firstEveryday moves
Claude Code examines the test files already present in a project to write a new test in the same style before the implementation, and confirming that this test genuinely fails proves it does indeed test something that does not exist yet.
Reviewing code and driving git in natural languageEveryday moves
Local code review through /code-review offers five effort levels from low to max, and ultra is not a sixth level of the same scale but a distinct facility, a multi agent review in the cloud billed separately.
Getting to grips with, documenting and migrating a codebaseEveryday moves
On an unfamiliar repository, asking for an overview before making any changes shapes the questions that follow, and the /init command actually reads the project's content to write a first CLAUDE.md rather than starting from a blank page.
Automating a repetitive task and writing a throwaway scriptEveryday moves
Automating a repeated action starts with separating what stays fixed from what varies each time, is described by its input, its output and the environment it must run in, and is checked with a dry run before any step that deletes, moves or overwrites anything.
Quick terminal movesEveryday moves
A handful of short moves cover most of a day to day session: resuming a specific session, going back to an earlier checkpoint, running a shell command without leaving the conversation, and asking for deeper reasoning for a single turn without changing the setting for the whole session.
Headless mode, output styles and background tasksEveryday moves
Headless mode runs Claude Code without an interactive interface using -p, --output-format determines whether the output stays plain text or becomes a JSON object a script can use, with the total cost included, and run_in_background lets a long command keep running without blocking the conversation.
Running in parallel: worktrees, model and fast modeEveryday moves
A git worktree isolates a parallel session on its own branch, and the --worktree flag now automates the whole thing, where previously only the manual git worktree add gesture existed.
Writing pitfalls: files, parallel edits and lost deliverablesEveryday moves
A success report written by a sub-agent proves nothing about the real state of files, since it starts in an isolated context with no access to what the main agent has already read or written, and the only reliable proof remains a diff checked afterwards, not the text of the report.
Loops, polluted context and restartingWhen things go wrong
The sign of a loop is the same failure message repeating, a saturated context is handled by a targeted compaction or a full clear, and starting over with a hand written summary of the decisions already made beats insisting inside a degraded conversation.
Undoing and recovering a changeWhen things go wrong
To undo Claude Code's last action within the current session, the checkpoint menu opened by /rewind now comes before Git, which remains necessary for everything this system does not track: a change made by a bash command, a sub-agent's background edit, or a file linked by a symbolic or hard link.
API errors and rate limitsWhen things go wrong
A call to the API can fail in several different ways: a 400 or 404 error most often signals a malformed request that must be corrected before any retry, except for the special case of a 400 returned for a spending cap that has been reached, whereas a 429 error only resolves itself by waiting if it carries a Retry-After header, which is not the case for a spending cap that has been reached.
A stuck commandWhen things go wrong
A shell command that stops responding is cut off with Ctrl+C without closing the session, and the delay that switches it to a background task is already fixed by Claude itself, not by a prefix you add by hand.
Several sessions die together, suspect the machineWhen things go wrong
When several sessions die at the same instant with no trace whatsoever in their own logs, the likely cause is the operating system killing processes under memory pressure, and the system log settles the question faster than a hunt through application errors.
The request may rest on a false premiseWhen things go wrong
A request can describe the symptom accurately while getting the cause wrong, and carrying out that request to the letter then fixes nothing, or makes the situation worse.
Read the function called next, prove the culpritWhen things go wrong
A fix whose unit test goes green can be undone, within the same execution turn, by the function called right after it, and the already fixed function only becomes a proven culprit once a test has isolated its effect from that of the functions that follow.
The four levers of a long sessionContext and cost
A session that runs long rests on just four levers: the cache, which reuses a stable prefix, clearing out stale tool outputs, compaction, which summarises the history, and partitioning, which delegates bulky work to isolated sub agents.
Compacting, clearing, reading just what is neededContext and cost
The /compact command replaces the message history with a summary and carries on the same conversation, the /clear command wipes that history and starts from scratch, and in both cases the project files on disk do not move: the move that saves the most remains getting Claude to read only the relevant slice of a file.
Prompt cache and the Batch API, two discounts worth knowingContext and cost
The prompt cache charges reading of an identical prefix at around ten per cent of the normal input price, with a lifetime that depends on the offering, one hour for the main conversation of a paid subscription used within its plan, five minutes for an API key or a sub agent; the Batch API, for its part, processes a batch of requests asynchronously with a fifty per cent discount, on a separate rate limit quota.
The auto-compact threshold does not do what you thinkContext and cost
The auto-compact threshold triggers a summary of the conversation when the context reaches it, it is not a wall that closes the window: a value set above the real window of the active model is capped at that window, a documented behaviour whose lack of an on-screen warning still needs to be checked for yourself.
A context window does not follow the modelContext and cost
An extended window does not appear to carry over automatically from one model to another, a point the documentation does not settle explicitly: the size suffix should be retyped as a precaution at every model change through the /model command, except for two named models whose behaviour differs from the general case.
Where the bill really comes from, and why a token count liesContext and cost
The real cost of a session rarely hides where you look for it: a token count often confuses a reread at cache rate with a first read at full rate, a handful of marathon sessions carry most of the bill because the entire history is reread on every tool call, and any file loaded automatically at startup is paid for in full again at every compaction, not just once at the start.
Quota, throughput, and routing to the cheapest modelContext and cost
Two distinct caps govern a session, the money cost and the throughput in tokens per minute, and both are handled by the same reflex: route repetitive tasks to Haiku or Sonnet, keep Opus for difficult reasoning, and wait according to a growing delay after a 429 error rather than retrying at once.
File-based memory: basic structure and disciplinesThe second brain
Claude Code's memory lives in a folder of markdown files, one fact per file classified by a type field with four values, and a note that carries a single idea linked to at least one other stays findable within seconds rather than after a full reread.
Obsidian: wikilinks, content maps and memory typesThe second brain
The link written between double brackets weaves a network rather than a stack of folders, the content map that gathers them is a community practice and not a feature of the software, and a note of type user in Claude Code's automatic memory stays filed under its project by default, unless explicitly configured otherwise: the memories genuinely shared across all projects are the personal instructions file, user-level rules and the organisation-managed policy.
Querying a graph rather than rereading everythingThe second brain
A knowledge graph built once answers a question by walking explicit links, which costs noticeably fewer tokens than a full reread of the source files, a gap illustrated by a public example that carries its own caveat, and the same principle applies to an old session transcript, queried by levels before being reopened in full.
Dream and continuous learning: nightly consolidationThe second brain
A nightly memory consolidation is a personal automation built on top of a scheduled task, not a native Claude feature: it digests notes in four phases, orientation, collection, consolidation through merging and archiving, verification, and only a task that runs on the machine or in an open session can read a folder of notes stored locally.
A perishable figure in an always loaded fileThe second brain
A measured, expired fact cited as current is worse than no figure at all, because it keeps the appearance of authority while switching off the reflex to verify: the test fits in one question, would a change tomorrow be flagged to anyone, and if the answer is no, the figure has no business sitting in a file loaded on every conversation.
A shared vault has no concurrent editingThe second brain
A local file notes application locks nothing on a shared network drive: a public report documents a settings folder that gets overwritten between users on this kind of mount, and the same mechanism makes plausible, without the source itself documenting it, the silent loss of a note edit.
The assistant's journal mostly talks about the assistantThe second brain
A review of a large memory corpus kept by an agent shows that most entries document the agent's own mistakes, written by it, about itself, with almost no explicit instruction from the person it is supposedly profiling: it is like judging a pilot by the aircraft's maintenance log.
Fan-out, pipeline, barrier: choosing the architecture, or giving it upSeveral agents and adversarial checking
Fan-out launches independent agents in parallel behind a shared barrier, a pipeline lets each item pass through without a barrier and remains the default for multi-step work, a barrier is only justified when a step genuinely needs the full result of the previous one, and sometimes the right decision is to use no agent at all when a single call already suffices.
Isolating and running in the background: worktrees and the dry loopSeveral agents and adversarial checking
A git worktree per agent stops the files of several parallel agents from colliding, a dry loop repeats until a cycle no longer returns anything new, judged against an already seen set, and since 13 August 2026 a non teammate agent launched during an interactive session runs in the background by default with a notification at the end rather than blocking the session.
Making a large scale fan-out hold togetherSeveral agents and adversarial checking
A bulky deliverable handed to a single agent gets cut off by an output size limit with nothing written at all: split by axis, have each agent write to its own file, respect the documented cap of sixteen agents active at once and one thousand agents in total on a single run, a single call accepting up to 4,096 items that the runtime itself schedules under that cap, then verify by comparing the expected files against what actually exists on disk rather than taking the agents' word for it.
Deterministic workflows: schemas, checkpoints, resumptionSeveral agents and adversarial checking
A workflow is a script that orchestrates subagents deterministically, with output structured by a JSON schema and a checkpoint after every step, but the model applied to a relaunched agent follows a four tier priority order, and when the first three tiers are left empty, that agent falls back, as a last resort, on the model of the session running it, not the one that wrote the script.
Adversarial verification, judge panels and completeness criticsSeveral agents and adversarial checking
Three verification roles serve different angles and do not substitute for one another: the verifier subagent receives only the artefact to judge, the success criteria and the tools to check it, never the diagnosis or the history of whoever built it, and its silence is only legitimate if it genuinely searched and found nothing, since the default bias facing doubt leans towards rejection; a panel comparing several scored solutions is a widespread industry practice, not a pattern Anthropic names; and a completeness critic, a pattern documented under that exact name, looks exclusively for what is missing against the brief, never for errors in what was delivered.
Multiplying agents can multiply the errorSeveral agents and adversarial checking
A study testing five agent architectures on 260 configurations measures an error rate amplified to around seventeen times that of a single agent when independent agents work without a coordinator validating their outputs, against around four times when a coordinator does validate them, and on a strictly sequential task, all four multi-agent architectures tested fall behind a single agent.
An unverified premise in a prompt comes back as a conclusionSeveral agents and adversarial checking
The framing text an orchestrator writes into each agent's prompt stays invisible to adversarial review, which receives the produced artefact and the success criteria, never the intent or the history of whoever built the task: a false claim slipped into that framing therefore travels through the whole chain untested, and a fan-out that sends the same framing to several agents multiplies this exposure instead of diluting it.
Three failure states, and accepting a risk properlySeveral agents and adversarial checking
An automation that processes a queue should distinguish success, recoverable failure that will be retried, and definitive failure that is abandoned, and only the third should reach a person, otherwise every recoverable failure wears out the value of the alert on the day it is right; accepting a risk with a compensating control differs from ignoring it, a snapshot taken before execution allowing the result to be sorted into three paths, silent normal variation, a significant change that only alerts, catastrophic loss that restores automatically.
Secrets: never let them pass through, never display them in the clearSecurity and data
A secret pasted into a conversation, even briefly, stays present afterwards in the logs and in any automatic review of the history, and a configuration command run for one precise purpose can display a neighbouring secret in the clear if its filter is too broad.
A committed secret is burned: rotate it now, never by the dateSecurity and data
A secret tracked by a repository is treated as compromised from the moment it is written, not when someone proves it has been read, and the fix that reaches every copy is to rotate the identifier, with history rewriting coming second and not always necessary.
Pseudonymous and anonymous are two different thingsSecurity and data
A reference number used in place of a name remains personal data as long as a correspondence table exists somewhere, which can make the recipient a processor depending on its actual role rather than a simple case of anonymisation, and a pseudonymous identity on a repository needs its own local configuration.
Auditing a skill before installing itSecurity and data
A dated study found a security flaw in more than a third of a large sample of third-party skills, and the vast majority of confirmed malicious cases went through a hidden instruction, and two real vulnerabilities let a malicious repository execute before any confirmation at all, which leaves quarantine, full reading and systematic scanning as the only reliable protocol.
What an agent can leak without being asked toSecurity and data
An indirect prompt injection hides an instruction inside content the agent reads rather than in what you typed, a generated file has no author who stands behind its content, and a configuration rule that targets a file path is accepted without error while blocking nothing for the tool that runs direct commands, whereas a rule that targets that tool's name blocks it for real.
Responsible automation: reversible first, failure reported, fix requestedSecurity and data
An irreversible action waits for a human checkpoint before executing, but this checkpoint is automatic only in the Manual permission mode, the most cautious of the six documented modes: on paid plans a session nonetheless starts in auto mode by default, and several of these modes approve file commands inside the working folder in advance, deletion included, which shifts responsibility for the checkpoint onto whoever designs the automation.
What leaves the machine, what gets archived, what never gets sharedSecurity and data
A request sends the prompt text and the model's responses over the network, encrypted in transit, and the local copy of that exchange then stays readable in plain text on disk for a duration fixed by default; deleting a file leaves no way back, whereas archiving it keeps it available and reversible; and an internal document rich in detail becomes dangerous the moment it leaves, for the very reason that makes it useful internally, which calls for a raw inventory followed by an adversarial re-read before any sending.
The request, a single point of entryThe Claude API for builders
Every interaction with Claude goes through a single HTTP entry point, the POST /v1/messages request, which receives an array of turns and always returns the same response structure.
Roles that hold, not a prefill that breaksThe Claude API for builders
Prefilling the assistant turn, a practice that used to start Claude's response in its place, is now rejected with a 400 error on current models; a stable system instruction or a constrained output replace it.
Tools: Claude proposes, the code decidesThe Claude API for builders
A tool is declared with a schema named input_schema; Claude never executes it itself, it returns a usage request that the code executes before returning the result so the conversation can continue.
Receiving the response as it streamsThe Claude API for builders
Streaming mode keeps a single HTTP connection open and delivers text in fragments as it is generated, and the cumulative token count is read in the last message_delta event received, never in the final message_stop event.
Two cost levers: cached memory and batch processingThe Claude API for builders
A request prefix marked as reusable costs a reduced fraction of the normal price when read back from the cache, and a set of non-urgent requests processed in a batch costs less than immediate processing, two discounts that stack with each other and with the other pricing modifiers.
Counting before sending: the context windowThe Claude API for builders
A dedicated counting endpoint returns the number of tokens in a request before it is sent, and the context window to compare against this figure is no longer one shared value across a whole model range, it now varies sharply from one family to another.
Choosing a model, switching models, and handling a refusalThe Claude API for builders
The choice of a model is a trade-off between quality, speed and cost that gets revisited with every new generation, and a refusal returned by a safety classifier is handled as a normal case of the protocol, not as a failure.
Content pipeline, from brief to shareable deliverableReal cases end to end
A reliable content pipeline separates six roles, each with a single task, from the validated brief to the single HTML file that can be checked offline, and mixing two of these roles in the same pass loses control.
Building a data asset, synthetic dataset or knowledge baseReal cases end to end
A synthetic training dataset and an internal knowledge base share the same four-operation architecture, a shared schema, a matching identifier, deduplication and validation before any downstream use.
Fan-out research, with adversarial verificationReal cases end to end
Launching several searches in parallel rather than in sequence speeds up the enquiry, but a claim is only cited after it has withstood a genuine attempt to refute it.
Verify before believing, four real trapsReal cases end to end
A report written by a third party's agent, a paid skill sold as a bundle of features, a data connector announced as synced, and a competitor's page displaying a missing feature share the same flaw: each replaces a direct measurement with a claim that would need checking before being cited.
A mobile application from end to endReal cases end to end
A scaffold, the starting structure automatically generated for an application, navigation between screens, a network call and a correction of the types flagged by errors can all be chained within a single work session, with a preview that updates on your own phone at every change.
Automating your own practice, stack and skillReal cases end to end
A scriptable call with no interface, lifecycle triggers and distilled memory form a stack that keeps working on its own, and a move repeated a third time deserves to become a named command.
Making your site readable by AIs, citation and agentic navigationReal cases end to end
Being cited by a conversational assistant and being usable by a navigating agent are two distinct requirements, one plays out off the site on reliable mentions, the other plays out on the page itself.
Warm-up, assembling a prompt and ticking your checklistWorkshop, capstone and exam
Rebuilding a complete prompt from memory and ticking your own practitioner's checklist before any project reveals the reflexes still missing, where rereading an example would only test reading.
Placing yourself, from beginner to expert, before choosing your projectWorkshop, capstone and exam
Four levels of autonomy, a Project fitted with instructions, a Claude Code session framed by a configuration file, a homemade skill, a linked and consolidated memory folder, show which of the three end of course projects matches your own level.
The capstone, three real projects to choose fromWorkshop, capstone and exam
Shipping a small real feature, building your own second brain linked through files, or setting up a content pipeline from brief to publication are three projects of equal demand, only one is needed to pass the course.
Advanced capstone, the multi agent adversarial reviewWorkshop, capstone and exam
An orchestrator that distributes narrow roles to several reviewers in parallel, a step that blocks incomplete outputs, then a synthesis that surfaces conflicts rather than smoothing them over, produce a more reliable review than a single reviewer.
The graduation checklist, the final examWorkshop, capstone and exam
A written self assessment reveals gaps that a simple reread does not show, and both model choice and agentic loops with checkpoints mark the line between practitioner and beginner.