DEV Community: Angélo Lima

I went looking for an IDE built for coding agents. I stayed with Orca.

Angélo Lima — Thu, 15 Oct 2026 14:34:06 +0000

IntelliJ and VS Code weren't designed to drive agents. Zed was, but I was missing everything around the editing. Six weeks with Orca, one worktree per session, scheduled tasks and a home-made plugin to keep an eye on the bill.

For years, my IDE was a settled question. IntelliJ at work, VS Code for everything else. Then agents showed up, and the question reopened without warning.

My days had changed. I write less code in a file and spend more time launching tasks, reading diffs, and answering an agent that is waiting for my go-ahead while another one works away in its corner. IntelliJ and VS Code weren't built for that. You bolt on a Claude Code plugin, a chat panel, an integrated terminal, and you end up juggling windows, branches and forgotten git stash entries.

Zed is a different story. It was designed for the agentic era: the Agent Client Protocol (ACP) to plug Claude Code, Codex or Gemini CLI straight into the editor, and since its 1.0 release in late April 2026, parallel agents each isolated in a worktree. It was the closest to what I was after. What I was missing sat around the editing: tasks that run without me on a schedule, a tool the agent itself can drive from the command line, and an easy way to extend it.

I tried quite a few things. Since mid-August I've been on Orca, and for the first time in a long while I don't feel like looking elsewhere.

In brief

What: Orca is an open-source (MIT) desktop development environment built to run several coding agents in parallel. Made by Stably AI, available on macOS, Windows and Linux.

The idea: every session gets its own git worktree, agent terminal and browser tab. Agents stop stepping on each other.

Supported agents: Claude Code, Codex, OpenCode, Cursor CLI, GitHub Copilot CLI, Gemini, and in practice any agent that runs in a terminal.

What sets it apart: an agent dashboard, scheduled automations, a CLI and skills the agent itself can use, a plugin system.

The catch: each worktree duplicates dependencies (disk, memory), and more agents in parallel means more tokens and more diffs to review.

What Orca is, in two sentences

Orca calls itself an "agent development environment". In practice, it's a desktop app where every task lives in a dedicated git worktree, with a terminal for the agent, a file editor, a diff viewer, a built-in browser, and access to GitHub pull requests (and Linear tickets).

The project is open source on GitHub, made by Stably AI, a San Francisco startup. It started in spring 2026 and gathered tens of thousands of stars within a few months, shipping releases almost daily. It's a young tool, and sometimes it shows. More on that below.

What Orca isn't: an agent. It has no model of its own. It orchestrates the ones you already use. For me that's mostly Claude Code, but nothing stops you from running another one in the next tab.

One worktree per session: the click

If I had to keep just one thing, it would be this.

A git worktree, for those who've never needed one, is a second working folder attached to the same repository but on another branch. Same history, separate files. I mentioned them in the article on Claude Code and Git workflows as a trick for advanced users. Orca has made them its foundation since the first commit: every new session creates its worktree, its branch, its terminal. Zed adopted the same approach for its parallel agents, which says a lot about the idea. In Orca it applies to any command-line agent and to several repositories at once.

The effect on how I work was immediate. Before, running two agents on the same project meant risking both editing the same file, or one reading code the other had half rewritten. So I didn't. I serialised. One task, wait, review, next.

Today I open a session to fix a bug, another for a dependency migration, a third to explore an idea I might throw away. Each moves forward on its own. When one is ready, I read the diff, push, open the PR, and delete the worktree. The others never noticed.

That's what I call multiplexing. Code doesn't come out of any single session faster, but nothing waits for the previous one to finish anymore. It works across projects too: three repositories, each with its sessions, in the same window.

The cost is real. Each worktree has its own node_modules (or equivalent), so disk fills up fast on a big project. A write-up by Margrop puts memory at about 2 GB per active agent, so around ten gigabytes for five agents in parallel. I haven't measured that precisely, but the order of magnitude feels right. Orca can push worktrees to a remote machine over SSH, which solves part of the problem.

The dashboard: who is waiting for what

Launching five sessions is easy. Knowing which one has been waiting for an answer for twenty minutes is another matter.

Orca shows the state of every agent: working, done, or blocked on a permission request. An overview gathers all sessions, with notifications when an agent needs you. It sounds minor. In practice, it's what makes parallelism sustainable. Without it, I kept making rounds of the terminals to check whether anyone had finished.

There's also a mobile app (iOS and Android) to follow agents and nudge them from your phone. Handy on the day a session needs approval while you're away from your desk.

Claude Code, Codex, or whatever you like

