Tooling stack ​

Why Week 2 is mechanical ​

Tooling without the mental shift produces an engineer with 10 tabs open and brain-fry within an hour. The mental shift without tooling produces an engineer who knows what they should be doing but can't keep track of which tab is which by 4 PM.

Week 1's identity work needs Week 2's mechanics to be sustainable. The mechanics are small and learnable in days — the whole reason Week 1 is six times the weight of Week 2 is that the adoption of the mechanics depends entirely on the mental shift having landed first.

If you find yourself this week thinking "this is just installing some CLI tools," you're correct, and the practice is still about the discipline of how you use them. Tab-renaming as a habit. Worktree-creation as a reflex. Knowing when an agent has cooked long enough to bring forward versus when it's stuck and needs intervention. The tools are simple; the habits around them are what flying-stage looks like.

1 — cctabs ​

cctabs is the per-tab Claude Code session manager built specifically for fleet practice. The job it does, that nothing else does in one piece:

• Per-tab session identity. Every Claude Code session has a stable name and a stable terminal tab. You can look at a window and know which tab is which work-stream without reading the bottom-line CWD prompt.
• Survives reboots. cctabs restore walks every dead tab from your last session and re-attaches Claude to it. The fleet you had open Friday evening is the fleet you walk back into Monday morning.
• Fork. cctabs fork <session> opens a new tab with the same session history, then lets the two diverge. The cheap way to explore an alternative direction without losing the original.
• Backends. Same Claude Code UX against alternative model providers (Ollama Cloud Kimi / Qwen, local Ollama models, OpenAI-compatible endpoints) when you need to route work off Anthropic — covered in §4 below.
• Send / scrollback. A sibling Claude session (or your own orchestrator session) can read another session's terminal output and pipe input to it. The substrate for cross-session coordination, used heavily in Week 4.

Install ​

npm install -g @generativereality/cctabs

Pick a terminal ​

cctabs supports Wave Terminal (works out of the box) and Tabby (requires a one-time companion plugin install). Wave is the recommended default for new users — fewer moving parts. Tabby is supported for engineers who already use it.

On Wave: just run cctabs new <name> and a new tab opens with a fresh Claude Code session in the current directory.

On Tabby: cctabs install-tabby-plugin --yes does the npm install and the restart in one shot, then your next cctabs new works. Plan to lose any other open Tabby tabs in the restart.

The discipline — tab names as fleet semantics ​

This is the part that matters more than the tool itself. Name every tab the moment it's spawned, and rename when its job changes. The names are how you (and your sibling Claude sessions) keep track of what's where.

Good names:

• auth-rate-limit-fix (specific to a work-stream)
• cctabs-docs-rewrite (specific to a deliverable)
• staging-smoke (specific to a fleet role)

Bad names:

• claude (default, undifferentiated)
• tab-7 (positional, breaks when you reorder)
• misc-stuff (signal-free)

If you can't think of a name for a tab, that's usually a sign that the tab doesn't have a clear-enough job. Either tighten the brief or close the tab.

Commands you'll use daily ​

cctabs sessions              # list all tabs + their Claude session status
cctabs new <name> [dir]      # spawn a new tab, optionally in a specific repo
cctabs rename <id> <new>     # rename a tab (and the Claude session)
cctabs fork <name>           # fork a session into a new tab
cctabs close <name>          # close a tab
cctabs restore               # after reboot, re-attach Claude to every dead tab
cctabs send <name> <text>    # send input to another tab (for orchestration)
cctabs scrollback <name>     # read another tab's terminal output

Full docs at cctabs.com.

2 — Worktrees ​

Worktrees are the git feature that lets a single repo have multiple working directories, each on a different branch, all sharing the same .git folder. They are not new; they predate fleet practice by years. But almost nobody used them at any scale before parallel Claude sessions made them load-bearing.

The why: parallel work-streams need parallel directories. When tab A is on branch auth-fix and tab B is on branch migration-v3, they can't both be in the same directory — checking out one branch evicts the other. Trying to share a directory between parallel streams produces dropped uncommitted changes, broken dev servers, and confused agents.

The how: git worktree add <path> <branch>. The worktree lives at the path you specify (often a sibling directory or under .worktrees/). Each tab gets its own. When you're done with the work, git worktree remove <path>.

Claude Code has first-class worktree support: claude --worktree <name> creates one under .claude/worktrees/<name>/ automatically and cleans it up when the session exits. cctabs's --worktree flag does the same when spawning a new tab.

cctabs new auth-fix ~/Dev/myapp --worktree
# Creates .claude/worktrees/auth-fix/ inside ~/Dev/myapp
# Branches it off main automatically

When to use a worktree ​

• Always, when a tab will edit code on a branch different from your main checkout.
• Always, when two tabs might check out different branches in the same repo.

When not to use a worktree ​

• Read-only sessions (docs review, coordination work). The tab can stay on whatever branch the main checkout is on.
• A single tab that's the only one touching that repo right now.

The gotcha worth knowing ​

Worktrees branched with --worktree branch from whatever your remote-tracking branch points at — not always from your current HEAD. If you have local un-pushed commits on the main checkout, a fresh worktree may branch from the older remote tip and miss those commits. After spawning, verify:

git -C ~/Dev/myapp/.claude/worktrees/auth-fix log --oneline -1

If the base isn't what you expected, push your main commits first, then re-spawn the worktree.

Per Session 1 notes: "you don't really understand worktrees until you try them." Schedule a few hours this week for that.

3 — Foreground vs background streams ​

At any moment, your fleet has two classes of stream:

Foreground (1–3 streams):

• The dev server you're running and live-QAing through the browser.
• The agent driving browser automation against staging that you need to eyeball.
• The work-stream where you're actively iterating with the agent in conversation.

