Claude Code has changed: 15 new concepts, from the model cache to cloud sessions

If you switch from Opus to Haiku in Claude Code for an easy question, thinking you’ll save tokens, you are most likely spending more. The reason is the cache: every model has its own, so the model that takes over has to reread the whole conversation at full price. For an easy question, keep the model and lower the effort with /effort low.

That’s only the first of 15 habits that were right at the start of 2026 and today make you spend more or get worse results. Claude Code has changed so much this year that it’s worth reviewing all of them, one by one:

1. Switching models mid-task costs more.
2. Higher effort doesn’t guarantee better results.
3. Prompts for Opus 5.5 are written differently.
4. A 1 million token context shouldn’t be filled up.
5. Projects became one chat that coordinates many tasks.
6. Plan mode is needed less and less.
7. Skills should shrink to the corrections only.
8. /goal can tell you it’s done when it isn’t.
9. Besides subagents, there are now forks.
10. With the advisor, one model asks another for advice.
11. Dynamic workflows run many agents in parallel.
12. Hooks can be written in plain words.
13. Routines start on their own, even from an event.
14. The usage limit no longer stops the work.
15. Cloud sessions keep running with your computer off.

1. Why does switching models in Claude Code cost more?

Switching models costs more because every model has its own cache. Every time you send a message, Claude rereads the whole conversation from the start, including the files it opened and the instructions you gave it. So you don’t pay full price every time, Claude keeps the part it has already read in a temporary memory, the cache. Reading from the cache costs much less.

The problem starts when you switch models. If after an hour of chatting with Opus you move to Haiku, Haiku has never read that conversation: it has to reread all of it at full price. And when you go back to Opus, Opus has to reread everything that happened in the meantime.

There’s a second reason. A small model often needs more attempts and more corrections to reach the same result. Every attempt is more tokens. Add it all up, and with Haiku you can spend more than if you had stayed on Opus 5.5.

Anthropic’s guide to choosing a model says it explicitly: most workloads start with Opus 5.5, and tuning effort is often a better lever than switching models. My rule is simple: pick the model at the start of the chat and keep it until the end.

2. Should you turn effort all the way up?

No: with Opus 5.5, higher effort doesn’t guarantee a better result. It’s tempting to turn it up, because more reasoning sounds like more accurate answers. But if you open the /effort menu in Claude Code, next to the max level it says it can use excessive tokens, respond slowly and overthink.

On Opus 5.5 the default level is medium, and that’s where Anthropic recommends starting. Addy Osmani’s guide to Opus 5.5 also quotes a tester who saw Opus 5.5 at its lowest effort catch more bugs than Opus 5 at high effort.

So when you have a simple question, don’t switch models: type /effort low. The cache stays, the model stays, and you spend less. Once the question is answered, set effort back to where it was, usually medium.

3. How do you write a prompt for Opus 5.5?

A prompt for Opus 5.5 says what you want, when the work is done, when to stop and ask, and what you don’t want. The advice comes from the guide Addy Osmani published on the Claude blog. Take this prompt, which worked perfectly well a few months ago:

Think carefully, step by step.
Build me a page to book appointments at my studio.

Today I’d rewrite it like this:

Build me a page where clients book an appointment at my studio.
Done means: I pick a day and time, a confirmation email arrives,
and two people can't book the same slot.
Test it yourself before telling me it works.
Stop and ask me only if you're missing information.
No cream background, no pill-shaped buttons.

There are four changes:

• I removed "think carefully, step by step". According to the guide, these instructions are no longer needed: Opus 5.5 always thinks before replying and decides how much on its own.
• I gave it a precise finish line. This is the most important change. Instead of letting the model decide when the work is done, I write it in the prompt. It works like the /goal command, which I cover further down.
• I told it when to stop and ask. Opus 5.5 works on its own for longer, so it pays to spell out when it should stop and ask you questions.
• I told it what I don’t want. Writing just "make it look nice" isn’t enough: a precise list of styles to avoid works better.

I wrote a full article on these 4 prompt changes for Opus 5.5.

4. Should you use the whole 1 million token context?

No. Sonnet and Opus now have a 1 million token context window, but the more tokens you put in the context, the less precise the model becomes. Anthropic measured it with a test where Opus 4.6 had to find 8 pieces of information hidden in a long text: at 256 thousand tokens it found them 93% of the time, at 1 million only 76% (Claude Opus 4.6 announcement).

The first place to fix is usually the CLAUDE.md file. It often holds non-essential information that Claude carries into every session. Move it into separate files, for example inside a docs folder, and leave only the path in CLAUDE.md. That way Claude opens the file only when it actually needs it.

One detail matters: write the reference without the @ sign. With @docs/prezzi.md Claude Code includes the file’s content at every startup and you save nothing. With docs/prezzi.md Claude opens it only when needed.

