Theo’s Guide to Running Coding Agents in Parallel

How many agent threads were already running when you clicked this video? I think many developers are missing the opportunity to work on several problems at once. My own approach is deliberately aggressive, and the examples here are meant to illustrate how I think, not to be a formula everyone should copy.

I have been moving among many accounts with friends, and I describe the suspensions we encountered as temporary. That is my experience, not a promise about anyone else’s account. Later I explicitly acknowledge that the setup might breach service terms or lead to a ban.

The outline is simple: getting and accessing tokens, using them well, experimenting with less obviously productive tasks, and keeping work going while you sleep. The practical examples matter more than the exact number of threads or accounts in my setup.

I expect objections that this works only for side projects or costs too much. I claim that people at larger companies are using some of these techniques as well, but the examples and numbers I offer are based on my own experience rather than an independent survey.

First, compare a subscription with paying directly for API usage. In my estimate, a $200 Claude subscription could yield usage that would cost around $8,000 at API rates, with about half in the Fable category under the limits I describe. This is an API-equivalent estimate, not a balance of money or a guaranteed allowance.

I consider the $100 plan less attractive for my pattern because, in my account, its shorter usage window is more restrictive. I also estimate roughly $12,000 of API-equivalent inference for a $200 Codex subscription. Actual value depends on usage, models, limits and the terms in force.

I speculate about model prices and provider margins, including a rough 95% margin calculation attributed to outside estimates. Those are guesses about costs and pricing strategy, not verified financial results. My argument is that the price difference makes subscriptions appealing for development work.

I also point to past Codex usage resets and argue that they increased the practical capacity of my accounts. Resets and subscription availability can change; treating a past reset cadence as a promise would be a mistake.

I suggest checking the data controls on personal accounts. I also claim that disabling model training makes personal and team terms effectively identical. That conclusion does not follow from the setting alone: agreements, retention and other protections can differ, so the relevant current terms need separate review.

I distinguish personal development work from serving public users, and say the latter should use the API rather than a subscription intended for personal use. I then describe buying more subscriptions, while acknowledging later that aspects of my setup may be against the rules.

With multiple machines and accounts, I found manually changing authentication awkward. I describe a proxy that centralizes access and reports usage, and explain why I chose to route my own machines through a home connection. These are details of my setup, not evidence that any provider permits it or will avoid enforcement.

A later disclosure is important: this might get an account banned and might violate the terms of service. My experience with my own accounts cannot establish that it is safe for other people, and neither a particular network address nor a proxy guarantees an outcome.

I also compare subscriptions sold by model providers with plans sold by other products. My estimates of the discounts those companies receive are speculation. Pricing and availability are time-sensitive, and the comparison depends on the exact model and usage.

In an update recorded after the original discussion, I say Claude Opus 5.5 changed my own workflow: many people may get enough useful work from one subscription and may not need multiple accounts or a proxy at all. That qualification matters when interpreting the rest of the demonstration.

The dashboard shows usage windows and reset dates. I discuss choosing accounts based on when their limits reset and tracking how much is being used. These mechanics describe the products and account states visible when I recorded the video, not a permanent schedule.

Session affinity matters for efficiency: when a thread continues on the same account, its existing prompt cache may be reusable. Switching accounts can require a cache to be written again, so I recommend watching cache reads and writes instead of assuming routing changes are free.

My machines reach the proxy over a private Tailscale network. I describe relying on that network boundary rather than an API key in my own setup. Network access controls are not a universal substitute for authentication or a guarantee of isolation; the security of a deployment depends on its configuration and devices.

I keep a fleet-management repository describing the tools and settings I want on each machine. When I add a box, I ask an agent to use those instructions to set it up. The larger idea is to make the environment repeatable, while treating access and approvals as decisions that still need review.

The services I use also handle resets differently, at least in the examples shown. I explain how an immediate or banked reset can affect when the next weekly limit comes back, and why a reset close to a scheduled renewal changes how I think about capacity.

I describe unused capacity at a reset as money lost. That is a motivational analogy, not a literal cash loss or a balance that could have been withdrawn. Whether more usage is valuable depends on whether the work is worth doing, and providers may change limits.

My hand injury changed how I use a computer: I cannot count on typing or switching applications as easily, and I do not want to sit watching a thread generate. The question I ask is how early an agent can start helping and how long it can work before I need to look again.

Think about both sides of the merge button. Before merging, give the agent tools and time to test, review and fix problems. I estimate that much more of my own token use goes to verification than writing code, because I want the change to be ready for a meaningful human decision.

After the merge, make failures visible and make rollback cheap. I suggest that a team unable to undo a bad change quickly should improve that system before increasing the pace. Automated checks reduce risk; they do not prove a change is safe, and recovery still needs to work when something goes wrong.

There is another stage before the merge: deciding what you want. I used to think through the whole solution before bringing in an agent. Now I try bringing it in when I first encounter the problem, so we can explore whether there is a simpler approach I missed.

I am not saying to stop thinking. The point is to decide where my attention is most useful. When I give an agent my preferred solution too early, it can faithfully implement the wrong idea; giving it the problem first sometimes avoids that detour.

A concrete example is a T3 Code bug reported with a screenshot. Instead of immediately dictating the changes, I can supply the screenshot and ask for a fix. If the result fails or misses the intent, that is a signal for me to investigate and steer the work more closely.

This resembles what I learned as a manager: give people interesting problems and help when the first answers reveal a difficult or novel issue. I want the agent involved from the first report through a reviewable pull request, while I continue talking with users and handling operational problems.

I call this scaling thinking rather than outsourcing it. The agent can investigate, test and wait for a review while I start another task. When work is ready, I return to evaluate it; long-running threads do not require me to watch every step.