Background (the rest of the fleet):

• Agents grinding through implementation work after you briefed them.
• Agents waiting on CI to come back.
• Agents that ran into something they needed to ask about and are now blocked on your reply.
• Forked exploration agents that you haven't checked back on yet.

The mental model: foreground streams have your attention. Background streams have your trust. You set them up with a clear brief, you let them run, you check in.

The scan ​

Every 15–30 minutes (more often if you have a hot stream needing close attention), you scan the fleet:

cctabs sessions

Look for: which sessions are blocked waiting on you, which sessions completed their work since the last scan, which sessions have been "active" for an hour without visible progress (a sign the agent is stuck in a loop). Bring blocked or completed ones forward to triage. Leave the still-cooking ones alone.

The triage queue ​

When you bring a stream forward, you do one of four things:

1. Approve and continue. Agent finished a chunk and is asking permission for the next. Read the diff or summary, approve, send back to the background.
2. Course-correct. Agent is doing the wrong thing. Re-prompt with the correction, send back to the background.
3. Decompose further. The brief was too broad. Break the remaining work into smaller pieces, possibly fork into multiple new tabs.
4. Close. This stream's work is either done (PR merged) or no-longer-needed (we changed direction). cctabs close and reclaim the mental slot.

The discipline: don't context-switch deliberately between streams. Scan, triage what surfaces, let the rest cook. Trying to give attention round-robin to all 10 streams in turn is brain-fry territory. Trust the brief.

4 — Anthropic quota management + local-model fallback ​

The hard ceiling on fleet practice today isn't capability — it's quota. Claude Code on Pro/Max plans gives generous but finite tokens-per-5-hour windows. Run 10+ sessions hard for a couple hours and you can hit the window cap mid-afternoon.

Be efficient with quota ​

The expensive operations: long context reads, repeated full-repo greps, large diffs, redundant tool calls. The cheap operations: targeted file reads, focused exchanges, small surgical changes.

Practices that conserve quota at high parallelism:

• Brief well so agents don't grep the whole repo to figure out what you meant. A 30-second extra effort in the brief saves the agent a chain of expensive context-building tool calls.
• Use skills and CLAUDE.md to encode patterns the agent would otherwise re-discover every session.
• Don't ask the same question twice. If you've already had Claude analyze a file in one session, don't ask another session to redo that work — share the conclusion via cctabs send / scrollback or a committed analysis note.
• Kill stuck loops fast. An agent re-trying the same broken approach 5 times is burning quota without progress. Bring the stream forward, redirect.

What to do when the window hits ​

When you hit the quota window cap, you have three options:

1. Wait it out. Window resets on a 5-hour rolling basis. If you're at 3 PM and the window resets in 90 minutes, often the right move is to switch to deep-work that doesn't need Claude, take a break, or batch a non-Claude review.
2. Switch a couple of background streams to a local or alternative model via cctabs backends. The work continues at lower capability while your Anthropic window resets.
3. Upgrade to a higher tier (Max if you're on Pro). Often the right call if you're hitting the cap multiple times a week — the tier upgrade pays for itself in unblocked time.

Local-model fallback via cctabs backends ​

cctabs ships with backend presets that route a Claude Code session to alternative model providers via a --backend flag:

cctabs new exploratory-refactor ~/Dev/myapp -b kimi --worktree
# Spawns a Claude Code session against Kimi K2 via Ollama Cloud Pro tier

Built-in backends (run cctabs backends for the live list):

• kimi — Kimi K2 via Ollama Cloud Pro. Cheap frontier alternative; works well for non-critical exploration.
• qwen-cloud — Qwen3 Coder Next via Ollama Cloud Pro. Fastest of the Pro options.
• qwen-local / qwen-next-local — local Ollama models. Slower on M1, but private and free; the fallback when you need to keep work off any cloud.
• gpt-oss — local gpt-oss 20B. Slow, free, private.
• anthropic (default) — Claude via Anthropic API.

Which work routes well to non-Anthropic backends:

• Exploratory refactors where you want a directional answer, not a polished one.
• Boilerplate generation that you'll review heavily anyway.
• Read-heavy analysis tasks where the model just needs to summarise what's in the repo.

Which work doesn't:

• Anything where capability matters end-to-end (production code on the critical path, complex architectural decisions, hard debugging).
• Tool-use-heavy work — non-Anthropic models can be flakier in the Claude Code system prompt, especially the smaller ones.

The practice is to keep your most-capability-sensitive 1–3 streams on Anthropic, and shed lower-stakes parallel work to backends when the quota window is tight.

The assignment — 6+ parallel for one full working day ​

One deliverable this week. Concrete, observable.

If 6+ streams feels like too many on your first attempt: this is itself a useful data point. Most engineers who've never run more than 3 hit a noticeable resistance at 6. The resistance is what Week 5's emotional spine is about. For now, just run the day, observe the resistance, don't try to make it go away.

Self-check — did this week land? ​

• cctabs installed, terminal of choice working, tab-naming discipline starting to be reflexive (you notice when an unnamed tab opens, and you fix it).
• You've used cctabs new --worktree at least once. You understand why it's the default for branch-divergent work.
• You can articulate the foreground / background split for your fleet on any given day — which streams are in the foreground right now, and why the others are in the background.
• You've hit a quota window at least once and dealt with it deliberately (waited / switched backends / upgraded), not in a panic.
• You ran the 6+ parallel day. You watched the recording (or at least scrubbed through it).
• You're noticing the urge to micromanage individual streams. You're not yet good at letting it go — that's Week 5. But you can see it.

What's next ​

Week 3 — Tighter integrations + the autonomous-agents question. The integration thesis: every web surface, every comms surface, every tool surface that's pure coordination overhead routes through the agent. Plus the question every cohort asks — answered explicitly.