Run background work across a fleet

Think in completed tasks

Parallel work needs independent tasks

Theo encourages keeping useful work running in the background. The broader lesson is to find work that can progress without blocking another task, not to hit an arbitrary thread count. An independent task can reach a useful result while another task waits for review or a model response. Work that shares the same files or depends on an unfinished change needs coordination before parallel execution helps.

Adapt the examples to your workload

He explicitly frames the video as ideas to adapt. His hardware, budget, and personal projects are context for his examples, not a required setup.

Separate subscription price from API-equivalent usage

A quota is not cash in an account

Theo compares flat subscriptions with what the same token volume would cost at API rates. These are his reported estimates. API-equivalent value is neither money earned nor a direct measure of useful work. The distinction is between a price comparison and usable capacity. To judge the setup, ask how many useful tasks fit within the available limits, rather than treating the advertised token allowance as money saved.

Usage windows change the effective capacity

Weekly limits, shorter limits, model-specific caps, and resets all affect how much work fits in a subscription. The figures in the recording are historical claims, not current plan specifications.

Account policy is separate from technical feasibility

The video discusses personal automation, serving public traffic, data settings, and client restrictions. It also contains a later warning that his setup might violate terms or cause bans. Its earlier confident assurances should not be read as policy confirmation.

Understand the proxy layer

A proxy centralizes account routing

Theo describes a customized CLI proxy that holds authentication state and routes agent requests. He also shows a usage dashboard and prefers using capacity that will expire sooner. Think of the proxy as the connection between clients and model accounts. It decides where a request goes while the coding agent still works on its assigned machine. Routing and task execution are separate responsibilities.

Keep a conversation on a consistent route

Session affinity means routing related requests to the same account or backend. In the discussion, this helps preserve prompt-cache reuse. Frequent switching can reduce that benefit.

Transport details affect the experience

The video calls out WebSocket support and model-name handling in his proxy setup. A routing layer has to preserve client behavior, not merely forward a request body.

Separate connectivity from execution

A private network can connect scattered machines

Theo describes reaching a home-hosted service over Tailscale. Agents on other machines can use the shared service while their actual coding work runs elsewhere. Tailscale provides the connection, not the computer that performs the task. A laptop can reach a service on a home machine while a separate agent edits and tests code on another host.

Residential routing is a described account tactic

He argues for a stable residential network exit and particular client choices to reduce account problems. These are his practices and claims. A working route does not establish permission or guarantee that an account will remain available.

Reduce the work around the merge button

Ask for the checks before opening the review

A useful handoff includes exercised behavior, relevant checks, and resolved review feedback. This reduces the chance that the next human interaction is merely asking for work that should already be done. The review should let someone assess the result, not reconstruct the agent's unfinished work. State what changed, what behavior was exercised, and which problems remain. A green build answers only part of that question.

Make recovery part of the workflow

Theo also emphasizes being able to revert a bad change. Verification reduces risk before a merge; recovery reduces the cost of mistakes that still escape.

Try the agent before doing all the preparation

He suggests asking the agent to investigate first, then spending deeper thought where the agent gets stuck. His point is to focus human attention, not to stop thinking about the work.

Treat threads as an inbox

Separate working threads from threads needing attention

A busy thread is not necessarily something you need to read. An inbox-style view helps you find results, questions, and decisions instead of watching generation. The useful distinction is whether a thread needs a decision from you. Background progress can stay out of the way; a finished result or a question belongs in the list you review.

Settling a thread includes finishing its loose ends

The video distinguishes settle from simply hiding a conversation. Ask the agent to finish what remains, handle the pull request, and leave a clear state before removing it from active attention.

Make the next visit useful

Theo dispatches work in the background and asks agents to monitor PRs. The aim is to return to an actionable result, not another incomplete status update.

Keep concurrent work isolated

Separate worktrees reduce edit collisions

Each task needs its own checkout when concurrent changes would overlap. Theo uses worktrees by default and remote machines for execution. This differs from Lauren's emphasis on cloud agents, but both approaches need isolated state. A worktree gives a task separate working files within the same Git repository. This prevents agents from overwriting each other's edits, but it does not resolve conflicts between their changes when those changes are later combined.

A client can show jobs running elsewhere

The thread list can combine work across multiple hosts. Closing the client need not stop a job when execution belongs to a persistent remote host.

Revisit abandoned work with enough context

Theo asks agents to inspect old projects, identify worthwhile unfinished work, and restore previews. A clear completion state makes this easier than guessing from an old conversation title.

Choose hardware around the actual bottleneck

An always-on spare computer may be enough

The video suggests old hardware for modest workloads before buying a large server. Much coding-agent time waits on inference, so all tasks do not need a dedicated high-end CPU. The machine still needs to stay awake and have the tools required by the task. Start by identifying whether the job waits on remote inference or spends time compiling locally; those workloads justify different hardware choices.

Builds can change the resource picture

Parallel compilation, local CI, storage, and memory may become the real limits. Theo notes that a Rust build can saturate cores. His positive Linux experience is an example, not a guarantee about every workload.

Use available time for useful experiments

The closing argument is that persistent machines let work continue during meetings or sleep. The useful outcome is completed work and learning, not burning tokens for their own sake.