You start with one terminal and Claude Code. Then a second task comes in, so you open a second terminal and start Codex on it. A frontend fix goes to a third. Now you are alt-tabbing between three windows, trying to remember which one is waiting on you, which one asked a question ten minutes ago, and which one quietly finished and is sitting idle while you burn attention on the other two. Nothing is on fire. But you have become the thing routing work between the agents, and that job scales worse than any of them.
The terminals are not the cost. You are. When agents run by hand, every decision about what happens next lives in one place: your head. Which agent gets the next task, whether the last diff is safe, what failed while you were reading a different window. That coordination is real work, it is unpaid, and it grows faster than the number of agents you add.
This article breaks down what running coding agents by hand actually costs, where the bill hides until it compounds, and the workflow that removes most of it. Sharkly is the management layer that sits above your agents: you keep Claude Code, Codex, or whatever runtime you already use, and Sharkly holds the tasks, the isolation, and the review in one shared place instead of across a wall of terminals.
TL;DR
Running coding agents by hand looks free because no tool charges for it. The real cost is your attention: you become the router between agents, the memory of what each one is doing, and the single reviewer who has to catch up on every window. That cost stays small at two or three agents and compounds past five. You can keep doing it manually, or route your existing agents through a task layer like Sharkly that assigns work, isolates each run, and returns every result to a Task for review.
The terminals aren’t the problem, you are
Here is the definition worth keeping: a terminal is where an agent runs; a task is the work it runs on. When you manage agents by hand, nothing connects the two except you. The terminal shows output. It does not know what the task was, whether it is done, or who decides what happens next. You supply all of that from memory, one window at a time.
That is why “too many terminals” is a symptom, not the disease. Splitting one agent across five panes with tmux does not reduce the coordination; it only arranges it. You still hold the map of which pane owns which task, which is mid-run, and which finished and needs a human to look. The map lives nowhere shared, so the moment you step away, it goes stale, and the moment a teammate needs it, it does not exist.
What running agents by hand actually costs
The bill is paid in attention, and attention has a measured price. When you switch between unrelated tasks, you do not resume instantly. Research on interrupted knowledge work by Gloria Mark and colleagues, published at CHI 2008, found it takes people an average of over twenty minutes to return to an interrupted task after being pulled away. The American Psychological Association’s summary of task-switching research puts the productivity loss from shifting between tasks as high as 40 percent. Every time an agent finishes and you swivel to a different window, you pay some version of that tax.
Running agents by hand turns that switch into your main loop. Here is where the cost accrues:
| Hidden cost | What it looks like by hand | Why it compounds |
|---|---|---|
| Routing | You decide which agent gets each new task, from memory | More agents means more pairings to hold in your head |
| Context reload | You re-read each terminal to remember what it was doing | Every switch restarts the clock on getting back into that task |
| State drift | Each terminal carries its own branch, env, and half-done edits | Two tasks in one directory quietly corrupt each other |
| Review backlog | You are the only one who saw each run happen | Finished work waits on the one person who can review it |
| No shared record | The status lives in your session, not anywhere a teammate can see | Step away and progress is invisible; nobody can pick it up |
None of these show up as a crash. They show up as a day that felt busy and produced three merged PRs instead of eight, with no single moment you could point to as the problem.
The failure modes hide until they compound
At two agents, you can hold the whole map in working memory and the cost is close to zero. This is worth saying plainly, because it is where most advice oversells the problem: if you run one or two agents on one machine and review each before starting the next, you do not need a management layer yet. Keep the moving parts at zero.
The equation changes when work overlaps in time or in state. Run three agents in the same checkout and you hit the isolation problem covered in multiple coding agents in the same repository: two agents touch the same files, and one silently overwrites the other. Fix that with a worktree per task, the discipline in coding agent worktrees, and you trade a merge problem for a bookkeeping problem: which directory maps to which task, which is safe to delete, which a human is mid-review on. Solve that with more terminals and you are back where you started, only with more windows.
The last cost is the quiet one. When every run happens in a private terminal, finished work has nowhere to go but your attention. Review becomes the bottleneck, because you are the only person who watched the agent work and the only one who can say whether the diff is good. Parallel agents do not help if reviewing their output serializes on a single human. That is the trap described in why the best coding agent matters less than how you manage them: the model got faster, and your review queue did not.
What the management layer removes
A task board removes the part you were doing by hand: being the connective tissue between agents and work. In Sharkly, the Task is the unit that owns the run. You assign a Task to an Agent, and Sharkly prepares an isolated worktree for it on a connected Computer, runs the agent session there, and returns the diff, the logs, and any blockers to that Task. The routing, the isolation, and the record you were holding in your head become properties of the Task instead.
That keeps the division of labor clean. Agents research, execute, test, and report; people set direction, grant authority, and accept the result. Sharkly is not a replacement for Claude Code, Codex, or the runtime you already use; those perform the execution. It adds the shared task, connected Computer, and review layer around them, so context, progress, blockers, results, and human review stay visible from request to release instead of scattered across five sessions only you can see. When you need to watch several runs at once, that is what an agent dashboard is actually for, and it is why teams end up wanting the layer above Claude Code and Codex rather than another terminal.
If you are already running several agents, that is the workflow Sharkly is built around. You can keep routing by hand across terminals, or run your existing coding agents through Sharkly and let the board hold the map.
When by-hand is fine, and when it isn’t
The honest decision rule is short:
- Run agents by hand when you have one or two, on one machine, and you review each before the next starts. The overhead of any tool is not worth it yet.
- Move to a task layer when a third agent starts, work spans more than one repository, or someone other than you needs to see what is running. That is the point where the coordination cost stops fitting in one person’s head.
The signal is not the number of terminals. It is the moment you catch yourself asking “wait, which window was that in?” That question is the coordination tax showing up as a sentence, and it is the same agent chaos a task board exists to end.
FAQ
Isn’t tmux or a terminal multiplexer enough? It arranges the windows; it does not remove the coordination. You still hold which pane owns which task, what finished, and who reviews it. A multiplexer solves screen real estate. The cost of running agents by hand is attention, not pixels.
How many agents can I run by hand before it hurts? Most people are fine at one or two and start feeling it around three to five, especially across more than one repository. The exact number depends on how long each task runs and how much review each needs. The tell is when routing and re-reading windows takes more of your day than the actual review.
Does a task board make my agents faster? No, and Sharkly does not claim to. The agents run at the same speed. What changes is your overhead: routing, isolation, and review stop living in your head and start returning to a Task where the work is visible and reviewable.
What about keeping context across sessions? Private terminals lose it the moment you close them. Binding a run to a Task keeps the goal, the diff, and the discussion together, which is the maintain-context-across-sessions problem solved at the record level instead of by memory.
Can I still use Claude Code and Codex together this way? Yes. Sharkly manages the work around the tools; it does not replace them. See how to run Claude Code and Codex together for the pattern.