That creates a coordination problem: how do you keep many threads straight? I demonstrate T3 Code, a project I work on, and argue that threads should be treated as tasks rather than histories that all demand constant attention.

In the demo, settling a finished thread removes it from the active sidebar, giving me an inbox-like view. This does not remove the cost of switching context, but it makes it easier to see which tasks are done or waiting for a decision.

For a new feature, I describe a small message queue with a pending message and an option to steer the agent. I attach an example and choose a machine that can keep working after I close my laptop. The interface groups repositories across machines when their Git origins match.

Another example begins with a screenshot of a confusing device connection screen. I explain that disconnect feels ambiguous and removal should be clearly presented as permanent. The agent gets the problem and possible directions, rather than a fixed list of implementation steps.

I also tell it how to proceed when uncertain: if the solution seems straightforward, implement it and return a screenshot; otherwise, make a few HTML mockups so we can choose together. That gives it room to proceed while preserving a point for a human decision.

A background-send shortcut lets me start a thread and stay in place to launch another. I generally wait until the thread is done or needs input before inspecting it. T3 Code also offers load balancing among connected machines, according to the demonstration.

Agents can work concurrently, but my own attention is limited. The design question is how to make a task self-contained enough that it can progress without interrupting me for every step, then surface the information I need when it is ready.

For a paragraph-streaming feature, I first ask whether it is difficult. Once the answer looks promising, I ask the agent to build it, file a pull request and start an environment where I can try it. Giving those steps together reduces the number of times I have to return just to ask for the next step.

I then ask the agent to monitor the pull request. My goal is for the next visit to include the code, a usable preview and the results of checks. I also describe conditional automatic merging, but that only makes sense where the stated conditions, permissions and review expectations actually permit it.

Parallel changes can collide. T3 Code starts new threads in separate Git worktrees by default, which helps isolate working directories. It is not perfect: for example, Git will not normally check out the same branch in two worktrees, so a second reviewer may need another branch or clone.

I postpone threads I want to revisit later and settle or archive work I no longer need. The sidebar dims running threads so completed work and requests for input stand out. The purpose is to reduce competing demands on attention, not to claim context switching disappears.

I prefer to inspect a result after the agent has finished rather than continuously watch it work. If it fails, I can inspect the reasoning or ask what happened. I also dismiss a viewer’s malware concern, but an agent’s output and tool use can introduce security risks and still require appropriate review.

The next category is deliberately open-ended use: ask an agent to explain a difficult pull request, summarize a teammate’s work, or find forgotten items that deserve attention. These are ways to explore and triage, with the result still subject to the user’s judgment.

I also describe using assistants to search email and collect my own medical records while other tasks run. Such examples depend on the access granted to the agent and involve sensitive information; the practical choice of tools and permissions matters.

I want one sidebar to show work across machines and distinguish work in progress from completed work. In my demonstration, threads run on several computers while appearing in the same interface and on my phone. I describe T3 Code and its connection options as they existed at the time.

I show how I connect another machine and say the project is free and open source. I also suggest that an agent could help prepare a new server. The example illustrates repeatable setup, but remote access and agent credentials still need appropriate controls.

Try asking questions that seem a little silly. When I had spare capacity, I asked an agent to examine my GitHub projects and unfinished local work, find ideas that might now be worth reviving, and suggest what I should prioritize. It returned a handful of candidates for me to consider.

After deciding what to do with a result, I can archive it or ask for a follow-up. In another thread I ask for a status update, a pull request and monitoring; for an old task I ask what the pull request does and why I might merge it.

One evening I had a dozen or more threads active. The next day I went through them one at a time and chose whether to merge, follow up or discard each result. I think of that process as processing an inbox, with the actual decision still mine.

Some tasks took minutes and others much longer. My suggestion is to experiment with unused capacity on exploratory work, including triaging old pull requests, because the results can reveal things I had forgotten. More consumption is not itself proof that the work created value.

The final topic is letting work continue while I am away. If an agent runs on an always-on machine, closing a laptop for a meeting or going to bed need not stop its task. I prefer a small remote computer that I can reach from my other devices.

For a low-cost starting point, I suggest finding an old laptop or desktop with roughly four cores and 8 GB of memory. That is a starting example, not a universal requirement: the suitable machine depends on the build, tests, number of concurrent processes and other demands.

I argue strongly for owning a small box rather than renting a server, using a particular monthly price and a hardware price as an illustration. The economics are situational: rental and purchase prices, electricity, administration and workload all affect the comparison. My claims about account bans on cloud IPs are not guarantees.

On my own server, I show a resource monitor while several threads are running and point out the low CPU utilization at that instant. The model inference is remote, so the local machine is coordinating work rather than performing that inference. One snapshot does not establish the resource needs of every development task.

I prefer Linux for parallel work and describe problems I have had on macOS. Your experience can differ with hardware, filesystem, operating system and project. A small machine can still run into limits if multiple agents start expensive local builds at the same time.

For resource-heavy tasks such as Rust builds, I suggest moving CI elsewhere or queueing it so several compiles do not saturate the same machine at once. The best arrangement depends on the bottleneck; one colleague reduced memory pressure by moving CI off her local machine.

I know some engineers find this style frustrating: an agent makes mistakes and watching it can feel slower than writing the code yourself. I still see failures too. My change is to let a task run while I do something else and come back when there is a result to assess.

What I enjoy is the new engineering problem around the work: scheduling CI, understanding machine resources and coordinating several tasks without supervising each moment. I hope these examples help people find their own useful and enjoyable way to work with agents.

A colleague told me that remote work had made this style more enjoyable for her too. I close by encouraging experimentation and offering to discuss the longer-term economics separately. The examples are a snapshot of my own workflow, not a prediction that today’s prices or limits will last.