Max Zimmer

/loop, -p, the Agent SDK, and background sessions, untangled

Wed, 21 Oct 2026 00:00:00 GMT

/loop, -p, the Agent SDK, and background sessions are four ways to run Claude Code without typing every message yourself. /loop repeats a prompt inside a session you already have open. -p runs a single prompt and exits, so it's the one for scripts. The Agent SDK is that same engine as a Python or TypeScript library. A background session is a normal Claude Code chat that keeps going after you close the terminal.

The Claude Code docs group all four under one heading on the sessions page, and what they share is narrow. The session picker and claude --continue handle each of them differently from a normal chat. If you're new, that heading makes them look like one feature, or at least four related ones. They're not. I keep explaining the difference to people who are new to Claude Code, so here it is written down once.

Short version

	What it is	Is it a chat you can reply to?	How you start it
`/loop`	A prompt that re-runs on a timer inside your session	Yes, it's your current session	`/loop 5m check the deploy`
`-p`	One prompt, one answer, then exit	No, it prints and quits	`claude -p "what does auth.py do?"`
Agent SDK	`-p`'s engine as a library in your own code	Only if your code builds that	`npm install @anthropic-ai/claude-agent-sdk`
Background session	A full chat with no terminal attached	Yes, attach or reply anytime	`claude --bg "fix the flaky test"`

/loop repeats a prompt in your session

/loop re-runs a prompt in the session you're already in. It's for waiting on something, like a deploy finishing, CI going green, or review comments landing on a PR. It arrived in Claude Code 2.1.71 in March 2026.

What you pass decides how it behaves:

/loop 5m check if the deployment finished    # fixed interval
/loop check whether CI passed                 # Claude picks the interval
/loop                                         # built-in maintenance prompt

With an interval, it runs on a schedule. Units are s, m, h, and d, and anything under a minute rounds up to a minute. Without an interval, Claude picks the wait after each run, somewhere between one minute and one hour depending on what it saw. A bare /loop runs a built-in prompt that keeps working on unfinished tasks and tends the current branch's pull request. You can swap that default for your own instructions in .claude/loop.md.

The limits matter more than the syntax. A loop only fires while the session is open and idle. Close the terminal and it stops. Recurring loops also delete themselves after seven days, so a forgotten one can't run forever. If you want something that runs on a schedule without a session open, the docs point you to cloud routines or Desktop scheduled tasks instead.

To stop a fixed-interval loop, ask Claude to cancel it. Esc only stops the self-paced kind.

-p runs one prompt, then exits

-p (short for --print) runs Claude Code without the chat interface. You hand it a prompt, it does the work, prints the result, and exits. The docs used to call this "headless mode" and now call it non-interactive mode.

claude -p "Find and fix the bug in auth.py" --allowedTools "Read,Edit,Bash"

This is the one for scripts, git hooks, and CI. It exits with code 0 on success and non-zero on failure, so a script can branch on the result. Add --output-format json and you get machine-readable output, including a session ID.

A -p run isn't a dead end. It's saved like any other session (unless you pass --no-session-persistence), so you can keep going:

session_id=$(claude -p "Start a review" --output-format json | jq -r '.session_id')
claude -p "Now focus on the database queries" --resume "$session_id"

I haven't needed -p myself yet.

The Agent SDK is -p as a library

The Agent SDK gives you "the same tools, agent loop, and context management that power Claude Code," but you call it from Python or TypeScript instead of the command line. It was called the Claude Code SDK until version 2.0.0 in September 2025, which is why older blog posts use that name.

npm install @anthropic-ai/claude-agent-sdk   # TypeScript
pip install claude-agent-sdk                 # Python

The SDK runs the Claude Code binary under the hood, and your skills, CLAUDE.md memory, hooks, and MCP servers load the same way they do in the CLI. Use it when you're building something: an internal tool, a bot, a product feature that needs an agent. If you're in a language other than Python or TypeScript, the docs say to shell out to claude -p --output-format json, which is a good hint at how close the two are.

If you build a product on it, Anthropic doesn't let third-party apps offer claude.ai login or subscription rate limits unless they've been approved, so your users need to bring an API key.

Background sessions keep going without a terminal

A background session is a full Claude Code conversation that keeps running when no terminal is attached. You can walk away, open it later, reply, and leave again. This is the newest of the four. The screen that manages them, agent view, landed in 2.1.139 in May 2026 and is still labeled a research preview.

There are three ways in:

claude --bg "investigate the flaky settings test" starts one straight from your shell
/bg (or /background) inside a session you already have open sends it to the background
claude agents opens agent view, where each prompt you type starts a new background session

Agent view lists every background session and whether it's working, waiting on you, or done. Press Space on a row to peek and reply, or Enter to attach and get the full conversation back.

A few things happen behind the scenes. When you start a session with --bg or from agent view, Claude moves it into its own git worktree before editing anything, so parallel sessions don't overwrite each other's files. A session you sent to the background with /bg keeps editing where it already was. A small supervisor process keeps the sessions alive, and it's local, so they stop if your machine shuts down. Each session also uses your subscription quota on its own, so ten at once burns through it about ten times as fast.

claude -p --bg is an error, which surprises people. It sounds like "run this in the background without a chat," but -p never starts the interactive session that a background session is, so Claude Code refuses before it starts anything. Use claude --bg "prompt" with the prompt as a plain argument.

Background sessions come up a lot for me, and mostly Claude starts them, not me. I've tried agent view with limited success. It sounds cool, but I don't find it that easy to make sense of. I like nested sessions in the desktop app a lot, but they're a different tool for a different job.

Why some sessions don't show up when you resume

Back to that docs heading. When you run claude --resume or claude --continue, Claude Code is looking for conversations you had. It deliberately skips the ones that weren't conversations in that sense:

Sessions started with -p or the Agent SDK are left out of the picker and out of --continue.
Sessions whose first prompt was /loop are left out too. Running /loop later in a normal chat doesn't hide it.
--continue opens a background session that's finished, but not one that's still running. For a running one, attach from claude agents.

None of these are lost. You can open any of them with claude --resume <session-id>, and claude -p --continue does include -p, SDK, and /loop sessions. The logic makes sense once you see it. If your last ten sessions were cron jobs, you'd want --continue to skip them and land on the chat you were actually having.

Which one to start with

If you're new, start with background sessions. You'll run into them anyway, because Claude starts them on its own, so it helps to know what you're looking at and how to attach to one. Next, try /loop the first time you catch yourself asking "is it done yet?" Reach for -p when you want Claude inside a script. Leave the Agent SDK until you're building something other people will use.

Details as of October 2026, Claude Code 2.1.306.

Sources

Manage sessions, Claude Code docs
Run prompts on a schedule, Claude Code docs
Run Claude Code programmatically, Claude Code docs
Agent SDK overview and quickstart, Claude Code docs
Manage multiple agents with agent view, Claude Code docs
Glossary, Claude Code docs
Claude Code changelog, versions 2.0.0, 2.1.71, and 2.1.139
@anthropic-ai/claude-code release dates, npm registry

Claude Code now remembers where I work

Wed, 21 Oct 2026 00:00:00 GMT

Starting a Claude Code session in the desktop app used to mean the same small ritual every time. Pick local, SSH, or cloud. Pick the folder. Decide whether you want a worktree. Now you can save all of that as an environment and pick it in one click. An environment is a named preset for where Claude runs, and it shipped in mid-October alongside nested sessions.

I work in a lot of local repos, one or more per client, and that ritual added up. Re-picking the folder and the worktree setting for every new session was friction I'd stopped noticing until it went away.

What shipped

Environments arrived in Claude Desktop v2.42304.0, the same release that bundled Claude Code 2.1.299 and added nested sessions. The release note reads:

Added environments: save a folder, SSH host, cloud environment, or Remote Control machine, with a worktree and branch setting for each folder, and pick one when you start a session. "Save as environment" at the top of a session saves where it started (not yet in third-party deployments).

AlphaSignal covered it on October 14 and describes a saved environment as "a named preset." That's the clearest way to think about it. "Third-party deployments" means Desktop running against a company's own model provider instead of a Claude account. Those users don't get it yet.

What an environment holds

An environment answers "where does Claude run, and on what?" There are four kinds:

Local: one or more folders on your own machine
SSH: a remote machine you connect to, plus a folder on it
Cloud: an Anthropic-hosted environment, where sessions keep going after you close the app
Remote Control: another computer of yours running Claude Code that you drive from Desktop

For local and SSH environments, the desktop docs say the environment "also holds the folders Claude works in," so the folder picker disappears from the new-session row once you choose one. Each folder carries its own worktree setting. A worktree is a separate git checkout of the same repo, which lets two sessions edit the same project without stepping on each other. If you always want a worktree for one repo and never for another, you set that once.

Environment variables live there too. An earlier release (v2.31226.0) moved them onto saved environments, so "This computer" starts clean and only sessions started from a given environment get its variables. The docs suggest this as the fix for a long-standing annoyance, which is that Desktop launched from the Dock doesn't pick up everything you export in ~/.zshrc. Add the variables to the environment instead:

Open New environment or Edit environment.
Select Environment variables and enter one KEY=value per line.
Select Create environment or Save.

I haven't put variables in an environment yet, but I want to try it soon.

Making one

There are a few ways an environment gets created.

From the selector. Open the environment selector under the prompt box and pick New environment at the bottom (or press ⌥⌘0). The dialog has a tab for each kind. On the Local tab you give the environment a name and add folders. Each folder gets a Worktree checkbox, and once it's ticked a branch picker appears so you can choose which branch the worktree starts from. Select Create environment (or Add environment for cloud) and you're done.

From a running session. The changelog says "Save as environment" at the top of a session saves wherever that session started. That's the version I'd want, since you often only realize a setup is worth keeping after you've used it. I couldn't find the button in my sessions, though, so it may still be rolling out.

Automatically. The first time you open the Code tab with the new layout, Desktop creates up to eight environments for you, based on the local and SSH folders you used most in the last month. If you open the selector and find entries you don't remember making, that's where they came from. Hover and click the gear icon to edit or delete them.

Where they show up

Environments now run through the whole Code tab:

The New session page has a row under the message box for choosing where Claude runs, plus a card of recent environments. The picker lists local environments first, with keyboard shortcuts (⌥⌘1, ⌥⌘2, and so on), then Cloud and SSH.
Each session has an Environment card on the new session rail to the right of the conversation, showing the environment it started from, its folder, branch, and Remote Control switch.
The sidebar can group sessions by environment (Group by > Environment). Sessions with no saved environment fall back to grouping by folder or repository.

A couple of rough edges

The docs and the changelog don't quite agree on timing. The docs say saved local and SSH environments need Desktop v2.37337.0 or later, while the changelog announces them in v2.42304.0. My guess is a staged rollout, with the feature in the code before it was turned on for everyone. If your selector still sits above the prompt box, you have what the docs call the earlier layout, and updating should fix it.

Remote Control is the odd one out. The changelog says you can save a Remote Control machine, but the Remote Control tab has no form to fill in. It tells you to run claude rc on the machine you want to code from, with a link to the Remote Control docs. Wmedia's walkthrough describes the same thing. My read is that the machine appears in the picker once it's connected, rather than being something you set up from Desktop.

My take

It's a handy shortcut. Most of my sessions start with a client task, and an environment means I'm not digging for the right folder before I can describe the work. I'm still deciding whether I want one environment per repo or one per client. Per repo keeps the worktree setting exact, and per client matches how my work actually arrives.

I'd be careful with the environment variables. Variables on a shared environment are shared, and the app even shows a message telling you not to put secrets in them. That's probably fine if you work solo or in a silo, but on a team I'd keep keys somewhere else.

Sources

Claude Desktop changelog (v2.42304.0 and v2.31226.0)
Claude Code docs: Desktop application
AlphaSignal: Anthropic's Claude Code now runs nested sessions and saves dev environments (October 14, 2026)
Wmedia: Claude Code Desktop environments (October 14, 2026)

Claude artifacts can talk back to your session

Tue, 20 Oct 2026 00:00:00 GMT

Artifacts are amazing! An artifact is a page Claude makes for you (a doc, a deck, a design, a dashboard) that you keep, share, and come back to. The part that surprised me most is that an artifact can talk back. Put a button on the page, click it, and the Claude session it's open beside gets the message. Open the same artifact on its own and the button has nobody to talk to.

I got hooked building a dashboard for managing tasks across my Claude sessions. It's part tool and part dashboard, with resources and notes I can edit as I go, and because artifacts can keep data in a database, all of it sticks around between visits. I've also used one to plan the jump from v1 to v2 of an app. Every v1 feature got its own row with a toggle to keep it or skip it, which mattered because v1 was a prototype full of proofs of concept.

I made an example of each type so you can see them instead of reading about them. They're linked as we go.

Five types