The second tip comes from Osmani’s guide again, and it’s meant for long tasks. Since Opus 5.5 works on its own for a long time, the context window slowly fills up. For tasks you know will take a while, add this sentence at the end of the prompt:

Keep a checklist in TASKS.md. Tick each item when it’s done and add anything you discover along the way.

This way, when the context fills up, Claude Code forgets nothing: everything it needs is written in the file. To see how much context you’re using there’s the /context command, which shows, among other entries, "Memory files", meaning your CLAUDE.md.

5. How do the new Claude Code projects work?

Since September 17, a Claude Code project is a single chat that acts as a team lead and coordinates many independent tasks. Before, projects were just chats grouped in a folder, and each chat stood on its own. Now the agents work autonomously and report everything back to the main chat, which therefore knows everything that happens in the project.

There are two things to know. First: since a project runs several threads in parallel, it uses a lot more tokens than a normal session. Anthropic explains that each thread is a full Claude Code session, and that model and effort can be chosen for both the main chat and the threads. Second: the new projects are still in beta, so they can have rough edges and bugs.

6. Is plan mode still useful?

Plan mode is needed less and less. Boris Cherny, who created Claude Code, wrote on Hacker News that plan mode was useful and no longer is, because the new models don’t need it anymore. I haven’t used it in months, and things work better, not worse.

Plan mode is still useful for two things:

• questions: in plan mode Claude Code asks you a lot of questions before starting;
• read-only mode: until you give the go-ahead, Claude doesn’t modify files.

For questions I found an alternative. I run a brainstorming session and write to Claude Code: "Ask me every question you have until everything is clear, one at a time." I answer one question after another, and without plan mode I haven’t noticed any difference. I suggest you try it.

Plan mode is still there, though, and it really looked like it would be removed. On September 23 Thariq, who works on the Claude Code team, wrote on X that they were thinking of killing it and using shift+tab to adjust effort. In his view the models don’t need it anymore, and he asked plan mode diehards to explain why they still use it.

The next day, after reading the replies, he changed the plan:

lots feedback here, many of you are planning yourself & don’t need plan mode

others prefer the UX of entering a mode where Claude is just thinking & brainstorming with you

my plan is to: make plan mode into a built-in mod; allow mods to add new modes or override shift+tab

So plan mode will stay, as a built-in mod, and mods will be able to add new modes or change what shift+tab does. If it makes you feel safer, you can keep using it.

7. How do you write a skill today?

Today a skill contains only the corrections for the mistakes Claude makes without it. At the start of the year a skill was a complete procedure, with every instruction written out so the agent could carry out a task. Now the models can do many of those tasks on their own. Anthropic’s advice is to let Claude Code try the task without a skill, watch how it does it, and create the skill only to correct the mistakes.

A public test on GitHub confirms it: the skill-placebo repository. It compared 9 of the most popular skill packs with a same-length "placebo" file, on Claude Code with Opus 5.5. In 7 cases out of 9 the skill did no better than the placebo: 6 tied, one did worse. Only 2 beat the placebo.

This doesn’t mean deleting all your skills. It depends on what they contain:

• generic procedures: Claude already knows how to do them, and the skill matters less and less;
• your own procedures, specific to your business: there the skill is still useful.

To review the instructions you’ve already written there’s the /claude-api prompt-audit command. It audits your repository and tells you which skills you can delete or shorten, and how to trim your CLAUDE.md.

I ran it on one of my repositories. It checked AGENTS.md, every CLAUDE.md, the docs/agents/ folder and 5 skills, against Opus 5.5. It didn’t modify a single file: it produced a report and a diff with 17 proposed changes, one per issue, which you can also apply one at a time. It took less than 6 minutes.

The interesting part is what it found. No sentences written for older models, like "think step by step". The issues were almost all outdated information and files that contradict each other:

• a guide says there’s no CI, but the workflows are there;
• a file references another file that doesn’t exist;
• a guide mentions 3 files in a folder that holds 5;
• two opposite rules on the background color of the slides;
• a skill that repeats "read EVERY file" four times, in capitals.

It grouped the issues by confidence, high and medium. Some it only flagged, without proposing changes: for example a table missing from the list of protected tables, which it left alone because that list is a prohibition.

To create and measure a skill there’s skill-creator, released by Anthropic: it runs evals on the same request with and without the skill, and tells you whether the skill actually helps.

8. Why does /goal say it’s done when it isn’t?

/goal can declare a goal reached when it isn’t, because the check reads only the chat. When you run /goal you give it a goal to reach. To verify whether the goal has been reached, Claude Code doesn’t open the output: it rereads the conversation. If the goal is vague, like "the report is finished", it’s enough for Claude to write "I finished the report" and the goal counts as achieved.

That’s why the goal must be specific, meaning measurable. There are two ways:

• a number: for example "the page loads in under 100 milliseconds";
• a script that checks: a script with rules, which you can have Claude Code write. The result of the check ends up in the chat, and the goal becomes much more precise.

