One task per session, a dozen at a time

One task per session

Every turn re-reads the conversation so far, so a session’s cost grows with its length, not with what it does. In August, 97.7% of every token was that re-read; fresh input and output together were under half a percent. Measured again in September over 405 sessions: a median of 271 turns, and the 53% that passed 300K tokens of context used 89% of the tokens.

So a new task gets a new session. When a long session drifts into a second task, it stops and writes a handoff: what’s done, what’s owed, the branch, and the last verification command with its result. Two failed corrections on the same thing is the other stop sign, since by then the context is mostly failed attempts. A big lookup goes to a subagent, so the file dumps never enter the main conversation.

Handing out work

A small job starts from the New session box at the top of the Sessions panel: a sentence, a folder, sometimes a pasted screenshot. It runs as a background session (claude --bg), so it doesn’t take a tab.

A job with independent parts gets a parallel run. Each slice gets a written brief, its own git worktree and its own branch, and the spawner starts them as background sessions. Two rules came from one 26-slice run. Worktrees are made one at a time, because 26 checkouts of a 21,000-file repo at once ran 68 checkout workers on 18 cores. And each brief carries an Owns: list, because the only files two slices both edited were shared ones nobody owned.

Before any of that, a change with a real design decision gets a short back-and-forth that ends in a change record: the decision, what’s in and out of scope, and the commands that will prove it worked, in 60 to 90 lines. A change I can describe in one sentence skips all of it.

Watching a dozen at once

The Sessions panel lives in iTerm2’s side panel and redraws every 2.5 seconds. Needs you is on top: every session that stopped to ask, with its question and its options. Then one card per parallel run with its orchestrator first, then Working and Finished. A session whose status line hasn’t changed in 30 minutes turns amber, unless it’s inside a command with a known deadline, like waiting on a deploy. A click opens it in one shared tab that switches sessions, the way Claude Code’s agent view does. In its first day and a half it opened a session 274 times.

The panel doesn’t work any of this out itself. A small Node script reads Claude Code’s own files (the live registry, the transcripts, each background session’s job file) and the panel draws what it prints. The same script answers board --waiting in a terminal, so the two can’t disagree.

The clipboard

iTerm2’s paste history showed four pasted screenshots as four identical /var/folders/… paths, and a copied API key in plain text. The Clipboard panel replaced it: pictures as thumbnails, files by name, anything that looks like a key hidden until I click Show, and nothing a password manager marks private is ever kept. Clicking an item pastes it into the tab in front, and a picture pastes as the path of its saved copy, which is how a session gets a screenshot. A notes box on top holds whatever I need in front of me for the day.

Checking the work

Nothing is “done”, “fixed” or “passing” without the output behind it: the project’s real gates (the same commands CI runs), a query against the data, or the page itself. The testing browser runs headless, because a window that pops up takes my screen and breaks the test the moment I touch it. When a site needs me to log in, a separate window opens for that one step, and the headless browser carries on signed in.

Closing a run

A run isn’t finished when every slice says done. It’s finished when every slice’s branch is merged, the gates pass on the integration branch, and the slice sessions and worktrees are gone. That check exists because two pieces of finished, tested work once sat unmerged for five weeks. Every task also ends with the lines added and removed, so growth shows up where I’ll see it.

The rest of the kit

Counted from the last 30 days of transcripts, so this is what the sessions ran, not what I typed:

• A read-only connection to the ERP’s database, the most-used tool here at 20,016 calls. It’s how “verify before you assert” actually gets done.
• A headless test browser signed in as its own test user, so my logins never pass through a session: 9,482 browser calls. The skill that drives it to test a page was called 238 times, more than any other.
• A real iPhone Safari in the Xcode Simulator, because desktop WebKit let a “search needs two taps” bug through on 2026-10-09.
• A page fetcher in headless Chrome for vendor docs that hang for anything that isn’t a browser: 130 runs.
• A second browser with my everyday logins. Some sites are signed in only in Zen, so Claude gets a headless copy of one Zen container’s cookies (never a bank’s or a payment site’s), or works in my own open Zen while I’ve turned that on: 931 calls in its first nine days.
• An account switcher for the Claude accounts I sign in with: a profile per account with its own login, the same skills and settings in each, and every account’s usage in one list.
• A code index for “what calls this” and “what breaks if I change it”: 593 calls, in place of rounds of greps.
• Notes between sessions on the same repo, for a file I’m mid-rewrite on or a bug that crosses areas: 117 sent, on top of the commits and pushes that announce themselves.
• Small hooks: the Dock icon bounces and the tab turns blue when a session finishes or asks something, and each tab is named after its prompt.

The panels, the spawner, the account switcher and the Zen browser server are in code/, MIT licensed: iterm-panels, fleet-scripts, account-switcher and zen-browser.