As of October 2026 there are five kinds of artifact you can start from, each with its own template. Docs, Slides, and Design left beta on October 8 and are on every plan, Free included. Dashboards and Motion launched the same day in beta.

Type	What it's for	Plans	Exports
Docs	Writing you edit together with Claude and other people	All, including Free	Word, PDF, Markdown, Google Docs
Slides	16:9 decks to present or download	All, including Free	PowerPoint, PDF, Google Slides
Design	Artboards on a canvas: screens, posters, social cards	All, including Free	.zip, PDF, PPTX, HTML, Google Slides
Dashboards (beta)	Charts, numbers, and tables, with sources	Pro, Max, Team, Enterprise	None listed
Motion (beta)	Animated video	Team, Enterprise	MP4

Design looks and feels a lot like Figma: a canvas of artboards you can pan around, comment on, and export. It started life as Claude Design, an Anthropic Labs research preview in April, moved into every conversation in September, and the standalone claude.ai/design site closes on December 14.

I made my design example with one simple prompt, asking Design to show off what Design can do. Panning across artboards, editing components, and leaving comments right on the canvas all feel like Figma.

My examples, all made by Claude from one prompt each:

A doc: Artifact capabilities cheat sheet
A deck: Claude artifacts in 7 slides
A design: emzimmer.com post designs, with a share card, a phone mockup of this post, and a button in three states
A dashboard: Claude artifact types at a glance

All of them are shared publicly, but they don't all behave the same signed out. The deck and the design open for anyone, the dashboard loads but asks you to sign in to see its data, and the doc needs a Claude account to open at all.

I couldn't make a Motion example because it isn't on my plan. There's also no Sheets type, which I half expected. Spreadsheets only show up through the Google Sheets connector.

You can also skip the templates and have Claude write a plain HTML page. That's what the two talk-back examples below are.

What a page can do

A plain artifact is a web page, so it can do whatever a page can. The interesting part is what Claude adds on top. According to Anthropic's help center and the Claude Code docs, an artifact can:

call Claude with no API key, with usage counted against the viewer's plan, not yours
use your connectors (Google Drive, Notion, and so on), running as whoever is viewing
keep data between visits, up to 20 MB per artifact
take comments, and in a doc you can mention @Claude to ask for an edit
in Claude Code, keep every publish as a version you can switch between

In Claude Code these are called capabilities, and a page asks for them by name when it's published. My cheat sheet lists all eleven.

Artifacts start private. On Pro and Max you can keep one to yourself or share it with anyone who has the link. Team and Enterprise add "only people invited" and "anyone at your org", and public links stay off until an owner turns on external sharing, per the sharing article.

One rule matters for anything clever. An artifact that uses your connectors or calls Claude can't be shared with "anyone with the link". That makes sense, since it would run on the viewer's account, but it means the most interesting artifacts are the hardest to show off.

Talking back to the session

This is the really cool part. A page can hand data to the Claude conversation it's open beside, using a function called sendToClaudeSession. It isn't in the public docs yet. I found it in the type definitions that ship with Claude Code (runtime contract 0.2.85), and the public artifacts page only suggests a "Copy as prompt" button you paste from.

It works in two modes:

stage (the default) drops the data in your message box as an attachment, and nothing reaches Claude until you send a message of your own
send shows you what the page wants to send and asks you to confirm, then starts Claude's turn

In my test only stage worked. send failed with claude_unavailable, even though the call ran straight from the click. The definitions say that happens on a browser that can't prove the viewer's click for a send, so for now I'd build buttons that stage.

Either way, the click has to come from you. In the type definitions' own words, "There is no way for a page to start Claude's turn by itself." Claude also gets the data framed as coming from the page, never as your words or as instructions. Those two rules are what make it safe to put a button like this on a page someone else might open.

The code is short. The page asks for the room capability when it's published, then:

const room = await claude.use("room"); // null when this view can't use it

button.addEventListener("click", () => {
  // Call it straight from the click, with nothing awaited first
  room.sendToClaudeSession(
    { label: "Explain this page", request: "explain" },
    { deliver: "stage" }
  );
});

Try it with my talk-back demo. Pick a request, press a button, and watch it land in your conversation.

Why it fails when you open it on its own

When I opened the same artifact by itself from the artifacts panel in the desktop app, the button failed silently. No error, no message. The type definitions explain why. Before sending, a page can call canSendToClaudeSession(), and when no conversation is open beside it, the answer is no_session. The data needs somewhere to go.

My demo shows the answer live, so you can see which state you're in. If you open it from a public link, you'll see off, because sending to Claude is never offered there. The definitions also list states where the platform will route a "send" to one of your sessions that already has the artifact, or open a new chat for it. I haven't seen those happen myself.

Can a dashboard run all your sessions?

Not yet, at least not on my account. Here's what I tried.

My first idea for reaching a particular session was webhooks. Claude Code's cloud sessions do have one, a tool called watch_url, but its signing secret is sealed so that only the artifact service can use it. It wakes a session when an artifact it watches gets republished, which is useful but isn't a way for your page to call a session. Routines also accept a webhook, and each one starts a brand new session rather than messaging an existing one.

The better route is the connector. Cloud sessions in Claude Code come with a Claude Code Remote connector that can start and steer other sessions, including listing them and sending one a message. An artifact can call your connectors as you. On paper, putting those together lets a page list your sessions and message any of them, one at a time or all at once.

So I built it: a Session Switchboard with a row per session, a message box on each, and a broadcast box for the ones you tick. It never got that far. When I opened it, the connector refused with blocked_by_policy and offered the page no tools at all. The runtime's type definitions describe that code as organization policy blocking the tool for this viewer. The artifact's permissions panel showed both tools allowed, and Claude Code Remote doesn't appear in the connector settings at all, so there was nothing for me to switch on. So for now, at least on my account, an artifact can't message your other sessions. The button beside a session is the only way back in.

My take

Start with persistent data. Ask Claude for a small tracker (tasks, reading list, whatever you'd otherwise keep in a note) that saves its data in the artifact's database. It's the feature my own task dashboard depends on. Once you have one, add a button that sends the current item to Claude, and open it beside a session.

Sources

Dashboards and Motion launch post, Anthropic, October 8, 2026
What are artifacts and how do I use them?, Claude Help Center
Publishing, remixing, and sharing artifacts, Claude Help Center
Artifacts admin guide for Team and Enterprise plans, Claude Help Center
Get started with Claude Design, Claude Help Center
Get started with Claude Docs, Claude Help Center
Get started with Claude Motion, Claude Help Center
Introducing Claude Design, Anthropic, April 17, 2026
Artifacts in Claude Code, Claude Code docs
Routines, Claude Code docs
Self-hosted environments configuration, Claude Code docs
Build and share AI-powered artifacts, Anthropic
Artifact runtime type definitions (room.d.ts, contract 0.2.85), bundled with Claude Code 2.1.302

Git for people who started with Claude Code

Mon, 19 Oct 2026 00:00:00 GMT

If you came to Claude Code without a programming background, git is the thing you're most likely to trip on. It shows up everywhere. The desktop app has a worktree toggle, sessions sit on branches with names like worktree-bright-running-fox, Claude offers to commit and open a pull request, and the diff view counts lines in green and red. Claude will happily run all of it for you. But if you don't know what a commit or a branch is, you can't tell whether Claude did the right thing, and you can't undo it when it didn't. Five ideas cover almost all of it: repository, commit, branch, remote, and worktree. This post explains each one, then walks through setting up git and GitHub from nothing.

Short version:

Git is a free program on your computer that keeps a history of a folder. GitHub is a website that hosts copies of those folders. You need git for Claude Code's best features, and GitHub mostly for cloud sessions and team work.
Commit early and often. A commit is a save point you can always get back to.
Branches let you try things without touching the working version. Worktrees let several Claude sessions each have their own branch at the same time.
Claude Code's rewind feature is handy, but it isn't a backup. Git is.

Git and GitHub aren't the same thing

Git is version control, a program that tracks changes to files. It was written in 2005 by Linus Torvalds and the Linux kernel community, after they lost free use of the tool they'd been using (Pro Git, GitHub's 20th anniversary Q&A with Torvalds). It runs entirely on your machine. Every copy of a project carries the full history, so you don't need an account, a server, or an internet connection to use it.

GitHub "builds on Git by hosting your Git projects" (GitHub Docs) and adds the collaboration layer on top: pull requests, issues, code review, and automation. It isn't the only host. GitLab, Bitbucket, and Codeberg do the same job, and all three have free tiers.

So when does Claude Code need GitHub? Locally, it doesn't. The docs say Claude Code "works in any directory," git repo or not (Common workflows). A few features do need git, though. Worktrees need a git repository, and so do the desktop app's session isolation and the /diff view (Worktrees, Desktop). GitHub specifically comes in for cloud sessions on claude.ai/code, where "repository cloning and pull request creation require GitHub" (Claude Code on the web), and for the @claude GitHub app.

Make every Claude Code project a git repo, even a folder of notes. It costs nothing and gives you an undo button for everything.

A repository is a folder with a memory

A repository (repo) is a normal folder with a hidden .git folder inside it. That hidden folder holds the entire history of the project. You make one in two ways.

git init                 # turn the current folder into a repo
git clone <url>          # copy an existing repo, history and all

Pro Git describes three places your work can live. The working tree is the files you see and edit. The staging area (git also calls it the index) is a holding area for changes you've picked for the next save. The .git folder is the permanent history. Most confusion about git comes from forgetting which of those three you're looking at.

When you start Claude Code in a repo, it reads your git state when the conversation starts: the current branch, uncommitted changes, and recent commits (How Claude Code works). That's how it knows what you were in the middle of.

A commit is a save point

A commit is a snapshot of your project at a moment in time. Git stores whole snapshots, not lists of edits. Each commit records who made it, a message describing it, a pointer to the commit before it, and an ID. The ID is a 40-character hash like 24b9da6552252987aa493b52f8696cd6d3b00373 (Pro Git).

Making one by hand takes two steps.

git status                       # what changed?
git add notes.md                 # stage this file for the next commit
git commit -m "Add meeting notes"

The git add step trips people up. It means "add precisely this content to the next commit" (Pro Git). If you edit the file again after adding it, you add it again.

Pro Git's advice is to "make each commit a logically separate changeset," with a short first line in the imperative ("Fix login bug," not "fixed stuff") (Pro Git). Small commits are easy to review and easy to undo one at a time. A commit that bundles a day's work is all-or-nothing.

With Claude Code you rarely type any of this. You say "commit my changes with a descriptive message" and it stages, writes the message, and commits (Overview). By default it adds a Co-Authored-By: Claude ... line to the message, which you can change with the attribution setting (Settings). Most commits on this blog have one.

How often you have Claude commit depends on the work. Each rhythm has its uses.

When Claude commits	Good for	Trade-off
After every change	Risky or exploratory work, where you want to step back one edit at a time	A long, noisy history
At the end of each task	Most day-to-day work. One commit per finished piece reads cleanly later	Mid-task mistakes are harder to undo on their own
Only when you ask	Learning git, or when you want to review everything before it's saved	Easy to forget, and uncommitted work has no safety net

A branch is a parallel version

A branch is "a lightweight movable pointer" to a commit (Pro Git). That's all it is. When you commit on a branch, the pointer moves forward to the new commit. Other branches stay where they were.

This is what makes experiments safe. Your working version lives on main. You make a branch, try something, and if it works you merge it back. If it doesn't, you throw the branch away and main never knew.

git switch -c try-new-layout     # create a branch and move to it
# ...edit and commit...
git switch main                  # go back
git merge try-new-layout         # bring the work in

A note on names. GitHub has called the default branch main since October 2020 (GitHub changelog). Git itself still calls it master when you run git init, and the docs say "this will change to main when Git 3.0 is released" (git-init). Set it once (see setup below) so your local repos match GitHub.

Sometimes a merge hits a conflict, when the same lines changed differently on both branches. Git stops and writes both versions into the file between <<<<<<<, =======, and >>>>>>> markers. You (or Claude) pick what to keep, delete the markers, then git add and git commit (Pro Git). It looks scarier than it is.

A remote is the copy somewhere else

A remote is a copy of the repo hosted elsewhere, usually GitHub. When you clone, git names it origin automatically (Pro Git). Three commands move work between your machine and the remote.

git push uploads your commits.
git fetch downloads new commits but doesn't change your files.
git pull downloads and merges in one step.

Your commits live only on your machine until you push. If your laptop dies before then, they're gone.

On GitHub, the standard way to merge a branch is a pull request (PR), a "proposal to merge code changes into a project" (GitHub Docs). GitHub flow is the simple loop most teams use.

Create a branch.
Make changes and commit them.
Push and open a pull request.
Review and address comments.
Merge, then delete the branch.

Claude Code opens PRs with GitHub's gh command-line tool (Common workflows), so ask it to "create a PR for my changes" and it'll push the branch and open one. Even when you work alone, a PR gives you one page showing everything Claude changed before it lands on main.