Orca doesn't impose an agent. It runs whatever works in a terminal: Claude Code, Codex, OpenCode, Cursor CLI, GitHub Copilot CLI, Gemini, and a long list of others. You can even send the same prompt to several different agents, each in its own worktree, and compare the results. Zed also lets you switch agents through ACP; Orca only needs a terminal, so an agent requires no specific integration to run in it.

That matters to me. I've spent enough time comparing tools (Claude Code, Cursor and Copilot, among others) to know none of them is final. I don't want my working environment to depend on a single vendor. With Orca, if another agent does better on some kind of task tomorrow, I add it in a tab. My habits, shortcuts and worktrees stay the same.

Scheduled tasks, or the agent that works on Monday morning

This is the feature I didn't expect and use the most.

Orca has an automation system: a prompt, an agent, a repository or worktree, and a schedule. The schedule accepts presets (hourly, daily, weekdays, weekly), a cron expression or an RRULE, with time zone support. You can also set a precheck, a small shell command that skips the run if it fails, so you don't burn tokens for nothing.

I have two running permanently.

Dependabot follow-up, once a week. Dependabot PRs pile up on my repositories. Individually they're trivial. Collectively nobody wants to deal with them. Now, every week, an agent goes through them, checks which pass CI and which break something, and prepares a summary of what can be merged as is and what deserves a closer look. I keep control of the merge. But the triage is done by the time I arrive.

Preparing the team daily. Every weekday morning, an agent gathers what moved since the day before: PRs opened and merged, pending reviews, tickets that changed state. I walk into the daily with a clear view instead of reconstructing yesterday from memory.

Here's what creating an automation looks like from the command line (repository name and prompt are examples):

orca automations create \
  --name "Weekly Dependabot" \
  --trigger "0 8 * * 1" \
  --timezone Europe/Paris \
  --prompt "List open Dependabot PRs, check their CI and summarise what can be merged" \
  --provider claude \
  --repo my-repo

Then orca automations list, run or edit to manage them. The UI does the same thing, with ready-made templates.

The CLI and skills: Claude Code handles the rest

This is where I understood Orca was designed by people who actually work with agents.

Everything the UI does is available through the orca CLI: create a worktree, read a terminal's output, send a command to another terminal, open a file, drive the built-in browser, manage automations. And Orca ships skills (in the sense of Claude Code skills) that teach the agent how to use that CLI. One command installs them:

npx skills add https://github.com/stablyai/orca --skill orca-cli --global

The upshot is that I hardly configure anything by hand anymore. I ask Claude Code to create the Dependabot automation, prepare three worktrees for a batch of tickets, or add a new project to Orca. It does it. What we used to set up through menus, we now describe in one sentence to an agent that has the tools to do it.

There are other skills for multi-agent orchestration (one agent handing work out to others), Linear, and driving iOS and Android emulators.

Plugins: I built one to track my usage

Last point, and the newest: Orca has a plugin system. It's still young (flagged experimental when it landed, and the repository issues show the API growing request by request), but it already lets you add panels, commands and shortcuts, and listen to application events.

I had a specific need. When you run many agents in parallel, usage goes up, and it goes up quietly. I'd already written about Claude Code billing, but I lacked a simple view of where the tokens were going.

So I built a plugin. It shows my usage per project and per model, with a monthly view, and surfaces the most expensive sessions. That last view is the one I check most. An exploration that was too vague, an agent looping on a test that won't pass: that kind of session jumps out at the top of the list, and it nudges you to frame your prompts better.

And like everything else, Claude Code wrote most of the plugin, from the documentation and the API Orca exposes.

What still gets in the way

I won't pretend it's all perfect.

The release pace. Releases almost every day are great for new features, less so for stability. You have to accept that the tool moves under your feet.

Resources. As mentioned above: disk, memory, and above all tokens. Five agents in parallel is potentially five times the usage. The tool makes parallelism easy. It doesn't make it free.

Review. More agents means more code produced, so more diffs to read. Orca helps (diff annotations, built-in PR review), but the bottleneck is me. If I don't review, I shouldn't merge.

The editor. Orca doesn't support VS Code extensions. For a big manual refactoring session, with the debugger and a language's full tooling, IntelliJ still has the edge. For me, that's become the exception.

Six weeks later

What changed, deep down, is the shape of my workstation. It's no longer organised around an open file. It's organised around tasks in progress, each in its own box, with someone (something) working on it while I do something else.

IntelliJ and VS Code remain excellent editors, designed around someone who writes code. Zed has made the move to agents, and made it well. Orca starts directly from someone who puts agents to work, schedules them, watches them and reviews what they produce. That's what I do most of the time now, and that's why I stayed.

If you want to try it: it's free, installs in a few minutes from onorca.dev, and your current agents work in it as they are. Start with two parallel sessions on a project you know well. You'll quickly see whether it clicks.

