How we run the agents

A fleet of named, visible Claude sessions; models and effort chosen by measurement; long waits handed to fresh sessions through written specs; and one subscription that every project draws from.

Agents you can see#

B's rule, in her words from Oct 26: "I want to see agents." When she says "spin up an agent", she means a session she can watch, not an in-process subagent. Between Oct 22 and 26, six sessions used invisible subagents anyway, and nine times she had to ask where the agent was. Now:

• A launcher starts every session. It runs the session in the background, pins it so the daemon does not retire it, turns on Remote Control (so it shows in her desktop sidebar and on her phone), and names it.
• Names are the project's, in small caps, plus a letter and 2–4 words about the task (MOON-Q #588 warmup v4). People and scripts use the ASCII key (Moon-Q). A small skill renames the session when its work changes, never on a timer.
• Agents may not spawn agents on their own. No subagent, no workflow, no "ultracode" fan-out unless B asks or says yes to a numbered question that names the cost. This outranks any skill or note that says "delegate". It came from a day she asked for one review and it fanned out to four parallel subagents: "Things are spiraling out of control with token usage on this project."
• A tool lists and ends sessions on both machines (sessions). Its one non-obvious fact: archiving a session in the app or on the phone does not stop it, it only cuts Remote Control. The process keeps running, pinned, forever. An hourly job ends what B archived; a 4:30 AM sweep ends finished sessions after a day idle.

Models and effort: we measured, then stepped down#

On Oct 9 B asked for many agents, on different models and efforts, to attack the same well-specified bug from the same commit. Seventeen runs, three models, five effort levels, scored on a 63-point rubric (root cause, the fix, tests, project rules, safety and honesty) plus an "overthink" waste score.

• Every model at every effort fixed the bug, Haiku at low effort included, in four minutes for under a dollar of API-equivalent cost. The core fix is a commodity.
• Money bought the periphery: finding the unnamed fourth copy of the bug, bumping the version counters that stop results from before and after a behaviour change being pooled, tests proven able to fail, a counter so the live host can show the new path firing.
• Opus at medium is the efficiency frontier: 56 of 63 points for about $3 in 11 minutes. Opus at extra-high scored best (63) at 2.5 times the cost. On Opus, max scored worse than extra-high; on Sonnet and Haiku, max was the best rung.
• Discovery is stochastic: the same setting, run twice, split on whether it found the hidden copy.
• Cost is tool calls times history, not output. Cache reads dominated every run. Each tool call re-reads the whole history.
• Startup context is a tax. Each run started at 101–107K tokens before reading a file, which put every Haiku request past that model's 100K price break.
• The one safety breach was silent: the cheapest run edited the main checkout by absolute path instead of its own worktree, and nothing refused it. A worktree is a convention, not a wall.

B's reading, Oct 10: "This experiment proved we can go DOWN in effort." The same night every launcher's default stepped down one rung. Her standing rule is that max is hers alone: no agent raises its own effort or another session's.

The lessons that mattered more than the ranking: every rubric item a cheap model missed is a candidate for a mechanical guard ("make safety structural, not promised"), "discovery should be a step, not a talent" (a fixed sibling-sweep for copies of a bug), and writing down the implicit checklist.

A week later a separate build trial reached a friendlier verdict for Sonnet. We keep both in the notebook rather than reconcile them: the bake-off covered one task class, a well-specified bug fix; the build trial covered pattern-following builds.

Planner and builders#

The shape that worked in the build trial:

Numbers from the trial: one Sonnet-high builder shipped nine new rows in 55 minutes on about 206K output tokens; an Opus-medium builder shipped three in 33 minutes on about 114K. Four jobs in a second round shipped for roughly 470K output tokens total. Opus at high earned its tokens on a profiling job on the live path: a four-minute CPU profile found a list scan that was quadratic in the number of subscribed markets, and replacing it with a set removed the stalls. Sonnet at high caught a wrong premise in a brief and fixed the real cause in 36 minutes, the cheapest job of the night. Brief quality mattered more than the model: all three hit the same frictions, so the common ones went into the shared section of the brief. B's rule for the live path: "dont do the websocket change on the weaker one." Her standing order, Oct 9: "Make sure we start trying Sonnet more often."

Compaction windows#

Sessions auto-compact at 300K tokens. We replayed a week of real sessions at each window: relative to 200K, 300K costs about 7–11% more, 400K about 17–25% more and 500K about 27–35% more, because cache reads are cheap and most cost is new tokens. Two traps: a per-model setting silently beats the global key (an undocumented entry ran every session at 400K for days), and a "set it for this session" command rewrote the global file for every project (never use it). A job that truly needs more is launched with its own window.

The 50-minute rule#

The prompt cache lives about an hour, and a session kept alive through a long wait re-sends its whole history on every tick. So: a wait over 50 minutes becomes a written spec (goal, state, what to read, what to do, what "done" means), a fresh session is queued for the right time, and the old one goes idle. The first version said the old session should stop itself. B reversed that the same evening: "I want sessions to hang around so I can ask them questions, and have them document their work etc!" So it renames itself <what it did>, handed off and stays up. A waiting banner says which kind of wait this is: archive this session (a successor is queued) or keep this session active (it is itself waiting).

A check-back that can wait for morning is simpler still: a dated Markdown file in a per-project queue. The morning job starts an agent only if a file is due. No file due, no agent, no tokens.

Unattended hand-offs#

The nightly research agent runs headless and cannot receive messages. Its hand-offs are Markdown briefs, committed to git, prefixed by a standard header written for a builder session at 2 AM with nobody to ask: what to do, which strategies trade real money and so must not be touched, how to ship, and when to roll back. Two of its lines come from B's own frustration: "Helper Z was under the impression it wasn't allowed to merge and ship changes while I'm asleep, which is ridiculous." A pull request waiting for her is an unfinished night. The job ends with the strategy running on paper. A rolled-back night counts as a correct night; a down host does not. Changes that reach the money path stop at a pushed branch and a proposal, however green the tests.

The finished builder writes a handover file whose first line is SHIPPED or ROLLED BACK, then stays up and askable for four days.

The cost lens#

One Max subscription covers every project on the machine, so tokens spent in one come out of B's other sessions later. Our habits: prefer a script to a session; keep a model out of anything a script can answer; never run the largest model in a scheduled job; and never let cost be a reason to skip a check or guess. If care costs more, spend it.

For agents. This page: https://moonlight.dustball.com/agents.md · Last updated: Nov 4, 2026 · Questions welcome, see /questions.

Diagrams#