A worktree is a second desk

Claude Code leans on git hardest with worktrees. Normally a repo has one folder, and that folder is on one branch at a time. If two Claude sessions work in the same folder, they edit the same files and step on each other.

A worktree fixes that. Git lets one repository "support multiple working trees, allowing you to check out more than one branch at a time" (git-worktree). Each worktree is a separate folder with its own branch, but they all share one history. Commit in one and the others can see it. The one rule is that a branch can only be checked out in one worktree at a time.

Claude Code wraps this up for you. In the terminal, claude --worktree feature-auth (or -w) creates a worktree at .claude/worktrees/feature-auth/ on a branch called worktree-feature-auth, and starts the session there (Worktrees). Leave off the name and Claude makes one up. In the desktop app it's the Worktree toggle on a new session (Desktop). Subagents can get their own worktree too, with isolation: worktree.

Two practical tips from the docs:

Add .claude/worktrees/ to your .gitignore so the worktree folders don't show up as changes in your main checkout.
Files git ignores, like your secrets file, don't get copied into a new worktree. List them in a .worktreeinclude file (same syntax as .gitignore) and Claude Code copies them in.

This is the machinery behind running several sessions at once, which I wrote about in nested sessions. The parent session merges each child's branch when it's done.

I learned this one the hard way. Before I used worktrees, I ran two sessions in the same folder and they overwrote each other's edits.

Checkpoints aren't git

Claude Code has its own undo. Press Esc twice or type /rewind and you can roll back the code, the conversation, or both, to any earlier prompt (Checkpointing). It's great for "no, not like that."

It's not version control, and the docs say so plainly: "Checkpoints are designed for quick, session-level recovery. For permanent version history and collaboration, continue using version control, such as Git, for commits, branches, and long-term history." Checkpoints only track edits Claude makes with its file tools. The same page says they don't track "files modified by Bash commands," so if Claude runs a script that rewrites files, or deletes something with rm, rewind won't bring it back. They also don't cover your own edits, and they expire. A commit doesn't expire.

Setting it up from scratch

As of October 2026, the latest git is 2.56.0, released September 28 (git-scm.com, git/git tags).

1. Install git

On a Mac, the easiest route is Apple's command line tools, which include git. Or use Homebrew if you have it (git-scm.com).

xcode-select --install
# or
brew install git

On Windows, install Git for Windows, or run winget install --id Git.Git -e --source winget. On Linux, use your package manager (sudo apt-get install git or sudo dnf install git). Check it worked with git --version.

2. Tell git who you are

Every commit carries your name and email, "immutably baked into the commits" (Pro Git). Set them once. The third line makes new repos start on main.

git config --global user.name "Your Name"
git config --global user.email you@example.com
git config --global init.defaultBranch main