Frequently asked questions

What is Orca?

Orca is an open-source (MIT) desktop development environment built to run several coding agents in parallel. Each task gets its own git worktree, agent terminal and browser tab. It is made by Stably AI and runs on macOS, Windows and Linux.

Is Orca free?

Yes. Orca is free and open source under the MIT license. The agents you run inside it are billed separately under their own model: an Anthropic subscription or API key for Claude Code, OpenAI for Codex, and so on.

Does Orca work with Claude Code?

Yes. Orca runs any command-line agent in a terminal: Claude Code, Codex, OpenCode, Cursor CLI, GitHub Copilot CLI, Gemini and more. You can even run several different agents on the same task, each in its own worktree.

Why does Orca use git worktrees?

A git worktree is a second working directory attached to the same repository, on a different branch. By giving each session its own worktree, Orca stops two agents from editing the same files at the same time: each works in its own folder, and changes are merged later through a pull request.

What is the difference between Orca and Zed?

Zed is a fast code editor built for agents: it integrates Claude Code and others through the Agent Client Protocol (ACP) and, since its 1.0 release (April 2026), runs parallel agents in git worktrees. Orca is an environment built around orchestration: it runs any terminal agent and adds scheduled automations, a CLI agents can drive, and a plugin system.

Can Orca run recurring scheduled tasks?

Yes. Orca automations launch an agent with a given prompt on a schedule (hourly, daily, weekdays, weekly, a cron expression or an RRULE), against a specific repository or worktree. They can be created from the UI or with the orca automations create command.

Originally published on angelo-lima.fr.

AI and ecology in 2026: the prompt is light, the infrastructure is heavy

Angélo Lima — Thu, 15 Oct 2026 14:33:47 +0000

A prompt uses 0.24 Wh. Data centers could use as much electricity as Japan by 2030. The October 2026 numbers, without doom or greenwashing.

A prompt uses less energy than an LED bulb left on for two minutes. And yet AI is becoming a real burden on power grids and water resources. Both sentences are true. That is the whole problem.

In 2025 I wrote a post on the ecological cost of AI. The question that framed the debate back then: what weighs more, training a model or using it?

A year and a half later, that question is largely settled. The cost of a single prompt stopped being contentious once the big AI companies published measurements. The argument is now about total volume, about water, about hardware, and about what agents are going to do with all of it.

So is AI an environmental burden, true or false? I went through the numbers available in October 2026 to find out.

In brief

One prompt: 0.24 Wh, 0.03 g of CO₂e and 0.26 mL of water for a median Gemini text request (Google, 2025). About 0.34 Wh in ChatGPT according to OpenAI.

Data centers: 448 TWh in 2025, 945 TWh projected for 2030, roughly Japan (United Nations University, June 2026).

The paradox: energy per AI task drops nearly tenfold every year, yet data center demand grew 17% in 2025.

The blind spot: water (consumption doubling by 2030) and chip manufacturing, which dominates several impact categories of a GPU.

The verdict: false at the individual level, true at the collective level, especially true at the local level.

The prompt, a featherweight

A standard text prompt now uses between 0.24 and 0.34 Wh. That is the first big change since 2025: these figures are measured.

Google instrumented its infrastructure for a year. The median text request in Gemini uses 0.24 Wh, emits 0.03 g of CO₂e and consumes 0.26 mL of water (source). Over the same period Google reports a 33-fold drop in energy per prompt.
OpenAI reports about 0.34 Wh for an average ChatGPT request.
Mistral published a full life-cycle assessment of Mistral Large 2, server manufacturing included, following the French AFNOR frugal AI framework, with ADEME and Carbone 4 (source).

These figures demolish the shock comparisons that were going around two years ago, like "a bottle of water per request". A 2023 study estimated 10 to 50 mL of water per prompt for GPT-3, 40 to 200 times more than Google's measurement (source).

They still need to be read carefully. Google gives a median rather than a mean, says nothing about prompt length or complexity, and only covers the Gemini app. Google's and OpenAI's numbers are not directly comparable (source). They are orders of magnitude and should be read as such.

A prompt next to everyday objects

For everyday use, an electric car or an air fryer uses far more than a chatbot. Twenty minutes of air frying is worth about 2,000 text prompts, a 10 km drive in a compact EV about 7,000, and the same drive in a large electric SUV over 10,000.

Three caveats keep this from being the end of the story:

Not all prompts are equal. A long reasoning prompt already uses more than two smartphone charges. A heavy agentic task can be worth several kilometres in an EV.
Look at what each use replaces. The EV replaces a petrol car, the air fryer often replaces an oven: both can lower the overall footprint. A good share of AI use is added on top without replacing anything.
Only usage electricity is counted here. Manufacturing a car battery or data center GPUs changes the picture, as we will see.