Here’s how I do it. First I ask Claude Code:

Write a check.sh script that checks that index.html exists and contains a form with a date field, a time field and a Book button.

Then I start the goal:

/goal the check.sh script passes and you show me the output; stop after 15 turns

Claude starts right away, no extra message needed. /goal with nothing after it shows where it stands, /goal clear removes the goal.

9. What’s the difference between a subagent and a fork?

A subagent starts from a blank page, a fork starts from a copy of the conversation. The subagent receives only a prompt and works on its own. The fork knows everything you’ve said to each other up to that point.

Here’s an example. I’ve had a conversation with Opus up to a certain point, and now there’s a task that needs all the previous context. Claude Code makes a fork: Opus works on the copy, and I keep working on the original.

Usually Claude Code decides on its own which one to use. If you want to launch them yourself, there are two commands:

• /subtask, for example /subtask find all the files that talk about pricing and summarize them: the result comes back to the main chat;
• /fork, for example /fork check whether the files contain contradicting information: it works in the background.

10. What is the Claude Code advisor?

The advisor makes two models work together: one does the work, the other gives advice. For example you work with Sonnet, type /advisor opus, and when needed Sonnet calls a second instance running Opus and asks it how to proceed.

In my tests I saw three things:

• it uses twice as much, because two models work on every consultation;
• on its own, Sonnet rarely calls it, even when the rule is written in CLAUDE.md;
• when asked in the prompt, it calls it: I write "Before reading or writing a file, call the advisor", and Sonnet consults Opus.

The feature has just come out and many things don’t work well yet. In some cases, though, it saves tokens.

11. What are dynamic workflows?

Dynamic workflows are how Claude Code runs many agents in parallel on the same task. You choose the number, based on your plan or, if you pay for the API, on how much you want to spend: 5, 10, 50, 100, 200 agents. The more agents you use, the more tokens you burn.

You turn them on with one word: write ultracode in the prompt. Claude Code generates a JavaScript script, split into steps, that calls subagents based on the task. For example:

ultracode: check all the files in this folder and find the broken links

There are four main architectures:

1. chain: one agent passes the result of its work to the next agent;
2. fan-out: several agents work in parallel and the result goes to a parent agent;
3. verification: one agent works and another checks. It’s my favorite;
4. loop: an agent works, the result is checked and it goes back to the agent until the result is convincing.

You can state the number of agents in words in the prompt, or set it in /config under "Dynamic workflow size". I also wrote about when you really need multiple agents.

12. How do you create a hook in plain words?

Today a Claude Code hook can be defined in plain words: instead of a script, another Claude chat checks the work that was done. Until recently hooks, the checks that always fire at a precise moment, could only be written as scripts.

You create the hook with a prompt. For example, you create a voce.md file with your tone rules (no exclamation marks, short sentences, address the reader informally) and write:

Add a stop hook of type agent to this project, with the Sonnet model, that reads voce.md and the files you modified, and sends you back to fix them if they don’t follow the rules.

From then on, if Claude writes a text that doesn’t follow voce.md, the hook stops it and tells it what’s wrong, and Claude fixes it. With /hooks you see it alongside the deterministic hooks from before.

13. What are Claude Code routines?

Routines start Claude Code on their own, even when your computer is off, because they run on Anthropic’s servers. They can start from an event: for example, a commit and push to GitHub can trigger a routine where Claude Code reviews the code you just pushed.

To create a routine, type /schedule, which in some versions is called /routines. Then you create the triggers on the source that generates the event, for example on GitHub.

14. What happens when you hit the usage limit?

When your plan reaches 100% usage, Claude Code pauses but then resumes the work on its own. Before, it stopped abruptly, halfway through the task.

The Claude Code documentation adds a few useful details. The session must stay open, because Claude Code waits there for the limit to reset. Automatic continue is on by default and you turn it off in /config under "Continue automatically at usage limit". And if a permission is needed in the meantime, Claude stops and waits for you, as always.

15. How do you use cloud sessions?

Cloud sessions are today the simplest way to run Claude Code autonomously without your PC being on. Everything runs on Anthropic’s cloud. From the terminal you start them with claude --cloud followed by what you want done, for example:

claude --cloud "Create a note.md file with 5 Instagram post ideas for a physiotherapy studio"

When you want to bring the session back to your computer, you use claude --teleport followed by the session code, which you’ll find in the "Resume with" line. So you start the work in the cloud, close your laptop, open it the next day and pick up where you left off.

Where should you start?

The change that saves the most is also the simplest: keep the same model for the whole chat and use /effort low for easy questions. Right after come a prompt with the finish line written out ("Done means…") and a shorter CLAUDE.md. The other new features, from forks to cloud sessions, make sense as your work grows. Pick one, try it on your next project and see how much it changes the way you work with Claude Code.

Clips from the video