In Six Lessons from Building a Game with AI, I explained why I built Warmstart: several coding agents, several subscription accounts, and too many scheduling decisions to keep in my head. This is the implementation story. Warmstart is open source, but still pre-alpha; these are design choices from a tool I use on my own projects, not a general benchmark of coding agents.
A task is the unit of work
Warmstart turns a prompt into a durable task with a thread, constraints, priority, dependencies, runs, and a finish policy. A run is one attempt by an agent; the task survives that run, the agent process, and even a change of provider. That distinction matters when an account hits its quota or an agent needs an answer: the work can pause with its history and resume later.
There are five task shapes: Single Task, Conversation, Plan & Execute, Plan & Split, and Debate. They use the same scheduler, but have different stopping rules. A Conversation returns to me after each turn; a Single Task can continue through implementation, checks, and landing. Dependencies make a task wait for another task's result instead of asking an agent to remember a sequence in one enormous conversation.
The screenshots in this article use staged accounts, projects, and results.
The Tasks board connects each task to its worker, status, and account capacity.
The control plane
The desktop application is Electron with a React interface. A separate, detached Node process holds the SQLite store, scheduler, quota poller, agent processes, and API. Closing the window does not kill work that may have to wait hours for a quota window. The interface talks to the daemon through Electron IPC; the daemon publishes events back to the interface. Agents receive a per-run MCP server for task actions such as asking a question or reporting a completed task.
I wanted the ordinary scheduling loop to be cheap and predictable. It ticks every ten seconds and spends no model tokens. It admits tasks whose time has come, checks holds and available capacity, chooses a candidate, and dispatches. A separate controller consults a model for judgment events, such as a genuine near tie between candidates on a large task. The routine path is arithmetic, not another agent deciding what an agent should do.
Routing by capacity, cache, and quality
Routing first applies hard gates. An account must be installed, signed in, healthy, allowed by the project's authority policy, able to provide the capabilities the task needs, and within its concurrency limit. A task pinned to a worker or model keeps that constraint. Quota is a gate too: an account close to exhausting the relevant pool cannot take work simply because its model scored well.
The eligible worker and model pairs are then scored using measured signals: remaining five-hour and weekly capacity, reset timing, expected cost, speed, past review quality, and whether an existing conversation can be reused while its prompt cache is warm. The score and its inputs are recorded with the dispatch. If the measurements cannot distinguish two close choices, Warmstart can ask a model; it does not hide an unknown measurement behind a made-up zero.
This makes the scheduling question more precise than “which model is smartest?” A strong model may finish in fewer turns. An account with quota about to reset may be worth using now. A warm conversation can save a large prefix read. The right choice depends on the task, the account, and the moment.
Conversations are an expensive cache
A coding agent repeatedly reads project instructions, tools, file layout, and earlier discussion. Rebuilding that context costs tokens. Warmstart can continue a live session, resume a previous conversation, or, when enabled, let another task in the same project and account reuse its context. The task still keeps its own mandate; sharing context does not expand permission to act.
Reuse has a boundary: a long conversation can become more expensive to carry forward than to summarize and start fresh. Warmstart tracks cache age and can compact a conversation at that break-even point. A warm cache is useful only while the provider can still reuse it, so the scheduler treats time since the last request as a cost input. It also keeps uncertainty explicit: an adapter may restore conversation context without reporting a cache read, which proves continuity but not a discount.
A task thread keeps the conversation and the task settings together.
Workspaces and landing
For parallel work, Warmstart gives tasks separate Git worktrees and task branches. That keeps two agents from editing the same checkout at once. A project can also choose a serial trunk mode, as this blog project does; a trunk task takes an exclusive lease on the main checkout. In either mode, the task's instructions and finish policy determine how far work may go.
The agent makes the commit, choosing exactly which files belong in it. Warmstart then applies the project's finish policy: hold for review, verify, merge, push, or open a pull request. A merge requires the declared checks. Failed checks leave the work available to inspect, and unmerged branches or dirty workspaces appear as loose ends. Cancellation is a stop, not an implicit deletion.
Those boundaries matter more to me than an “autonomous” label. The system needs to know when it can proceed, when it must ask, and what evidence supports a landing. This project's policy currently holds each conversation turn for a person; I can inspect a result before asking it to land.
The Flow view shows tasks moving through the worktree pool.
Measuring the actual work
Each task records its worker, model, elapsed time, token observations, and share of subscription usage. Subscription pricing is awkward: a five-hour window can be shared by several concurrent runs, and a quota panel may update late. Warmstart divides observed window movement among overlapping runs and marks estimates. If it lacks a before and after reading, it reports the price as unknown. Unknown is different from free.
Cost and speed alone do not tell me whether an agent did good work, so a peer agent from a different provider can review a finished task against a rubric. Those scores feed future routing as one signal. They are judgments on my own tasks, with their own biases; they are not a universal ranking of models.
Statistics compares measured quality, cost, and active time.
The trade-offs
The most difficult part is not launching several CLIs. It is preserving the identity of a task across runs, assigning quota honestly, deciding when context is worth carrying, and preventing a convenient automation from quietly landing the wrong thing. Warmstart currently runs the official Claude Code, Codex, and Antigravity CLIs against accounts I control. It is pre-alpha, and some unattended agents run with the full authority of the operating-system user. I treat project scope, review, and the machine I run it on as part of the design, not as defaults to forget about.
Visit warmstart.dev for an overview and downloads.
The source and installation notes are public, along with the architecture, routing, and landing references. I am still changing the tool as I learn from real tasks; these documents are the best place to see how it works now.
No comments yet