The paradox: each task costs less, the total explodes

In 2025, data center electricity demand grew by 17%, against 3% for global electricity demand. Over the same period, energy per AI task dropped nearly tenfold each year (source).

This is an almost perfect Jevons paradox. When a resource gets cheaper to use, we use so much more of it that total consumption rises. There are more users, and each of them runs heavier tasks, like agents or reasoning models.

The projections all point the same way, towards a doubling by the end of the decade (UN, Gartner).

And that electricity is not clean: according to the IEA, about 40% of the additional data center consumption through 2030 will still be met by gas and coal (source).

The impact is also highly concentrated. Data centers already account for more than 20% of Ireland's electricity, against 2 to 3% on average in the EU (source). AI will not bring down the global grid. It can saturate a local one.

Beyond carbon: water, hardware, waste

Carbon is only part of the impact, and probably not the most worrying part. Kaveh Madani, lead author of the June 2026 UN report, says it plainly: the debate still treats AI as software, when it is a physical infrastructure made of power plants, chips, minerals, land and water (source).

Carbon: significant, not outsized. Data centers already emit as much CO₂ as Argentina (source). Against the roughly 37 billion tonnes emitted worldwide each year, that is around 0.5%, and AI is only part of it. Hyperscalers claim 92% of their energy comes from low-carbon sources, but partly through purchase agreements (source).

Water: the real hotspot. According to the UN, data center water consumption should more than double by 2030 (source). Over 21% of US data centers sit in basins with medium to high water stress (source). And the reported figures are underestimates: the water used by the power plants feeding them is reportedly about 12 times their direct consumption (source).

Manufacturing: the blind spot. A life-cycle assessment of the Nvidia A100 GPU shows that manufacturing dominates several impact categories over the whole life cycle, well beyond carbon alone (source). Cobalt, tungsten, lithium: each chip contains little, but demand is climbing fast.

E-waste. A high-end GPU can be outdated in under two years (source). Yet only 22% of e-waste is collected and recycled worldwide (source).

Agents push the cost per task back up

The training versus inference debate from my 2025 post is settled: more than 80% of AI's electricity use now comes from the usage phase (source). A model is trained once. It answers billions of times.

And usage is changing shape. A long advanced reasoning prompt can exceed 33 Wh, more than 130 times a standard text prompt (source). A coding agent that chains dozens of calls, rereads files, runs tests and starts over is another scale entirely.

This is where the "cost per token is falling" line becomes misleading. Cost per token is falling, yes. But the number of tokens per task is exploding. I see it every day working on an agentic platform: the number I track is the cost of a finished task. A single prompt tells you almost nothing. I reached the same conclusion with the Claude Code bill, where the whole session is what costs money.

So, environmental burden: true or false?

Both, depending on the scale you look at.

False at the individual level. Your prompt is not destroying the planet. Shaming someone for asking a chatbot a question while they drive to buy bread makes no sense.
True at the collective level. AI has become a significant and growing load on power grids, with a mix that is still largely fossil.
Especially true at the local level. Water, grid saturation and pushback from residents all play out where data centers are built.
Underestimated on the hardware side. Chip manufacturing and e-waste remain the big absentees from per-prompt figures.

The UN's wording seems the most accurate to me: AI will not exhaust water or electricity globally, but poorly planned expansion can collide with resources that are already under strain in specific places (source).

What developers and teams can do

The lever that matters most is sizing. Mistral's analysis shows that impact roughly tracks model size: a model ten times larger costs about ten times more for the same number of tokens (source).

Route to the right model. A small model to classify, summarise or extract, possibly running locally with Ollama. The big reasoning model only when the task calls for it.
Measure per task, not per prompt. Track tokens consumed per completed task, especially for agents.
Limit loops. Cap agent iterations, cache, avoid reloading the whole context on every call.
Choose where the compute runs. A cloud region with low-carbon electricity and little water stress genuinely changes the footprint.
Ask whether AI is needed at all. It is the first question in the AFNOR frugal AI framework (source). A regex is still cheaper than an LLM.

A prompt weighs nothing. A poorly sized agentic architecture, deployed to thousands of users, weighs a lot. And that architecture is designed by teams like mine.

Sources

Frequently asked questions

How much energy does an AI prompt use in 2026?

A standard text prompt uses between 0.24 and 0.34 Wh in 2026. Google measures 0.24 Wh, 0.03 g of CO₂e and 0.26 mL of water for the median text request in Gemini; OpenAI reports about 0.34 Wh for an average ChatGPT request. That is less than an LED bulb left on for two minutes.

Does a ChatGPT prompt use a bottle of water?