Sign up at github.com. The free plan includes unlimited public and private repos and unlimited collaborators (GitHub pricing, GitHub's plans).

GitHub stopped accepting passwords for git in August 2021 (GitHub blog), so you need a token or an SSH key. Skip both and install the GitHub CLI, which handles it for you and is also what Claude Code uses to open PRs.

brew install gh          # Mac; see cli.github.com for Windows and Linux
gh auth login

gh auth login opens your browser, signs you in, and offers to set up git's credentials so git push just works (gh manual). If you'd rather click than type, GitHub Desktop is a free app for Mac and Windows that does the same.

4. Create a repo

You can start on GitHub. Click + then New repository, give it a name, pick public or private, and tick the boxes for a README and a .gitignore template (GitHub Docs). Then clone it.

Or start from a folder you already have. This turns it into a repo, makes a first commit, creates a private repo on GitHub, and pushes to it.

cd my-project
git init
git add .
git commit -m "First commit"
gh repo create my-project --private --source=. --remote=origin --push

Or skip all of that and ask Claude Code to do it. Now that you know what each step is, you can read along as it does.

5. Keep secrets out

A .gitignore file lists files git should never track. Put your secrets file in it, along with things like node_modules/ and .DS_Store, before your first commit. A .gitignore doesn't affect files git already tracks. You'd have to untrack them with git rm --cached <file> (gitignore docs).

This matters because a committed secret stays in the history even after you delete the file. GitHub's advice is to revoke and replace the key first, because cleaning history is hard and copies can survive in clones and forks (GitHub Docs). GitHub's push protection blocks pushes containing known secrets to public repos by default, but not to private ones unless you turn it on (GitHub Docs). Private by default is the safer habit.

Undo, and what Claude asks first

The undo commands you'll actually use:

Command	What it does	Safe?
`git restore <file>`	Throws away uncommitted edits to a file	Destroys those edits
`git restore --staged <file>`	Unstages a file, keeps your edits	Yes
`git revert <commit>`	Makes a new commit that undoes an old one	Yes, history is kept
`git stash` / `git stash pop`	Sets uncommitted work aside, then brings it back	Yes
`git reset --hard`	Moves the branch back and discards local changes	No

The git docs warn about reset --hard directly: "Do not do this if you have already given these commits to somebody else" (git-reset). If you're unsure, revert is almost always the right answer, and you can ask Claude to do it.

On permissions, read-only git commands like git status and git log run without asking. Everything else, including git commit and git push, prompts you by default unless you've allowed it (Permissions). In auto mode, Claude blocks force pushes, git reset --hard, and similar destructive commands on its own. But auto mode allows "pushing to any branch of the repository you're working in, including the default branch," without a prompt (Permission modes). If you want a human check before anything reaches GitHub, add Bash(git push *) to your permissions.ask rules.

How I'd start

I run auto mode and let Claude commit and push. If you're new to all of this, the one habit that pays off is committing before you ask Claude for anything big. Then whatever happens, git status shows you what changed and git restore gets you back. Everything else in this post you can learn when you need it.

Sources

Pro Git book (history, what git is, recording changes, branching, remotes, first-time setup, contributing)
git-init, git-worktree, git-reset, git-restore, gitignore
Install git: macOS, Windows, Linux
git/git tags
Git turns 20: a Q&A with Linus Torvalds, GitHub blog, April 2025
About GitHub and Git, GitHub Docs
GitHub pricing and GitHub's plans
Git password authentication is shutting down, GitHub changelog, August 2021
The default branch for newly created repositories is now main, GitHub changelog, October 2020
GitHub flow and About pull requests, GitHub Docs
Creating a new repository, GitHub Docs
gh auth login and gh repo create, GitHub CLI manual
About GitHub Desktop
Removing sensitive data from a repository and About push protection, GitHub Docs
Claude Code docs: Common workflows, Overview, How Claude Code works, Worktrees, Checkpointing, Desktop, Claude Code on the web, Settings, Permissions, Permission modes

I keep my Claude Code sidebar strict

Sun, 18 Oct 2026 00:00:00 GMT

If you run a lot of Claude Code sessions in the Claude desktop app, the sidebar turns into a junk drawer fast. I keep it in check with three habits. I name every session with the same pattern, I file each one into a section based on its status, and I archive anything that's finished. None of it is clever. Being strict about it is what makes the difference.

The sidebar fills up quicker than it used to. Nested sessions let one session spin off half a dozen children, and every one of them is a session you might need to find again next week.

Name your sessions

The app titles each session for you, and the changelog shows it generating titles from the conversation. They're fine in the moment and useless a week later, when five sessions are all called something like "Fix form validation."

To rename one, open it and click the session title in the title bar. The session's right-click menu has Rename too. I use one pattern for everything:

WXX: YYY - Short task description

WXX is the week number, YYY is the client or ticket identifier, and the rest is a few words about the task. So a session from this week might be W42: ACME01 - Fix donation form validation.

The week number tells me how stale a session is at a glance. The identifier groups a client's work together when I sort or search. The description is for me, so it only has to make sense to me. It's a small thing, but a consistent prefix means I can find any session in a couple of seconds.

Sort sessions into sections

The sidebar lets you make your own groups, which the app now calls sections. They got that name in v2.42304.0, the same release that shipped nested sessions. To make one, right-click an empty spot in the sidebar and pick New section. To file a session, right-click it, choose Move to group, and pick a section (or make a new one right there).

I group by status, not by client, since the naming convention already covers clients. My sections:

Pinned is for focus time. Pin is on the session menu, and pinned sessions get their own list in the sidebar. Whatever I'm working on right now goes here, and nothing else does.
Waiting/Hold is for sessions blocked on someone else, usually a client's approval. They're not done, but there's nothing for me to do until I hear back.
Past Due is for task sessions that have slipped past their due date. Having a section for it means I can't pretend it isn't happening.
Case Closed is where a session goes when the work is done and Claude is running a retrospective on it. Nothing's needed from me, so the session is closed in all but name.
Recents is everything else. It's the default spot for sessions that aren't in a section, so new sessions land there until I file them.

The app's Group and sort menu shows up when you hover over a section heading. It also lets you group by folder, repository, or (since v2.42304.0) environment. I tried those, but status is what I actually need to know when I open the app.

Archive what's closed

Once a session has its retro and nothing else is pending, I archive it. Hover over the session, open its menu, and pick Archive. If your sessions end in pull requests, there's a setting called "Auto-archive after PR merge or close" in Settings > Claude Code (docs). I've never used it. I prefer archiving by hand. You can also ask Claude to tidy up. The docs give "archive the sessions whose PRs have merged" as an example.

Archiving isn't deleting. Archived sessions live under View all > Archived, and you can unarchive one from there. One thing to know first is what happens to the session's worktree (the separate git checkout the session works in). For a local session, the worktree stays on disk with its changes, and the app removes it about 30 days after you archive the session or last open it, whichever is later. If there's uncommitted work you care about, commit it before you archive.

Why bother

Partly it's for me. When I open the app in the morning, the sidebar tells me what's in focus, what's blocked, and what's late, without opening a single session.

There's also a practical side. Lots of open sessions cost something. Anthropic has fixed sessions stalling "when many sessions are open" (v2.7032.0), and there are open GitHub issues about the desktop app eating memory with several sessions running, like this one on a 32 GB Windows laptop. There's no official number for how many sessions is too many. Speed wasn't why I started archiving, and I'm not claiming it fixes performance. For me it's about finding things, and a smaller pile doesn't hurt.

The setup has rough edges. Since the Recents change, the Recents section expands itself every time you start a session. Search can also archive a session by accident. The ⌘K results mix in actions like Archive and Delete for the session you have open, so read before you click.

My take

Sessions are cheap to start, so you'll start a lot of them. The sidebar is the only place that knows about all of them at once, and it only stays useful if you keep it in order. Name it when you start it, move it when its status changes, and archive it when it's closed. It takes a few seconds per session, and it's worth doing every time.

Sources

Claude Code desktop docs: renaming, archiving, auto-archive, worktree cleanup, Group and sort.
Claude desktop release notes: v2.42304.0 (sections, Group and sort, environment grouping), v2.2553.0 (Pinned list), v2.7032.0 (many-sessions fix).
GitHub issues on anthropics/claude-code: #78796 (session menu items), #100949 (search actions), #101710 (memory), #103008 (Recents behavior).

Nested sessions turn one Claude Code session into a switchboard

Sat, 17 Oct 2026 00:00:00 GMT

The Claude desktop app can now hand a task to a whole new Claude Code session that lives under the one you're in. Anthropic calls these nested sessions. The parent can message its children, the children report back, and each child is a full session you can open and talk to yourself. That last part is what makes them different from subagents. It means I can use one session as an orchestration layer and still stay in the loop on every task it spins off.

I found this by accident. A suggested task showed up in a conversation, I clicked it, and instead of the usual worktree session I got a child session tucked under the parent in the sidebar.

What shipped

Nested sessions arrived in Claude Desktop v2.42304.0 on October 15, 2026, which bundles Claude Code 2.1.299. The release note says Claude "can start a task in a separate session, which appears under the original session in the sidebar and reports back to it." AlphaSignal's writeup from the day before describes the same thing: a parent splits work into child sessions, and each child "reports the result to the parent when finished."

A few details from the release notes:

It works in local and SSH sessions in the desktop app's Code tab. Cloud sessions don't get it, and neither do third-party deployments yet.
Suggested tasks now appear inline in the conversation instead of above the message box.
Settings > Claude Code has a new option for what happens when you ask for something unrelated to the current task.

How it works

Suggested tasks aren't new. The desktop docs describe them as task chips. When Claude notices something worth fixing that's out of scope, it offers the work as a chip, and clicking it starts the work in a new session "with its own worktree" while Claude carries on in the current one. A worktree is a separate git checkout of the same repo, so two sessions can edit files without stepping on each other.

What's new is where that session goes and what it can do once it's there. Clicking "create a new session, do it there" opens an options box where you choose:

whether to use a worktree (the docs only mention worktrees, but you can switch it off and run in the parent's folder)
the model
the effort level

The session that starts sits under its parent in the sidebar. If it outgrows that spot, you can detach it and promote it to a top-level session. Nesting only goes one level deep for now. When a child tries to spawn its own task, the new session shows up as a sibling, not a grandchild.

You don't have to wait for Claude to notice something, either. You can ask the parent to suggest tasks, and it'll lay out a set of cards that you can accept one at a time or all at once. I haven't hit a limit on how many children a parent can have. Yesterday I had one session with six nested tasks under it.

That session was for one client with several asks. The parent held the direction and did the orchestration. Each nested session took one piece of the work in its own worktree, and the parent merged the commits from each child. I could check in on any child's progress whenever I wanted. When something new came up mid-task, I told the parent, and it passed the update to all six children at once.

The parent can talk to its children

The parent-to-child link runs on cross-session messaging, which has been in Claude Code since v2.1.224. Claude finds sessions with a ListAgents tool and sends with SendMessage. You don't call either one yourself. You just say "tell the payments session the schema changed" and Claude writes the message.

A few things from the docs that matter in practice:

Replies work both ways. The receiving Claude can answer, and the answer comes back to the sender.
Nothing is interrupted. If the receiving session is mid-task, the message waits until the current work finishes. If it's idle, the message starts a new turn.
Messages carry no authority. A message from another session can't approve a permission prompt or change settings. Each session keeps its own permissions.
It's plain text. A message is text that one Claude writes to another. It never includes the sender's conversation history or files.

There's also an idle notice. The parent can ask a child to send a single notice when it next goes idle, which is handy for a long migration or test run. And the desktop app lets Claude list, read, rename, and archive your other Code tab sessions, so the parent can tidy up children whose PRs have merged.

How this differs from the other ways to run agents

Claude Code now has a lot of ways to run work in parallel. The docs' comparison page lists five of them, and that's before nested sessions. I covered one of them, dynamic workflows, last week. Here's where nested sessions fit:

	Who coordinates	Can you talk to a worker directly?	Isolation
Subagents	Claude, inside one session	No, they return a summary	Own context, optional worktree
Agent teams	A lead session, using a shared task list	Yes	No worktrees, so you split up the files
Agent view	You	Yes	Its own worktree before it edits
Nested sessions	The parent session, with you approving each spawn	Yes, each one is a full session	Worktree or the parent's folder, your choice

Subagents are the closest comparison. Both are delegated work that reports back. The difference is that a subagent is a black box that hands back a summary, while a nested session is a real session with its own history. I can open it, read what it did, correct it, and send it back to work. It's a subagent I can manage. Agent teams are still experimental and off by default, and they lean toward Claude running the show. Nested sessions keep me as the one who says yes to each task.

What I use them for

My main use is complex work where I need to stay in the loop on each item. The parent holds the overall plan and acts as the orchestration layer. Each item becomes a nested session that I can check, steer, and approve on its own. That keeps the parent's context focused on coordination instead of filling up with the details of six different tasks. Sometimes I open a child and redirect it while it's running. Sometimes the parent reviews a child's result before I approve it. I'm sure there are plenty of other ways to set it up.

Setting up the orchestrator pattern

Here's how I'd set up the version from my client session. The prompts are examples, so word them however you like.

Start the parent in the project folder on the branch you want the work to land on. The parent does the merging, so it should sit where the merges go.
Give it the whole job and ask for tasks. Something like "Here are the client's asks. Break them into separate pieces of work and suggest a task for each."
Accept the cards, all at once or one by one. Turn the worktree on for any child that might touch the same files as another, and pick a model and effort level per task.
When something changes, tell the parent, not each child. "The client wants the banner in blue now. Let every task that touches the header know."
As children finish, have the parent review and merge. "Child 2 reported back. Check its commits and merge them if they look right."
Clean up. Ask the parent to archive the finished children. You'll get an approval card first unless you're in Auto or Bypass permissions mode.

There's also a setting for this. In Settings > Claude Code, you can choose what happens when you ask for a task unrelated to the current one.

Some other uses that fit well:

The out-of-scope fix. This is the original purpose of suggested tasks. Claude spots a bug that has nothing to do with the current work, and you send it off to a child session instead of derailing the conversation.
Clearing a backlog. Paste in a list of small issues, ask the parent to suggest a task for each one, and accept them all at once.
Matching the model to the job. Since each child gets its own model and effort setting, routine chores can run on a cheaper model at low effort while the hard task gets the big one.
Long-running jobs. Put a migration or a slow test suite in a child and have the parent ask to be told when it goes idle.
Trying two approaches. Spin off two children in separate worktrees, each with a different approach, and compare them.

Costs and rough edges

Every child is a full session, so the tokens add up. The docs say plainly that "running several sessions or subagents at once multiplies token usage," and every delivered cross-session message counts toward usage like a prompt you typed. Six children means six sessions' worth of usage.

The messaging also has limits. Messages are plain text, a single message to a session on the same machine is capped at about a million characters, and a receiving session queues at most 50 messages. Those limits mostly exist to stop two sessions from messaging each other in a loop.

I haven't hit a real problem yet. The only awkward part was the first time, which went roughly "huh?" then "oh, cool," and then a while of wondering how to make the most of it.

My take

This is the multi-agent setup I've wanted. Subagents are great when I don't care how the work gets done. Agent teams and workflows are great when I want Claude to run the whole thing. Most of my real work sits in between. I want help splitting it up and keeping track of it, but I want to make the call on each piece. Nested sessions handle that middle ground, and since they show up as chips you can click, there's almost nothing to learn.

If you're on the desktop app, update it, then ask your next session to suggest tasks for whatever you're working on. Turn off the worktree for small tasks in the same folder and keep it on for anything that edits the same files as the parent.

Sources

Claude Desktop release notes, v2.42304.0 (October 15, 2026) and v2.31226.0 (October 8, 2026)
Use Claude Code Desktop, Claude Code docs
Message your other Claude Code sessions, Claude Code docs
Run agents in parallel, Claude Code docs
Anthropic's Claude Code now runs nested sessions and saves dev environments, AlphaSignal, October 14, 2026
My own use of the Claude desktop app, October 2026

Claude Code is also an MCP server. What!?

Wed, 14 Oct 2026 00:00:00 GMT

Claude Code can run as an MCP server. One command, claude mcp serve, lets any app that speaks MCP (Claude Desktop, Cursor, or a script you write) use Claude Code's tools: reading and editing files, running shell commands, searching the web, and, as of a few weeks ago, handing off a whole task to a Claude Code agent. It also does no permission checks of its own, so the app on the other end has to be the one that asks before anything runs.

I stumbled on this in the Claude Code MCP docs and had no idea what to do with it. So I poked at it until I did.

Flipping the usual direction

MCP (Model Context Protocol) is the standard way AI apps connect to outside tools. Usually Claude Code is the client. You add a server, say for GitHub or a database, and Claude Code calls its tools.

claude mcp serve turns that around. Claude Code becomes the server, and some other app is the client. That app gets Claude Code's toolbox without having to build its own file editor or shell runner.

Setting it up

Start it like this:

claude mcp serve

Nothing happens. No banner, no prompt, just a terminal that looks frozen. That's correct. The docs explain that a stdio server talks over standard input and output, so it sits there waiting for a client to connect. You won't normally run it by hand anyway. The client app starts it for you.

For Claude Desktop, add this to claude_desktop_config.json:

{
  "mcpServers": {
    "claude-code": {
      "type": "stdio",
      "command": "claude",
      "args": ["mcp", "serve"],
      "env": {}
    }
  }
}

If Desktop can't find claude on its PATH, you'll get spawn claude ENOENT. Run which claude and put the full path in command instead.

The server runs in whatever directory the client launches it from. In my test, pwd returned the folder I started it in, and every file path is relative to that.

What it actually exposes

The docs say it exposes "Claude Code's tools" without listing them, so I asked it directly. A few lines of Python can speak MCP to it:

import subprocess, json

p = subprocess.Popen(["claude", "mcp", "serve"], stdin=subprocess.PIPE,
                     stdout=subprocess.PIPE, text=True)

def send(msg):
    p.stdin.write(json.dumps(msg) + "\n")
    p.stdin.flush()

send({"jsonrpc": "2.0", "id": 1, "method": "initialize",
      "params": {"protocolVersion": "2025-06-18", "capabilities": {},
                 "clientInfo": {"name": "probe", "version": "0"}}})
p.stdout.readline()
send({"jsonrpc": "2.0", "method": "notifications/initialized"})
send({"jsonrpc": "2.0", "id": 2, "method": "tools/list"})

for tool in json.loads(p.stdout.readline())["result"]["tools"]:
    print(tool["name"])
p.kill()

On Claude Code 2.1.296 I got 24 tools back. The ones that matter most:

Read, Write, Edit, and NotebookEdit for files
Bash for shell commands
WebSearch and WebFetch
Skill, so a client can run your Claude Code skills
Agent, Workflow, and SendMessage for delegating work to subagents
CronCreate and friends for scheduling

Your list will differ. Mine included tools tied to my own setup, like Artifact and DesignSync. What it doesn't include is any of the MCP servers Claude Code itself is connected to. My Gmail, Notion, and Figma connectors were nowhere in the list. There's no passthrough, which Kyle Redelinghuys also found.

Why it flew under the radar

For most of its life this was a remote file editor and shell. Useful, but most MCP clients can already get that from a dedicated filesystem server.

The Agent tool is what makes it interesting, and it barely worked until recently. The changelog for 2.1.288 says it "fixed the Agent tool in claude mcp serve always reporting no available agents and rejecting every subagent_type." Before that fix, a client couldn't actually hand Claude Code a task.

Now it can. I sent an Agent call asking a general-purpose subagent to read a file and tell me its contents. It came back in 4.3 seconds, ran on Opus 5.5, and reported using 33,825 tokens for that one tiny job. So a client can say "go refactor this module" and get a full Claude Code agent doing the work.

A couple of other recent fixes point the same way. Version 2.1.271 added a progress update every 30 seconds so long commands don't hit client timeouts. Version 2.1.295 made background Bash results include the output file path. It's getting steady attention, even if it isn't getting announcements.

Be careful with it

The docs say it plainly. The server "only exposes Claude Code's tools to your MCP client, so your own client is responsible for implementing user confirmation for individual tool calls."

I tested how far that goes. My Bash and Read calls ran instantly with no prompt. Then I added a project .claude/settings.json with deny rules for Bash(rm:*) and for reading a file called secret.txt. In my test neither rule stopped anything. The client read the secret and deleted the other file. I only tried this on one machine and one version, so treat it as a warning rather than a spec, but don't count on your Claude Code permissions to protect you here.

So only connect a client that asks you before each tool call, and launch it in a folder you're happy for it to touch.

When I'd use it

Kyle's take is that "this isn't revolutionary for day-to-day coding if your current tools work fine." That's fair. If you already live in Claude Code, you don't need another app driving it.

It earns its place when the other app is where you already are. Claude Desktop can now hand a coding task to a real Claude Code agent. Your own script or agent can borrow Claude Code's tools, and your skills, without rebuilding them.

I don't have a real use for it yet. I mostly wanted to understand it, and I'll keep using Claude Code directly. But now I know it's there.

Sources

Connect Claude Code to tools via MCP, Claude Code docs
Claude Code changelog, versions 2.1.271, 2.1.288, and 2.1.295
Claude Code MCP Server: Complete Setup Guide, Kyle Redelinghuys, October 2025
Claude Code MCP Server: claude mcp serve Explained, Oodle
My own tests against Claude Code 2.1.296 on macOS, October 2026

How close does Workers AI get to the frontier? An October 2026 scorecard

Mon, 12 Oct 2026 00:00:00 GMT

For most of its life, Workers AI was where you went for embeddings, Whisper, and an 8B Llama for classification. Serious reasoning work went to a closed API. That changed in 2026. Since March, Cloudflare has been adding trillion-parameter open-weight models with million-token context windows, and it has been rebuilding its inference stack to serve them.

So I wanted a direct answer to one question. If you build on Workers AI today, how far behind the frontier are you, and what does it cost you?

The short version:

Workers AI lists 69 models. 35 of them are text-generation models.
The best hosted LLM, GLM-5.3, scores 45 on the Artificial Analysis Intelligence Index. The leader, Claude Opus 5.5, scores 58. That puts the best Workers AI model at about 78% of the top score.
GLM-5.3-Flash scores 42 and costs about 4% of what Opus 5.5 costs on the sample agent workload below.
Cloudflare's per-token prices for these models match the model makers' own APIs. You pay the same rate and get Cloudflare's network, bindings, and billing.
The large paid models are limited to 20 requests per minute per model per account (50 with prepaid AI Gateway credits). For many production agent fleets, this limit matters more than the benchmark gap.

All figures below were checked on October 9–11, 2026. Both the catalog and the leaderboard change monthly.

Two catalogs, not one

There are two separate Cloudflare model lists, and they are easy to confuse.

Workers AI (69 models). These models run on Cloudflare's own GPUs, have IDs like @cf/zai-org/glm-5.3, and are billed in Neurons.
The unified AI catalog (241 models). This list adds third-party models such as Claude, GPT-6, Gemini, Grok, Seedance, and ElevenLabs. Requests go through AI Gateway, the provider runs inference, and you pay with the provider's key or with prepaid Cloudflare credits.

So you can call Claude Opus 5.5 from a Worker, but Workers AI is not serving it. Comparing "Workers AI vs frontier" really means comparing Cloudflare-hosted open-weight models with closed models reachable through the same binding.

What's actually hosted

Here is the Workers AI catalog by task type, taken from the models page (last updated August 12, 2026):

Task	Count	Notable models
Text generation	35	`glm-5.3`, `glm-5.3-flash`, `deepseek-v4-pro-0813`, `deepseek-v4-flash-0731`, `kimi-k2.6`, `kimi-k2.7-code`, `qwen3.8-27b`, `gemma-4-26b-a4b-it`, `nemotron-3-120b-a12b`, `gpt-oss-120b`, Llama 3.x/4 Scout, Cloudflare's own `clef`
Text-to-image	10	FLUX.2 dev / klein 4B / klein 9B, FLUX.1 schnell, Leonardo Lucid Origin and Phoenix, SDXL variants
Text embeddings	7	`bge-m3`, `bge-*-en-v1.5`, `embeddinggemma-300m`, `qwen3-embedding-0.6b`, `plamo-embedding-1b`
Speech recognition	5	Deepgram `nova-3` and `flux`, Whisper large-v3-turbo
Text-to-speech	4	Deepgram Aura 1/2, MeloTTS
Classification / reranking	2	`bge-reranker-base`, DistilBERT SST-2
Image-to-text	2	`moondream3.1-9B-A2B`, LLaVA 1.5
Translation	2	IndicTrans2, M2M100
Image classification	1	ResNet-50
Voice turn detection	1	Pipecat `smart-turn-v2`
Total	69

One model in that list has no outside equivalent. Clef is Cloudflare's own 27B multimodal "decision model." You give it a state (text, JSON, or images) and up to 64 typed questions (noul, choice, score), and it returns a probability for every allowed answer. Input costs $0.24 per million tokens and output tokens are free. It is built for routing, triage, and scoring, where people currently ask a chat model for JSON and hope it parses.

The scoreboard

To compare models, I used the Artificial Analysis Intelligence Index. It is currently at v4.3.2 and is a weighted average of 10 evaluations that Artificial Analysis runs itself: agents (30%), coding with Terminal-Bench 4.0 and SciCode (20%), general knowledge and long-context (30%), and scientific reasoning with HLE and CritPt (20%). Full weights are in the methodology page. It is English-only and text-only, and it tells you nothing about speed on Cloudflare specifically. It is still the most consistent independent yardstick available.

Each model is shown at its highest-effort setting:

Model	Hosted where	Index	% of #1	Gap
Claude Opus 5.5	Anthropic (via Gateway)	58	100%	—
Claude Sonnet 5.5	Anthropic (via Gateway)	56	97%	−2
GPT-6 Astra	OpenAI (via Gateway)	53	91%	−5
Gemini 4 Argon	Google (not in Cloudflare's catalog)	53	91%	−5
GPT-6.1 Sol	OpenAI (via Gateway)	52	90%	−6
MiMo-V2.6-Pro	Xiaomi (not on Cloudflare)	46	79%	−12
GLM-5.3	Workers AI	45	78%	−13
GLM-5.3-Flash	Workers AI	42	72%	−16
DeepSeek V4 Pro 0813	Workers AI	36	62%	−22
Qwen3.8 27B	Workers AI	34	59%	−24
Kimi K2.7 Code	Workers AI	26	45%	−32
Gemma 4 26B A4B	Workers AI	17	29%	−41
Nemotron 3 Super	Workers AI	13	22%	−45
gpt-oss-120b	Workers AI	12	21%	−46
Llama 4 Scout	Workers AI	8	14%	−50
Llama 3.3 70B	Workers AI	8	14%	−50

The open-weight frontier is on Cloudflare, with one exception. GLM-5.3 is the #2 open-weight model on the board, one point behind Xiaomi's MiMo-V2.6-Pro (46), which Workers AI doesn't host. Kimi K3 (44) isn't on Workers AI either, though you can reach it as a third-party model through the unified catalog. Within the open-weight field, Cloudflare is close to the top.

The closed lead is about 13 points, and it is real. A 45 lands around the level of Claude Haiku 5.5 at max effort (43) and GPT-5.6 Terra at max (42). That is a strong model. It is not Opus.

The models people already have in their code are far behind. If your Worker still calls llama-3.3-70b-instruct-fp8-fast, you are running a model that scores 8. Changing one string to glm-5.3-flash gets you to 42.

Two caveats before you trust a column of numbers:

Effort settings differ. GLM-5.3 defaults to max on Workers AI, so the score above is what you get by default. DeepSeek V4 Pro defaults to high, while the 36 was measured at max. Set reasoning_effort: "max" if you want that number.
Same weights, different stack. Artificial Analysis benchmarks these models on the makers' own APIs. Cloudflare serves the same weights on its own engine, with its own quantization and kernels. Artificial Analysis lists Cloudflare as a provider only for gpt-oss, Gemma 4, Llama 4 Scout, and Llama 3.3, and publishes no speed figures for it. Treat the hosted scores as very likely, not guaranteed.

What it costs

Workers AI bills in Neurons at $0.011 per 1,000, with 10,000 free Neurons per day on both plans (pricing). For LLMs, Cloudflare also publishes per-token equivalents, so you can ignore Neurons and compare dollars directly.

Cloudflare charges the same per-token rates as the model makers' own APIs.

Model	Workers AI (in / out per 1M)	First-party API (in / out)
GLM-5.3	$1.40 / $4.40	$1.40 / $4.40 (Z.ai)
GLM-5.3-Flash	$0.15 / $0.50	$0.15 / $0.50 (Z.ai)
DeepSeek V4 Pro 0813	$1.32 / $3.96	$1.32 / $3.96 (DeepSeek)

First-party prices are as reported on the Artificial Analysis model pages for GLM-5.3, GLM-5.3-Flash, and DeepSeek V4 Pro.

For comparison, closed models through the same binding:

Model	Input	Cached input	Output
Claude Opus 5.5	$4.00	$0.20	$20.00
GPT-6 Astra	$10.00	$1.00	$50.00
GPT-6.1 Sol	$2.00	$0.10	$10.00

Prices come from Anthropic pricing; GPT-6 prices from Artificial Analysis and eesel.ai's summary of OpenAI's pricing page. AI Gateway passes these through with no markup, plus a 5% fee on credit purchases.

A worked example with an agent fleet

List prices mislead for agent workloads because most input tokens are cache hits. So I priced a concrete day:

50M input tokens, 80% cache hits
2M output tokens
Uncached input, cached input, and output each billed at the rates above. Models without a published cached price pay full input.

Model	Index	$/day	$/30 days	vs Opus 5.5
GPT-6 Astra	53	$240.00	$7,200	2.7× more
Claude Opus 5.5	58	$88.00	$2,640	1.0×
GPT-6.1 Sol	52	$44.00	$1,320	2.0× cheaper
GLM-5.3	45	$33.20	$996	2.7× cheaper
Qwen3.8 27B	34	$28.90	$867	3.0× cheaper
DeepSeek V4 Pro	36	$22.88	$686	3.8× cheaper
gpt-oss-120b	12	$19.00	$570	4.6× cheaper
GLM-5.3-Flash	42	$3.70	$111	23.8× cheaper

What the table shows:

GLM-5.3 is only 1.3× cheaper than GPT-6.1 Sol on this workload and scores 7 points lower, because caching narrows the gap. GLM-5.3's cached input costs $0.26 per million on Workers AI, while Sol's costs $0.10 and Opus's costs $0.20. Once 80% of input is cached, the big list-price gap mostly disappears. If your workload is heavily cached, the flagship open model is not the bargain its sticker price suggests.
GLM-5.3-Flash is the real value story. It scores 42 at $3.70 a day, which is 9× cheaper than GLM-5.3 for 3 fewer points. It is also 5× cheaper than gpt-oss-120b, which has no cached-input discount and scores 12.
Artificial Analysis's own cost to run the full index tells the same story: $5.98 for Opus 5.5, $2.01 for GLM-5.3, and $0.25 for GLM-5.3-Flash. Per point of index score, Flash comes out about 17× ahead of Opus.

Cloudflare's own numbers point the same way. When it launched Kimi K2.5 in March, Cloudflare said an internal security-review agent processing over 7 billion tokens a day would have cost about $2.4M a year on a mid-tier proprietary model, and that moving it to Workers AI cut costs by 77%. That is a vendor estimate, but the direction matches the table.

Why Cloudflare can serve trillion-parameter models

A year ago, a 1T-parameter model on Workers AI would have sounded like a mistake. A few infrastructure changes made it workable:

Infire, a Rust inference engine that replaced vLLM in Cloudflare's stack. In Cloudflare's August 2025 benchmark on an H100 NVL, it served 17,224 tokens/s against 16,164 for vLLM 0.10.0 at 25% CPU instead of 140%. The CPU savings matter most because Cloudflare can run it bare-metal instead of under gVisor.
Prefill/decode disaggregation. Prompt processing and token generation run on separate servers behind a token-aware load balancer. Cloudflare reports p90 inter-token latency falling from about 100 ms to 20–30 ms.
Session-affinity prompt caching. Send an x-session-affinity header and your requests stick to the node holding your KV cache. Mooncake moves cache between nodes and spills it to NVMe. Internal heavy users raised their cache hit rate from 60% to 80% at peak.
Speculative decoding with NVIDIA's EAGLE-3 draft model, which helps most on predictable output like tool calls and JSON.
Unweight, Cloudflare's lossless weight compression, which it says cuts model size by about 15–22%.

Kimi K2.5 alone is about 560 GB of weights and needs at least eight H100s just to load. Cloudflare says it now starts in under 20 seconds and runs about 3× faster than at launch.

The fine print that bites

Rate limits

This is the one most likely to stop a project. Workers AI's general LLM limit is 300 requests per minute. The paid-only models (GLM-5.2, GLM-5.3, GLM-5.3-Flash, Kimi K2.6, Kimi K2.7 Code, DeepSeek V4 Flash, and DeepSeek V4 Pro) are limited to 20 requests per minute per model per account, or 50 if you pay through AI Gateway credits. That is at most 28,800 requests a day at 20 RPM. That is fine for a coding agent but limiting for a consumer chat app. Higher limits require a form.

Paid plan only

Those same models require Workers Paid or prepaid Gateway credits. The free 10,000 Neurons per day is worth $0.11 and is meant for small models.

Context windows aren't always what the model card says

GLM-5.3 and DeepSeek V4 Pro get the full ~1M tokens on Workers AI. But llama-3.3-70b-instruct-fp8-fast is capped at 24,000 tokens, compared with 128k upstream, and its default max_tokens is 256. Check the model page, not the Hugging Face card.

You can't turn GLM-5.3's reasoning off

It supports low, high, and max. Legacy values like none and medium are silently mapped to max, which is the most expensive setting. If you are porting code that sends reasoning_effort: "none", your bill will go up.

Models get retired

Cloudflare deprecated 18 models on May 30, 2026. kimi-k2.5 became an alias for the more expensive K2.6. Pin versions where Cloudflare offers dated IDs (-0813, -0731) and watch the changelog.

What I'd actually build

The setup that makes sense today is a router. Start on the cheap hosted model and escalate to a frontier model when needed, through the same env.AI binding:

export interface Env {
  AI: Ai;
}

export default {
  async fetch(req: Request, env: Env): Promise<Response> {
    const { prompt, hard } = await req.json<{ prompt: string; hard?: boolean }>();

    // Default: Cloudflare-hosted, index 42, $0.15 / $0.50 per 1M tokens
    if (!hard) {
      const r = await env.AI.run("@cf/zai-org/glm-5.3-flash", {
        messages: [{ role: "user", content: prompt }],
      });
      return Response.json(r);
    }

    // Escalation: Claude Opus 5.5 via the unified catalog, index 58
    const r = await env.AI.run("anthropic/claude-opus-5.5", {
      max_tokens: 2048,
      messages: [{ role: "user", content: prompt }],
    });
    return Response.json(r);
  },
} satisfies ExportedHandler<Env>;

Clef is a natural fit for deciding hard. It returns calibrated probabilities instead of free text, and output tokens are free.

My picks by job:

glm-5.3-flash is my default workhorse. It scores 42, costs very little, has 1M context, and accepts images.
glm-5.3 handles the hardest open-weight jobs, but price it against GPT-6.1 Sol if your workload is heavily cached.
clef or clef-flash handles classification, routing, and triage.
Opus 5.5 or GPT-6.1 Sol through AI Gateway covers anything at the frontier. You still get one binding and one bill.
Retire the Llama 3.x and gpt-oss calls in existing code now. For general reasoning, they are a generation behind.

The gap between Workers AI and the frontier is about 13 index points. The gap between the Workers AI models people use and the ones Cloudflare now offers is about 34. For most teams, the second gap is the one to close first.

Method

The catalog comes from the Workers AI models page, all 69 entries extracted and de-duplicated.
Scores come from the Artificial Analysis leaderboard, Intelligence Index v4.3.2, checked October 9 and 11, 2026. Scores from older index versions were not mixed in. Kimi K2.6, GLM-5.2, and DeepSeek V4 Flash 0731 are hosted on Workers AI but not on the current board.
Prices come from Cloudflare's pricing page (updated October 9, 2026), Anthropic's pricing docs, and Artificial Analysis model pages. GPT-6 prices were confirmed against a second source that cites OpenAI's page. Gemini 4 Argon's price was only available from Artificial Analysis, so it is left out of the cost tables.
All ratios and the workload table come from a script, not mental math.
I didn't measure latency or throughput on Cloudflare's network, or the quality of the image and speech models.

Sources

Dynamic workflows in Claude Code move the plan out of the context window

Sat, 10 Oct 2026 00:00:00 GMT

Dynamic workflows are simply the most interesting change to Claude Code this year. Claude stops being the orchestrator and starts writing one. Instead of juggling subagents turn by turn, Claude writes a short JavaScript program, a runtime runs it in the background, and only the final answer comes back into the conversation. That makes big agent jobs something you can read, rerun, and resume, like ordinary code.

I found them by accident. I manage a lot of projects, and I'd asked Claude to go through all their project directories, audit each CLAUDE.md file, and bring them in line with one standard (limits and formatting to save tokens), while keeping whatever was unique to each project. Then the background tasks window popped open and a couple dozen agents were working at once, each project going through its own audit, rewrite, and verify phases. It was amazing to watch, so I went and figured out what had just happened.

Every multi-agent setup eventually hits the same wall. The orchestrator is itself an LLM conversation. Each subagent result lands in its context, every "what next?" decision costs a turn, and somewhere around a few dozen delegations the coordinator starts losing the thread.

Workflows shipped as a research preview on May 28, 2026 and are now generally available. Loops, branching, retries, and intermediate results live in script variables, not in Claude's context.

Below, I cover how to trigger one, what the script looks like, how resume and caching work, what it costs, and where I think it does and doesn't fit.

Where workflows sit

Claude Code now has several ways to run work in parallel. The distinction I find most useful, and the one the docs draw, is who holds the plan:

	Subagents	Skills	Agent teams	Workflows
Who decides what runs next	Claude, turn by turn	Claude, following a prompt	A lead agent, turn by turn	The script
Where intermediate results live	Claude's context	Claude's context	Shared task list	Script variables
What's repeatable	Worker definition	Instructions	Team definition	The orchestration itself
Typical scale	A few tasks per turn	Same as subagents	A handful of peers	Dozens to hundreds of agents
On interruption	Turn restarts	Turn restarts	Teammates keep going	Resumable in-session

The last two rows are the ones that matter. Because the plan is code, it's deterministic, diffable, rerunnable, and checkpointable. That also means quality patterns like fan-out-then-verify, adversarial review, and judge panels get baked into the script, instead of hoping the model remembers them on turn 40.

How to start one

There are five ways in.

The keyword, per task. Put ultracode anywhere in your prompt, or just ask in plain English ("use a workflow"). Claude Code highlights the keyword, and Claude writes a script instead of working turn by turn.

ultracode: audit every API endpoint under src/routes/ for missing auth checks

Changed your mind? Option+W (macOS) or Alt+W (Windows/Linux) dismisses the highlight for that prompt, and you can turn the keyword off entirely in /config.

Ultracode, per session. /effort ultracode tells Claude to plan a workflow for every substantive task, so one request can become a chain of workflows: one to understand the code, one to change it, and one to verify. Start a session this way with claude --effort ultracode (which also sets effort to xhigh), persist it with the ultracode setting, and turn it off with /effort ultracode off. Ultracode is a toggle, not an effort level. It needs a model that supports xhigh, and it disappears if workflows are disabled (model config docs).

The bundled workflow. /deep-research <question> fans out web searches across several angles, cross-checks the sources, votes on each claim, and returns a cited report with refuted claims removed. Claims the verifiers couldn't check (rate limits, API errors) are listed as unverified rather than counted as false. It's the fastest way to watch the machinery run.

I've only used it briefly, and it's pretty great. For some subjects it's heavier than the question needs, so it depends on what you're researching.

Saved workflows. When a run does what you wanted, open /workflows, select it, and press s. It becomes a /<name> command, saved to .claude/workflows/ (shared through the repo) or ~/.claude/workflows/ (personal). Saved workflows take input through an args global, so Run /triage-issues on 1024, 1025, and 1030 passes a real array. No string parsing.

Plugins. Drop scripts in a plugin's workflows/ directory and they ship namespaced. A release-audit workflow in plugin acme-tools runs as /acme-tools:release-audit.

Upgrade if you run Claude Code on untrusted text

As of v2.1.210, the ultracode keyword only counts when you typed it, whether at the interactive prompt, in an IDE panel, through Remote Control, or in an SDK app that marks input as human. It no longer triggers from -p prompts, scheduled tasks, webhook payloads, or PR comments relayed into the session. Before that version, a PR comment containing the word could launch a fan-out. If you point Claude Code at text other people write, upgrade.

What the script looks like

You'll rarely write these by hand, but you should be able to read one. Here's a sketch of a fix-until-green loop using the primitives the docs describe:

export const meta = {
  name: 'fix-types',
  description: 'Run tsc and fix errors until clean or stalled',
}

let stalls = 0
let lastCount = Infinity

while (stalls < 2) {
  phase('Check')
  const report = await agent('Run `npx tsc --noEmit` and list every error by file.', {
    schema: {
      type: 'object',
      required: ['errors'],
      properties: {
        errors: {
          type: 'array',
          items: {
            type: 'object',
            required: ['file', 'message'],
            properties: { file: { type: 'string' }, message: { type: 'string' } },
          },
        },
      },
    },
  })

  if (report.errors.length === 0) return 'Type check passes.'
  stalls = report.errors.length >= lastCount ? stalls + 1 : 0
  lastCount = report.errors.length

  phase('Fix')
  const byFile = Object.groupBy(report.errors, e => e.file)
  await pipeline(Object.keys(byFile), file =>
    agent(`Fix these type errors in ${file}:\n${byFile[file].map(e => e.message).join('\n')}`, { label: file }),
  )
}

return `Stopped: no progress for two rounds (${lastCount} errors remain).`

The API is small:

agent(prompt, opts) spawns one subagent. Pass a JSON schema and you get validated JSON back instead of prose. Failing outputs are retried (five attempts by default, tunable with MAX_STRUCTURED_OUTPUT_RETRIES), and self-contradictory schemas are rejected before the agent starts.
pipeline(items, fn) runs one agent per item. parallel(...) runs a set and waits for all of them.
phase(title) groups agents in the progress view, and log() prints above the phases.
A stopped or failed agent resolves to null, which is why scripts tend to end with .filter(Boolean).

The constraints are deliberate, and I think they're the right ones:

No filesystem or shell in the script. Agents do the work; the script only coordinates.
No import(). Library work happens inside an agent's task.
No nondeterminism. Date.now(), Math.random(), and a bare new Date() throw, so pass timestamps in through args. This is what lets resume replay the same agent() calls.
No mid-run user input. If you need to sign off between stages, make each stage its own workflow.

Runtime behavior worth knowing

Concurrency and caps. Up to 16 agents run at once by default (fewer on CPU-limited machines), adjustable from 1 to 256 with CLAUDE_CODE_WORKFLOW_MAX_CONCURRENT_AGENTS. A single parallel() or pipeline() call takes at most 4,096 items and errors past that rather than silently truncating. A whole run is capped at 1,000 agents to stop runaway loops.

Shared prompt cache. Agents with the same model, effort, agent type, tools, schema, and working directory build the same prompt prefix. In a fan-out, the runtime holds back all but the first matching agent until its response starts (up to 5 seconds, set by CLAUDE_CODE_WORKFLOW_PREFIX_STAGGER_MS), then releases the rest so they read a warm cache instead of each paying for the prefix. Workflow agents get a 5-minute cache TTL by default. For long runs, set subagentPromptCacheTtl to 1h and accept the higher write rate.

Resume is replay. Relaunching a stopped run replays agents in the order they started. Completed agents return saved results, up to the first agent whose prompt differs from the previous run; after that, everything reruns. A failed agent reruns along with every agent that started after it, even completed ones. So if A, B, C, and D start in order and B fails, a relaunch reuses A and reruns B, C, and D. Design long fan-outs so failures are absorbed (inside pipeline(), a failure becomes null and the run continues) rather than awaited directly, which ends the run.

Stalls fix themselves. An agent that goes quiet too long restarts from the same prompt, up to five times. Files it already changed stay changed. Lengthen the window per agent with stallMs, or globally with CLAUDE_ASYNC_AGENT_STALL_TIMEOUT_MS.

Usage limits pause the run instead of failing it. On an interactive subscription session (v2.1.271+), agents that hit your usage limit wait for the reset and the run carries on. There are limits to that. Resets more than 24 hours out, and a third limit hit, still fail the agent.

The script is a file, at least according to the docs. Every run writes its script under ~/.claude/projects/, where you can read it, diff it against the last run, edit it, and ask Claude to relaunch from your edit. I went looking for mine and couldn't find it, so I can't vouch for that part yet. Saving a run from /workflows as a reusable command works, and that's the part I care about.

Watching and steering a run

/workflows lists runs and opens a progress view with per-phase agent counts and live token usage. Open any agent to see its prompt, recent tool calls, and result. The keys you'll use: p pauses and resumes, x stops an agent or the whole run, r restarts a running agent, f filters by status, and s saves the script as a command. A one-line summary also sits in the task panel under the input box.

Permissions

How a launch gets approved depends on your permission mode:

In auto mode, you're asked on the first launch only, and not at all with ultracode on. Anthropic recommends auto mode for workflows.
In manual or accept-edits mode, you're asked every run, with the planned phases shown and an option to view the raw script (Ctrl+G opens it in your editor). Bundled, saved, and plugin workflows can be set to "don't ask again" per project.
claude -p and the Agent SDK never prompt, because the Workflow tool goes through normal permission evaluation. Allow Workflow (all) or Workflow(<name>) (one saved workflow), or approve through auto mode, a PreToolUse hook, or canUseTool.

The agents themselves get no special treatment. They follow the same permission rules and the same sandboxing. To keep a long run from stalling on prompts, add the tools it needs to your allow rules before you start. One subtle point: in auto mode, prompts a script passes to agent() are marked as script-computed, so the classifier doesn't treat them as instructions from you.

Cost is the part to take seriously

Workflows burn a lot more tokens than doing the same task in conversation, and on a subscription that counts against your limits. The guardrails:

A "Large workflow" warning appears when a run schedules more than 25 agents or projects past 1.5M tokens. It's advisory and doesn't stop anything.
A size guideline (workflowSizeGuideline or /config) nudges how many agents Claude plans: small (under 5), medium (under 10, the default), large (under 50), or unrestricted. Pro defaults to small on v2.1.271+. It's advice to Claude, not a hard cap.
You can pick the model per stage. Agents default to your session model; ask Claude to put mechanical stages on a smaller one, or set CLAUDE_CODE_SUBAGENT_MODEL.
Pilot on a slice. Run it on one directory first, watch the token column in /workflows, then scale up.

Ultracode deliberately removes the large-run warning and the concurrent-subagent limit, because turning it on counts as consent to big runs. I'd leave it off for routine work.

For a sense of scale, my CLAUDE.md audit took my session usage on the Pro plan from about 11% to 48%. I knew it would cost something, and the amount still surprised me a little. It didn't come close to my weekly limit, and it was completely worth it.

The big case study is Bun's move from Zig to Rust

The launch post's showcase was Jarred Sumner's port of Bun from Zig to Rust. It produced roughly 750,000 lines of Rust, passed 99.8% of the existing test suite, and took eleven days from first commit to merge. It's a chain of workflows with one job each. One mapped the correct Rust lifetime for every struct field. The next ported each .zig file to a behavior-identical .rs file, using hundreds of agents and two reviewers per file. A fix loop then drove the build and tests until both were clean. An overnight workflow afterward hunted for unnecessary copies and opened a PR per fix.

Sumner's own write-up, via Simon Willison, and later coverage fill in the details: around 50 workflows over the 11 days, a PORTING.md mapping Zig idioms to Rust plus a lifetimes table as the key inputs, and a peak of four concurrent workflows at 16 agents each, which is 64 agents in parallel across separate worktrees. He describes watching the runs, reading outputs, and having Claude adjust the loops as problems surfaced. Claude Code itself has shipped on the Rust build of Bun since v2.1.181.

It isn't an uncontested success. The Register reported the run cost about $165,000 at API pricing. InfoQ noted the mechanical translation introduced 19 subtle regressions, where Zig and Rust code looked alike but behaved differently. And Zig creator Andrew Kelley publicly criticized the rewrite, asking how a test suite that missed bugs in Zig would catch them in machine-written Rust. I read the case study as a demonstration of scale, and of how much verification you'll need, not as proof the output is correct.

Other early users reported smaller wins. Klarna's engineering team used workflows to find dead code and cleanup opportunities that static analysis missed, and CyberAgent described them as filling the gap between a single subagent and a full agent team.

When I'd reach for one

Good fits are work that's wide, repetitive, or needs independent checking:

The same audit across many files (auth checks, input validation, unsafe patterns), with each finding adversarially verified
Large migrations, with each file transformed in an isolated copy
Fix-until-green loops on a type checker, linter, or test suite
Search-until-saturated jobs, like a flaky-test hunt that stops after two rounds find nothing new
Research where sources need to be checked against each other
High-stakes plans you want drafted from several angles and compared

Poor fits:

Small tasks that fit comfortably in one context. You pay the fan-out overhead for nothing.
Anything that needs your judgment mid-run. Split it into separate workflows instead.
Work where you can't verify the output. More agents just produce more unverified code, faster.

If you already have orchestration built another way, like a folder of subagent prompts or a skill that fans out, you can point Claude at it and ask for an equivalent workflow.

Availability and off switches

Workflows need Claude Code v2.1.154+ and are available on Pro, Max, Team, and Enterprise, through the Anthropic API, and on Amazon Bedrock, Google Cloud, and Microsoft Foundry. They're on by default except on Pro, where you turn on the Dynamic workflows row in /config. They run in the CLI, the Desktop app (progress shows in the Background tasks pane), IDE extensions, claude -p, and the Agent SDK.

To turn them off, use the toggle in /config, set "disableWorkflows": true, or export CLAUDE_CODE_DISABLE_WORKFLOWS=1. Admins can enforce the same through managed settings or the Claude Code admin page. Disabling workflows also removes ultracode and /deep-research.

My take

Orchestration moved out of a model's turn-by-turn judgment and into a program the model writes, which you can read, edit, rerun, save, and resume. That makes agent work at codebase scale look a lot more like normal engineering: a script, a progress view, a cost meter, and a verification step you can inspect.

If you want to try it, start with /deep-research to watch it run, then try ultracode: on one scoped audit, and save the first workflow that earns its tokens.

Sources

What the research says about fan-out-then-verify, adversarial review, and judge panels

Thu, 08 Oct 2026 00:00:00 GMT

In my post on dynamic workflows I wrote that workflows let you bake quality patterns like fan-out-then-verify, adversarial review, and judge panels into a script. I then went and read the research behind those three patterns, because "more agents checking each other" sounds like it should work and I wanted to know if it does.

Mostly it does, but not for the reasons the names suggest. The gains come from two places. The first is sampling several independent answers and voting. The second is a checker that knows something the generator doesn't, such as a test suite, a different model, or a reviewer with a fresh context. Agents arguing with each other and panels of judges that share a base model mostly cost tokens.

The short version:

Generating more attempts is cheap and reliably finds more right answers. Picking the right one is the hard part, and an imperfect checker caps how good the result can get.
Majority voting explains most of what's been credited to multi-agent debate. At equal compute, plain voting usually wins.
Asking a model to critique its own answer, with no outside signal, often makes the answer worse.
Judge panels beat a single judge mainly when the judges come from different model families. Even then, nine judges behaved like about two independent votes in a 2026 study.
In Claude Code, you can get all of this with a one-line prompt, a saved workflow, a reviewer subagent on a different model, or a Stop hook that runs your tests.

All papers below were checked against their full text in October 2026, and I looked for peer reviews or replications where they exist.

Generating is easy, picking is hard

The cleanest evidence comes from inference-time scaling, which means spending more compute when you run a model rather than when you train it.

Large Language Monkeys (Brown et al., 2024) measured "coverage," the share of problems where at least one of many attempts is correct. On SWE-bench Lite, DeepSeek-Coder-V2-Instruct solved 15.9% of problems with one attempt and 56% with 250 attempts. The best single-attempt result at the time was 43%. So the right answer was usually somewhere in the pile.

Getting it out of the pile was the problem. Without an automatic checker like unit tests, the paper found that majority voting and reward models "plateau beyond approximately 100 samples" while coverage keeps climbing. (The abstract says "several hundred"; the body says about 100.) The paper was rejected at ICLR 2025, with reviewers arguing the coverage curves are what you'd expect mathematically. That's fair, and it doesn't change the gap between finding and picking.

Stroebl, Kapoor, and Narayanan put a hard number on why. If your checker ever accepts a wrong answer, resampling can't push that error rate down, so there's a ceiling "regardless of compute budget." On coding benchmarks with thin unit tests, they found "optimal sampling attempts are often fewer than 10." It was accepted at ICLR 2026 as a borderline poster; reviewers worried it generalizes too much from coding.

Checkers also get fooled in embarrassing ways. One Token to Fool LLM-as-a-Judge (Zhao et al., 2025) sent judges answers that contained no reasoning at all, just a colon or the words "Thought process:", and counted how often the judge marked them correct. Averaged across their ten "master key" responses and five benchmarks:

Judge	Average false-positive rate
GPT-o1	6.0%
Claude-4 Sonnet	12.4%
GPT-4o	14.6%
Qwen2.5-72B	66.8%
LLaMA3-70B	80.6%

A lone ":" got Claude-4 to accept 53.6% of answers on MATH. The paper was rejected at ICLR 2026, partly because reviewers saw it as another form of reward hacking and the judges weren't the newest. I still find it a useful warning. A judge that only reads the answer can be fooled by its shape.

Fan-out-then-verify

This is the pattern with the strongest evidence. Fan out several attempts, check them, and keep what survives.

The simplest version is voting. Self-consistency (Wang et al., ICLR 2023) samples 40 reasoning paths and takes the most common answer. On the GSM8K math benchmark it lifted PaLM-540B from 56.5% to 74.4%, a gain of 17.9 points. More Agents Is All You Need (Li et al., TMLR 2024) found the same effect across model sizes. With 15 samples and a vote, Llama2-13B matched a single Llama2-70B on GSM8K. Voting has limits, though. Chen et al. showed that past a point, more calls can make voting worse, because extra samples help on easy questions and hurt on hard ones.

A trained checker does better than a vote. OpenAI's GSM8K paper (Cobbe et al., 2021) sampled 100 solutions per problem and let a trained verifier pick one. They said this gave "approximately the same performance boost as a 30x model size increase." The same paper also found the verifier got worse past about 400 samples, because more samples meant more wrong answers good enough to fool it. Let's Verify Step by Step (Lightman et al., ICLR 2024) compared checking each step against checking only the final answer, picking the best of 1,860 attempts on MATH problems:

Selection method	Accuracy
Majority vote	69.6%
Checks final answer only	72.4%
Checks every step	78.2%

The authors say the two checkers were trained on different data and "are not directly comparable," and ICLR reviewers flagged reproducibility because the model sizes weren't disclosed. A 2025 Qwen paper also argues that best-of-N tests flatter step checkers, so treat the exact gap loosely.

This is how Anthropic's own tools are built. The Claude Code Review docs say "a verification step checks candidates against actual code behavior to filter out false positives." The public code-review plugin shows the shape. Four reviewers run in parallel (two on Sonnet for CLAUDE.md rules, two on Opus for bugs), then a separate subagent validates each issue, and anything not validated is dropped. The built-in /deep-research workflow "votes on each claim," and when a verifier can't check a claim, say after a rate limit, it lists the claim "as unverified instead of counting it as refuted." I think that last rule matters more than it looks. A checker that fails is not a checker that disagrees.

Adversarial review and debate

Adversarial review means a second agent tries to break the first agent's answer. Debate is the multi-round version, where agents read each other's answers and revise.

Debate had a strong start. Du et al. (ICML 2024) ran three GPT-3.5 agents for two rounds and got 85.0% on GSM8K, against 81.0% for a majority vote and 77.0% for a single agent. But debate used more model calls than the vote it beat, and each benchmark had only about 100 questions.

When others matched the compute, the advantage went away.

Huang et al. (ICLR 2024) re-ran debate on the full GSM8K set. With 9 responses, debate scored 83.0% and self-consistency scored 88.2%.
Should we be going MAD? (Smit et al., ICML 2024) found debate didn't reliably beat self-consistency or ensembling. On MMLU with GPT-3.5, self-consistency scored 0.78 and a debate setup scored 0.73.
Stop Overvaluing Multi-Agent Debate (Zhang et al., 2025) tested 5 debate methods on 9 benchmarks with 4 models, and found no method beat plain chain-of-thought in more than 20% of the 36 settings. It's a position paper, not peer-reviewed.
Debate or Vote (Choi, Zhu, and Li, a NeurIPS 2025 spotlight) concluded that majority voting "alone accounts for most of the performance gains typically attributed to" debate. They also proved that debate on its own is a martingale, meaning the expected accuracy doesn't improve from round to round.

More rounds made it worse in that study. A big part of the reason is conformity. Talk Isn't Always Cheap (Wynn, Satija, and Hadfield, an ICML 2025 workshop paper) found agents flip from right to wrong more often than wrong to right, and a correct agent is most likely to cave when it's the only one holding that answer. Three Mistral agents on MMLU went from 33.6% before debate to 24.4% after.

Self-critique without an outside signal has the same problem. Huang et al. asked models to review and fix their own answers with no new information. GPT-4 on GSM8K dropped from 95.5% to 89.0%, and GPT-3.5 on CommonSenseQA fell from 75.8% to 41.8%. The model mostly talked itself out of right answers.

So where does adversarial review work? When the reviewer brings something new. Cemri et al.'s study of 1,642 multi-agent traces (NeurIPS 2025) found that verification problems, such as checking too little, checking wrongly, or stopping early, caused 23.5% of failures. Two 2026 security preprints show what a good adversarial checker looks like in practice.

Refute-or-Promote (Agarwal) used "kill" agents to reject about 79% of 171 vulnerability candidates, leading to 4 CVEs. A critic from a different model family found problems in 3 of 19 fixes that same-family reviewers had approved. Its two failure stories are the most useful part. Ten agents unanimously endorsed a false finding that one empirical test killed, and one real vulnerability was unanimously killed and later became CVE-2026-41254.
OpenAnt (Korda and Evron) had agents simulate an attacker against each finding, which cut 376 findings to 190. Of those 190, 144 (75.8%) produced working exploits.

Both are single-team preprints with no ablation, so they show the pattern can work, not how much it adds. I looked for a controlled study comparing a "try to refute this" prompt against a neutral "check this" prompt at equal compute and didn't find one, in more than ten targeted searches. The closest is Qiu and Gill, where making disagreement explicit raised F1 from 0.457 to 0.533 on 100 examples. If you know of a better study, I'd like to read it.

Judge panels

A judge panel has several models score the same output and combines their votes. It exists because single LLM judges have well-documented biases. The original MT-Bench paper (Zheng et al., NeurIPS 2023) found GPT-4 agreed with human raters 85% of the time, slightly more than humans agreed with each other (81%). But it also found:

Position bias. When the same answer pair was shown in swapped order, GPT-4 gave a consistent verdict only 65.0% of the time, and Claude-v1 23.8%.
Verbosity bias. Padding an answer with a repetitive list fooled GPT-3.5 and Claude-v1 91.3% of the time (GPT-4, 8.7%), though only 23 answers were tested.
A possible preference for its own answers, which the authors said they couldn't confirm with their data. Panickssery, Bowman, and Feng (NeurIPS 2024) later showed GPT-4 could pick out its own summaries 73.5% of the time, and that self-preference rose with self-recognition. A 2025 follow-up found much of that preference is earned, because the stronger model's output really is better.

Pairwise or Pointwise? (Tripathi et al., COLM 2025) adds a practical note. When distracting features were added to answers, pairwise "which is better" verdicts flipped in about 35% of cases, against about 9% for scoring each answer on its own.

The case for panels comes mostly from Replacing Judges with Juries (Verga et al., Cohere, 2024). A panel of three smaller models from three families (Command R, Claude 3 Haiku, and GPT-3.5) agreed with human annotators more than GPT-4 alone on all three QA datasets tested and was "seven to eight times less expensive." It has two caveats. Claude 3 Haiku alone beat the panel on one dataset. And when the authors gave GPT-4 a prompt that told it not to overthink, GPT-4 scored 0.725 on Natural Questions against the panel's 0.699. I couldn't find an independent replication or released code.

The case against is correlated errors. Kim et al. (ICML 2025) compared hundreds of models and found that when two models both get a HELM question wrong, they pick the same wrong answer 60% of the time, against 33% by chance. Models from the same provider agree more, and more capable models agree more. Goel et al. (ICML 2025) found judges score models higher the more similar those models are to themselves, with an average correlation of 0.84.

Nine Judges, Two Effective Votes (Kohli, 2026) measured this directly. Nine frontier judges from seven families behaved like 2.0 to 2.5 independent votes. The panel scored 8 to 22 points below what truly independent votes would have reached, and the best single judge matched or beat the panel on every dataset.

It's a single-author preprint on classification tasks that were picked for being ambiguous, and you'd need the answer key to know which judge is "best" in advance. But a follow-up with 32 judges reproduced the roughly two-vote result under the same measure, while showing other measures give between 2 and 6.5.

I read the two sides as consistent. A panel helps when you can't pick a strong single judge, when its members come from different families, and when the task has a reference answer. It helps much less when every judge shares the same blind spot. One note on a source people cite against panels. Anthropic's multi-agent research post says "a single LLM call with a single prompt" was more consistent than "multiple judges," but its multiple judges were one per scoring criterion, not a panel of different models.

How to build these in Claude Code

There are four levels, from least to most setup.

Ask in the prompt. Any prompt with the word ultracode, or one that says "use a workflow," makes Claude write a workflow script for the task. The docs' own example of fan-out-then-verify is:

use a workflow to audit every route handler under src/routes/ for missing authentication checks, and adversarially verify each finding before reporting it

For loop-until-dry, the docs suggest "stop once two rounds in a row find nothing new." Since v2.1.210 the keyword only works in prompts you type, not in -p runs or relayed PR comments. /effort ultracode turns on workflow planning for every task in the session, and /deep-research <question> runs the built-in research workflow.

Save the script. When a run does what you want, open /workflows, select it, and press s. It saves to .claude/workflows/ (shared with the repo) or ~/.claude/workflows/ (just you) and runs as /<name> afterward. Arguments reach the script as a global named args. The adversarial check from the /workflow-authoring reference looks like this:

const votes = await parallel(Array.from({length: 3}, () => () =>
  agent(`Try to refute: ${claim}. Default to refuted=true if uncertain.`, {schema: VERDICT})))
const survives = votes.filter(Boolean).filter(v => !v.refuted).length >= 2

Given the research above, I'd change two things. Give each skeptic a different job instead of three copies of the same prompt, and give at least one of them a way to run something. Here's my sketch of a judge panel that does both, with each judge on a different model and scoring answers one at a time instead of in pairs:

const JUDGES = [
  {model: 'opus',   lens: 'correctness: run the tests and check edge cases'},
  {model: 'sonnet', lens: 'does it meet every requirement in the task?'},
  {model: 'haiku',  lens: 'what would a maintainer object to?'},
]
const SCORE = {type: 'object', properties: {score: {type: 'number'}, reason: {type: 'string'}},
               required: ['score', 'reason']}

const scored = await parallel(candidates.map((c, i) => () =>
  parallel(JUDGES.map(j => () =>
    agent(`Score this candidate from 0 to 10 on ${j.lens}. Do not compare it to others.\n\n${c}`,
          {model: j.model, schema: SCORE})))
    .then(vs => ({i, total: vs.filter(Boolean).reduce((s, v) => s + v.score, 0)}))))

The per-agent model option counts as the per-invocation model in the subagent model order. All three are still Claude models, though. Claude Code doesn't route to non-Claude models, so a judge from another family has to come in through an MCP tool or an HTTP hook.

Use a reviewer subagent on a different model. A file in .claude/agents/ with a model field gives you a reviewer that doesn't share the main session's context or, if you choose, its model:

---
name: skeptic
description: Tries to refute a claimed fix or finding. Use before reporting a bug or closing a task.
tools: Read, Grep, Glob, Bash
model: opus
---

Assume the claim is wrong. Reproduce it by running code or tests where you can.
Reply REFUTED, CONFIRMED, or UNVERIFIED with the evidence. If you couldn't check it, say UNVERIFIED.

Make your tests the judge. A Stop hook can block Claude from finishing until a check passes. This agent hook, straight from the docs, runs the test suite first (agent hooks are marked experimental):

{
  "hooks": {
    "Stop": [
      {
        "hooks": [
          {
            "type": "agent",
            "prompt": "Verify that all unit tests pass. Run the test suite and check the results. $ARGUMENTS",
            "timeout": 120
          }
        ]
      }
    ]
  }
}

For code review specifically, /code-review takes an effort level from low (fewer, more confident findings) to max, and the ultra mode says "every reported finding is independently reproduced and verified."

What it costs

Verification is where the tokens go. Anthropic's research-system post says multi-agent systems use about 15 times the tokens of a chat. The best real-world number I found is in a public workflow script, adversarial-review.js in rosenfieldben/nyc-transit-live. Its header records a review that ran 6 finders with 3 verifiers per finding. It used 123 agents and about 8.3M tokens, and 117 of those agents were verifiers. Re-run with 29 agents and about 1.6M tokens, it still caught both critical bugs. The same script marks a finding UNVERIFIED rather than refuted when a verifier read the wrong commit, after that caused real bugs to be thrown out.

Claude Code shows a Large workflow warning when a run schedules more than 25 agents or is projected past 1.5 million tokens, and the default size guideline asks Claude to stay under 10 agents (under 5 on Pro). I'd start with one verifier per finding and only add more when the first round lets bad findings through.

Open-source options

If you don't use Claude Code, or want to see how others built these, here's what I found on GitHub. Stars and licenses were checked on October 11, 2026.

Project	Pattern	How	License
stanfordnlp/dspy	Best-of-N	`BestOfN` reruns a module and keeps the highest-reward attempt; `Refine` and `MultiChainComparison` sit alongside it	MIT
EleutherAI/lm-evaluation-harness	Voting	`MajorityVoteFilter` gives majority-vote accuracy over repeated samples	MIT
UKGovernmentBEIS/inspect_ai	Judge panel	The model-graded scorer accepts a list of grader models with a majority reducer	MIT
haizelabs/verdict	Judge panel with verification	Chains judge, verify, and max-vote units; the quickstart builds 3 verified judges plus a vote	MIT
promptfoo/promptfoo	Graders and red-teaming	`llm-rubric` takes a grader per assertion; `select-best` picks among outputs; a separate red-team suite	MIT
confident-ai/deepeval	Blind pairwise judging	Arena G-Eval hides which model produced each answer	Apache-2.0
prometheus-eval/prometheus-eval	Open judge model	Absolute (1 to 5) and pairwise grading with an open-weight judge	Apache-2.0
karpathy/llm-council	Judge panel	Several models answer, rank each other's anonymized answers, and a chairman writes the final one. The README calls it "99% vibe coded"	None
composable-models/llm_multiagent_debate	Debate	The code from Du et al.	None
Skytliang/Multi-Agents-Debate	Adversarial debate	One agent argues against another and a judge decides	GPL-3.0
hamelsmu/claude-review-loop	Cross-model review	A Claude Code stop hook sends the work to up to 4 parallel Codex reviewers before Claude can finish	None
hurttlocker/o8	Adversarial verify	A 17-line saved workflow with three skeptics, each with a different lens (correctness, reachability, regression); a claim survives if 2 of 3 can't refute it	MIT

Anthropic's code-review plugin is worth reading as a reference, but it isn't open source; the repo's license is "All rights reserved." Its README also still describes an older 0 to 100 confidence filter that the current command file replaced with validation subagents. Licenses matter here because three of the most-starred projects in this list have none, which means you can read the code but not legally reuse it.

What I'd do

My own results with these patterns have been mixed. Verification has caught real problems for me, and it has also burned tokens confirming things that were already right. The research above explains both.

My rules, after reading all of this, are short. Sample and vote before you reach for debate. Make the checker as independent as you can, preferably by running something, otherwise by using a different model or at least a fresh context. Treat "couldn't check" as its own result, not as a rejection. And spend verification tokens on the findings you're about to act on, not on every candidate.

If you only set up one thing, save a review workflow that adversarially verifies its findings, and run it on every branch. Save it once, and the checking happens every time without you having to ask for it.

Sources

Papers (checked against full text, October 2026):

Wang et al., Self-Consistency Improves Chain of Thought Reasoning in Language Models, ICLR 2023
Cobbe et al., Training Verifiers to Solve Math Word Problems, 2021
Lightman et al., Let's Verify Step by Step, ICLR 2024 (reviews)
Brown et al., Large Language Monkeys, 2024 (reviews)
Li et al., More Agents Is All You Need, TMLR 2024
Chen et al., Are More LLM Calls All You Need?, NeurIPS 2024
Stroebl, Kapoor, and Narayanan, The Limits of Inference Scaling Through Resampling, ICLR 2026 (reviews)
Zhao et al., One Token to Fool LLM-as-a-Judge, 2025 (reviews)
Du et al., Improving Factuality and Reasoning in Language Models through Multiagent Debate, ICML 2024
Huang et al., Large Language Models Cannot Self-Correct Reasoning Yet, ICLR 2024
Smit et al., Should we be going MAD?, ICML 2024
Zhang et al., Stop Overvaluing Multi-Agent Debate, 2025
Choi, Zhu, and Li, Debate or Vote, NeurIPS 2025
Wynn, Satija, and Hadfield, Talk Isn't Always Cheap, ICML 2025 workshop
Cemri et al., Why Do Multi-Agent LLM Systems Fail?, NeurIPS 2025
Agarwal, Refute-or-Promote, 2026 preprint
Korda and Evron, OpenAnt, 2026 preprint
Qiu and Gill, Adversarial Review, 2026
Zheng et al., Judging LLM-as-a-Judge with MT-Bench and Chatbot Arena, NeurIPS 2023
Panickssery, Bowman, and Feng, LLM Evaluators Recognize and Favor Their Own Generations, NeurIPS 2024
Qwen team, The Lessons of Developing Process Reward Models in Mathematical Reasoning, 2025
Chen et al., Do LLM Evaluators Prefer Themselves for a Reason?, 2025
Tripathi et al., Pairwise or Pointwise?, COLM 2025
Verga et al., Replacing Judges with Juries, 2024
Kim et al., Correlated Errors in Large Language Models, ICML 2025
Goel et al., Great Models Think Alike and this Undermines AI Oversight, ICML 2025
Kohli, Nine Judges, Two Effective Votes, 2026 preprint
Li, Yu, and Li, How Many Humans Are 32 LLM Judges Worth?, 2026 preprint

Docs and posts:

Claude Code docs: dynamic workflows, subagents, hooks guide, code review, ultrareview, LLM gateway
Anthropic, How we built our multi-agent research system, June 2025
Anthropic, code-review plugin command
rosenfieldben, adversarial-review.js

Max Zimmer

/loop, -p, the Agent SDK, and background sessions, untangled

Short version

/loop repeats a prompt in your session

-p runs one prompt, then exits

The Agent SDK is -p as a library

Background sessions keep going without a terminal

Why some sessions don't show up when you resume

Which one to start with

Sources

Claude Code now remembers where I work

What shipped

What an environment holds

Making one

Where they show up

A couple of rough edges

My take

Sources

Claude artifacts can talk back to your session

Five types

What a page can do

Sharing

Talking back to the session

Why it fails when you open it on its own

Can a dashboard run all your sessions?

My take

Sources

Git for people who started with Claude Code

Git and GitHub aren't the same thing

A repository is a folder with a memory

A commit is a save point

A branch is a parallel version

A remote is the copy somewhere else

A worktree is a second desk

Checkpoints aren't git

Setting it up from scratch

1. Install git

2. Tell git who you are

3. Make a GitHub account and sign in from the terminal

4. Create a repo

5. Keep secrets out

Undo, and what Claude asks first

How I'd start

Sources

I keep my Claude Code sidebar strict

Name your sessions

Sort sessions into sections

Archive what's closed

Why bother

My take

Sources

Nested sessions turn one Claude Code session into a switchboard

What shipped

How it works

The parent can talk to its children

How this differs from the other ways to run agents

What I use them for

Setting up the orchestrator pattern

Costs and rough edges

My take

Sources

Claude Code is also an MCP server. What!?

Flipping the usual direction

Setting it up

What it actually exposes

Why it flew under the radar

Be careful with it

When I'd use it

Sources

How close does Workers AI get to the frontier? An October 2026 scorecard

Two catalogs, not one

What's actually hosted

The scoreboard

What it costs

A worked example with an agent fleet

Why Cloudflare can serve trillion-parameter models

The fine print that bites

Rate limits

Paid plan only

Context windows aren't always what the model card says