No. That comparison came from a 2023 study estimating 10 to 50 mL of water per prompt for GPT-3. The measurement Google published in 2025 gives 0.26 mL per median Gemini text request, 40 to 200 times less.

How much electricity do data centers use worldwide?

Data centers used about 448 TWh in 2025 according to United Nations University, and are projected to reach 945 TWh in 2030, roughly the consumption of Japan. Gartner estimates 565 TWh for 2026.

Is AI an environmental burden?

AI is not a burden at the individual level: a single prompt weighs very little. It becomes one at the collective level, with data center electricity demand set to double by 2030 on a grid mix that is still partly fossil, and above all at the local level, where data centers strain water and power grids.

How can developers reduce the environmental impact of AI?

The main lever is sizing: route each task to the smallest model that can handle it, measure tokens per completed task, cap agent loops and use caching. Choosing a cloud region with low-carbon electricity and low water stress also changes the footprint.

Originally published on angelo-lima.fr.

Kaizen: a complete SDLC for Claude Code, from requirement to production

Angélo Lima — Thu, 15 Oct 2026 14:33:41 +0000

A coding agent speeds everything up, mistakes included. Kaizen gives Claude Code a whole development lifecycle, with its critical rules enforced by code.

A coding agent writes fast. It also sometimes forgets the tests, or pushes a branch nobody reviewed. The DORA 2025 report measured it: AI raises team throughput, and instability along with it, except in teams that keep clear principles, small batches and real feedback.

Kaizen is the plugin I wrote to tool those disciplines in Claude Code, across the whole SDLC, from the requirement to production. It also answers the question I left open in April in my map of SDD, Compound Engineering and BMAD: can you combine the rigor of a spec with a learning loop?

In brief

What: Kaizen is an open source (MIT) Claude Code plugin covering the whole development lifecycle: requirements, plan, code, review, PR, deployment, monitoring, postmortem.

Key numbers: 23 skills, 21 read-only agents, 6 hooks, a Node.js CLI with no npm dependency. Version 3.2.1, October 7, 2026.

What sets it apart: the critical rules are hooks. Claude cannot finish on red tests, push without a real review, or deploy to production without a code you type.

Where it comes from: the loop of Every's Compound Engineering, the constitution from Spec Kit, practices from DORA and the NIST SSDF.

Who it's for: teams on Claude Code that want quality guarantees all the way to production.

The SDLC, phase by phase

Each classic phase of the cycle has its command. The last column says whether a check in code enforces it.

Phase	Command `/kaizen:…`	Enforced by code
Principles	`constitution`: 5 to 9 rules, each with a check	partly
Requirements	`brainstorm`: requirements R1…, acceptance examples AE1…	partly
Design	`plan` (STRIDE threats, rollback, PR-sized slices), then `doc-review`	partly: `plan check` verifies every requirement is covered
Code	`work` (test first), `debug`	yes: no end of turn on red tests
Verification	`review`, reviewers picked from the diff	yes: push refused without a real review
Delivery	`ship`, `watch-pr`, `release`	yes: PR size and SemVer checked
Deployment	`deploy` with your commands, rollback	yes: approval code for production
Operations	`monitor`: plan thresholds, dated incidents	partly
Improvement	`learn`, `postmortem`, `metrics` (DORA)	partly

Lost along the way? /kaizen:help looks at where the repository stands and gives the next command.

The critical rules are hooks

Writing "run the tests before finishing" in CLAUDE.md works nine times out of ten. The tenth time the session is long, the context compacted, and Claude reports that all is well over a red suite. So Kaizen puts those rules in hooks, which Claude Code runs on every tool call.

Before a commit, a scan refuses about thirty kinds of keys and tokens.
Before a push, the branch is refused until a review has been recorded, with proof that the reviewer agents really ran.
At the end of a turn, tests, lint and type checks must pass.
For production, only a code you type unlocks the deployment.

A loop that learns

This is what Compound Engineering brings. What a cycle learns (learnings, ADRs, postmortems) is written in the repository, and an agent reads it back before every plan, review or debugging session. Deployments, rollbacks and incidents become dated git tags, so the DORA metrics are computed from real events. /kaizen:metrics also separates learnings that were read from those applied in a commit. A learning nobody reuses signals a loop that isn't turning.

Ceremony is set by profile: lean for a prototype, standard for a product in production, full for a regulated domain. The checks in code stay on in all three.

Try it

/plugin marketplace add Lingelo/dojo
/plugin install kaizen@dojo

Kaizen is built for Claude Code and relies on its hooks. You need Node.js 18 or later, git, and gh for PRs. In your repository, run /kaizen:setup audit: it scores the project's SDLC maturity in five areas and offers to add what's missing. Code and docs are on GitHub. For how plugins work, see my article on Claude Code marketplaces.

Frequently asked questions

What is Kaizen for Claude Code?

Kaizen is an open source (MIT) plugin that gives Claude Code a complete SDLC: requirements, plan, test-first code, multi-agent review, pull request, watched deployment, incidents and learnings. It ships 23 skills, 21 read-only agents and a zero-dependency Node.js CLI. Version 3.2.1 was released on October 7, 2026.

What is an AI SDLC?

An SDLC (Software Development Life Cycle) is the set of phases that take software from a requirement to production: framing, design, code, verification, delivery, deployment, operations and improvement. An AI SDLC tools those phases for a coding agent, with checks suited to a fast executor that can forget an instruction.

How is Kaizen different from Compound Engineering?

Kaizen is derived from Every's Compound Engineering plugin (MIT) and keeps its learning loop. It adds checks enforced by hooks, Spec Kit's constitution, deployment, monitoring and DORA metrics. Kaizen is built for Claude Code and relies on its hooks.

How do I install Kaizen?

In Claude Code, add the marketplace with /plugin marketplace add Lingelo/dojo, then install the plugin with /plugin install kaizen@dojo. Kaizen needs Node.js 18 or later and git, plus gh for pull requests. In a repository, start with /kaizen:setup.

Can Kaizen deploy to production on its own?

No. Kaizen only deploys with the commands the team declared, and for a protected environment the user must type an approval code, valid for 30 minutes. Autopilot mode stops at a ready pull request and never merges or deploys.

Originally published on angelo-lima.fr.

Claude Code Cheat Sheet, October 2026: the complete state of play

Angélo Lima — Thu, 15 Oct 2026 14:33:34 +0000

All of Claude Code v2.1.296 on one page: 120 commands, 33 hooks, 243 settings, 391 environment variables

My fourth Claude Code cheat sheet in seven months, and the first one I didn't feel like calling an "update". Between June's v2.1.170 and October 9's v2.1.296, Anthropic shipped about 125 versions, including four new models and plugins that can redraw the interface. And the default permission mode changed its very nature. Adding badges to the June edition was no longer enough.

So this time I rebuilt the reference from scratch, from the official documentation downloaded page by page on October 13, and aimed for exhaustiveness in the strict sense: every command, every hook event, every flag, and in an appendix each of the 243 settings.json keys and 391 environment variables. The article that goes with it takes stock of what moved since June, and of what disappeared.

In brief

What: an exhaustive cheat sheet for Claude Code v2.1.296 (October 9, 2026), as interactive HTML, in English and French, checked against code.claude.com.

Key figures: ~120 built-in commands and skills, 33 hook events, 46 tools, 243 settings, 391 environment variables.

Models: Opus 5.5 is the default everywhere ($4 / $20 per MTok, medium effort), plus Sonnet 5.5, Haiku 5.5, and Fable 5.1 as an option for big jobs.

What changed in nature: auto mode became the default mode, subagents run in the background, and mods let you change Claude Code from the inside.

Why it matters: you now steer Claude Code by goals and delegate to background agents, instead of approving each command.

The cheat sheet

English: interactive HTML
Français : HTML interactif

Same palette as the previous ones (dark background, gold accent), with three badges: NEW for anything that wasn't in the June edition, CHANGED for anything whose behavior changed, REMOVED for anything that no longer exists. The page now renders properly on mobile, which the earlier editions didn't (they forced a fixed 1,400-pixel width).

What's covered

Section	Contents
What changed since June	Month-by-month timeline, June to October
Keyboard shortcuts	Essentials, navigation, readline editing, prefixes, transcript, agent view
Vim mode	Modes, navigation, editing, text objects
Models, effort and costs	The four 5.x models, aliases, effort levels, fast mode, advisor, fallbacks
Slash commands	Complete list in 9 categories, removed ones included
CLI	Subcommands (background sessions, plugins, purge, gateway…) and every flag
Permissions	6 modes, rule syntax, auto mode, sandbox
Hooks	All 33 events, the 5 handler types, common fields
Memory, skills, subagents	CLAUDE.md and AGENTS.md, full frontmatter, output styles
Plugins, mods and MCP	Plugin components, marketplaces, mods, MCP
Parallelism	Subagents, fork, agent view, agent teams, workflows, projects
Platforms	CLI, Desktop, web, self-hosted, mobile, IDEs, Chrome, Slack, CI/CD
Built-in tools	All 46 tools, deprecated ones included
Files and configuration	`.claude/` tree, precedence, key settings, status line, artifacts
Admin and enterprise	Model control, policies, versions, observability
Appendix	All 243 settings keys, 391 environment variables and 137 keybinding actions

State of play: where Claude Code stands in October 2026

Models: the 5.5 generation settles in

It was a busy summer. Sonnet 5 landed on July 2, Opus 5 on July 24, then the next generation: Fable 5.1 on September 1, Opus 5.5 on the 22nd, Sonnet 5.5 on the 28th, and Haiku 5.5 on October 7. In June I had to annotate the cheat sheet in a hurry after Fable 5 was suspended. The Fable family is back, and the fable alias now points to 5.1.

Model	ID	Price (input / output, per MTok)	Status
Fable 5.1	`claude-fable-5-1`	$10 / $50	Most capable, never the default
Opus 5.5	`claude-opus-5-5`	$4 / $20	Default on every plan and the API
Sonnet 5.5	`claude-sonnet-5-5`	$2 / $10	`sonnet` alias
Haiku 5.5	`claude-haiku-5-5`	$0.10 / $0.50	`haiku` alias

All of them have a native one-million-token context. Since v2.1.280, Opus is the default model on every plan, Pro and Team Standard included (they used to be on Sonnet). Default effort on the 5.5 models drops to medium, which the documentation recommends for well-scoped everyday work, and it is now saved per model. Finally, ultracode has become an independent toggle (/effort ultracode on) that plans a workflow for each substantive task, at any level.

On the safety side, recent models run with classifiers (cybersecurity, biology). A flagged request automatically switches to a fallback model depending on the category: Opus 4.8 for cyber, Opus 5 for bio. If you work on a security repository and see unexplained switches, switchModelsOnFlag makes Claude Code ask you first.

Auto mode is no longer optional

To me this is the most structural change of the period. In June, auto mode was a feature you turned on. On August 14 it became the default mode for new Pro, Max and Team sessions, and since v2.1.284 (September 28) it is the default for every interactive session on every plan and provider, unless permissions.defaultMode says otherwise.

The idea: a classifier evaluates each action instead of asking you to click. It now runs server-side by default, and its calls no longer count against your usage limits. It was hardened all summer: it blocks git reset --hard or git clean -fd when you didn't ask to throw work away, refuses terraform destroy without an explicit request, forbids access to cloud metadata endpoints, asks before the first read outside the working directory, and now names the rule behind a denial (for example [Data Exfiltration]). The /auto-mode-setup command drafts the autoMode.environment section that describes your trusted repositories and domains.

As a consequence, the old "default" mode is now called Manual, and bypassPermissions can no longer be turned on from a repository's settings. I covered the old model in the Permissions and security article. The rule syntax there still holds; what moved is the starting point.

Parallelism became the norm

In June, agent view had just arrived. Four months later, parallelism is everywhere, and the documentation now lists five distinct ways to get several agents working:

Subagents run in the background by default since July. They can nest three levels deep, twenty can run at once, and their permission requests surface in the main session. The frontmatter gains omitClaudeMd, autoCompactWindow and effort (see the subagents article for the basics).
Fork is on by default: a forked subagent inherits the whole conversation and the cache. /subtask starts one, and /fork now copies the entire session into a background session with its own worktree.
Agent view (claude agents, or ← on an empty prompt) gains search by name, the n: filter, classifier-written titles, and a link to the associated PR or GitLab MR.
Dynamic workflows orchestrate tens to hundreds of agents from a JavaScript script Claude writes. Saved in .claude/workflows/, they become commands.
Projects (Pro and Max beta) launch parallel cloud threads from a single conversation.

On top of that comes cross-session messaging (August): two Claude Code sessions on the same machine can write to each other through SendMessage, and @name in the prompt mentions another session.

Extending Claude Code: enter mods

Skills, subagents, hooks, MCP and plugins were already there. On October 1 (v2.1.287) a new layer arrived: mods. A mod is a plugin written in JavaScript or TypeScript that runs inside Claude Code. Where a hook launches an external script, a mod can draw a pane next to the transcript, add a band above the prompt, create a command that runs without a Claude turn, hold a tool call while it asks a question, or send a request to another model. Anthropic uses the mechanism for its own features too: the /diff panel is a mod.

The trade-off is spelled out in the docs: a mod runs with your permissions, reads your secrets, sees every prompt and can approve a tool call on your behalf. I would only install them from a marketplace I control.

Hooks keep growing as well: we're up to 33 events (from 27 in June), including DirectoryAdded, PreModelSwitch and PostModelSwitch. The new onFailure: "block" field (v2.1.295) closes a real gap for anyone relying on hooks as a safeguard: a security hook that crashes or times out now blocks the action instead of letting it through.

Other notable ecosystem additions: claude plugin eval to test a plugin against a run without it, /skill-doctor to spot skills that cost context without being used, syncing of the skills and plugins enabled on claude.ai, and AGENTS.md support when a project has no CLAUDE.md. /import codex, /import gemini and /import cursor bring over another agent's configuration.

Beyond the terminal

Claude Code lives less and less in the terminal alone:

Desktop comes to Linux in beta (Ubuntu 22.04+, Debian 12+), with a built-in browser, an iOS Simulator, background computer use on macOS, pop-out panes and automatic continuation after a usage limit. /resume there picks up sessions started from the CLI.
Artifacts publish interactive pages to claude.ai from the session, and can call your MCP connectors on every view.
Self-hosted environments run cloud sessions on the company's own infrastructure (Team and Enterprise beta).
Remote Control is out of preview, and the mobile app shows your machines as cards you can start a session on.
Claude in Chrome has been generally available since July.

Review and security

Four tools now complement each other. /code-review hunts bugs in a background agent, at five effort levels, and can comment on the PR or apply fixes. /simplify handles cleanup. /ultrareview sends a fleet of agents into the cloud. On the security side, the security-guidance plugin reviews each edit, and the Claude Security plugin (July) runs a full multi-agent scan with a threat model, then turns the findings you pick into patches to review. Finally, /verify and /run launch the application to see that a change actually works, beyond the tests.

On the enterprise side

Administrators got a lot of levers: deniedModels and availableModelsMatch: "exact" to block a model until it's approved, maxEffortLevel, allowedProviders, modelPricing to show costs at negotiated rates, managedMcpServers to hand out MCP servers, and the self-hosted Claude apps gateway (SSO, policies, spend limits) in front of Bedrock, Vertex or Foundry. A repository's settings can no longer turn on telemetry, Remote Control or Claude in Chrome: those now belong to the user or the admin.

What disappeared

Ultraplan (the /ultraplan command and keyword): removed in August.
/vim and /pr-comments: removed. Vim mode is set in /config.
The TodoWrite and Task* tools are no longer provided to recent models (CLAUDE_CODE_ENABLE_TODO_TOOLS=1 brings them back), and TaskOutput is gone.
Glob and Grep are absent by default on macOS, Linux and WSL: Claude uses find and grep, which actually run embedded versions of bfs and ugrep.
/agents no longer opens a wizard: ask Claude to create the agent, or edit .claude/agents/.

My takeaway

Back in December, in my 20-article series, Claude Code was a terminal assistant you watched command by command. In October, the tool is designed for you to hand it a goal (/goal), let it break the goal down, delegate to background agents, and let a classifier act as the guardrail. The user's job shifts toward defining the frame: rules, hooks, CLAUDE.md, spend limits. That is exactly the idea behind Kaizen, the Claude Code SDLC I presented last week: when the agent speeds everything up, critical rules have to be enforced by code.

The flip side is surface area. 243 settings and 391 environment variables is a lot, and part of this cheat sheet exists so you can find the right lever without rereading 220 documentation pages. /doctor and /skill-doctor go in the right direction by helping you remove what no longer serves.

Official sources: Changelog, What's new, Commands, CLI reference, Hooks reference, Model configuration, Mods overview, All settings, Environment variables.

Previous editions are still available: June EN · FR, April EN · FR, March EN · FR.

If you spot a mistake or something missing, let me know and I'll fix the cheat sheet.

Frequently asked questions

What is the latest version of Claude Code in October 2026?

As of October 13, 2026, the latest Claude Code version is v2.1.296, released on October 9, 2026. About 125 versions shipped between June 9 (v2.1.170) and October 9. Run claude --version to see the installed version and claude update to upgrade.

Which model does Claude Code use by default in October 2026?

Since v2.1.280 (September 22, 2026), Claude Code uses Claude Opus 5.5 by default on the Pro, Max, Team and Enterprise plans and on the Anthropic API, at medium effort. Fable 5.1, the most capable model, is never the default: select it with /model fable.

What is Claude Code's auto mode?

Auto mode is a Claude Code permission mode in which a classifier judges each action instead of asking the user to confirm it. By default it blocks destructive actions such as git reset --hard or terraform destroy. Since v2.1.284 it is the starting mode for every interactive session that isn't configured otherwise.

What is a mod in Claude Code?

A mod is a Claude Code plugin written in JavaScript or TypeScript that runs inside the tool, introduced on October 1, 2026 (v2.1.287). It can draw panes, add commands that run without a Claude turn, intercept tool calls or call a model. It runs with the user's permissions, so it should only be installed from a trusted source.

How many commands and settings does Claude Code have?

In October 2026, Claude Code documents about 120 built-in slash commands and skills, 33 hook events, 46 built-in tools, 243 settings.json keys and 391 environment variables. Angelo Lima's cheat sheet lists all of them, with an expandable appendix for settings and variables.

Originally published on angelo-lima.fr.