Routing Is An Engineering Decision
When you have more than one machine available, routing Claude Code and Codex jobs becomes a real workflow decision. The question is not """which agent is best?""" The question is """where should this specific task execute?"""
Junction""'s multi-daemon model makes that decision visible. A daemon can live on your laptop, workstation, or VPS. Each daemon has its own repository checkouts, provider authentication, GitHub login, model settings, local tools, and current load. The browser can supervise all of them, but the agent still runs on one machine at a time.
Good routing keeps work close to the right code, credentials, hardware, and review path.
Start With The Repository
The first routing rule is simple: run the job where the repository already works.
If your laptop is the only machine with a working checkout, the laptop is the correct host. If your workstation has the full monorepo, faster tests, and the right build cache, route the job there. If a VPS has a clean checkout for small maintenance tasks, it can handle repeatable work.
Avoid routing agents to machines that are almost configured. """Almost""" usually means the agent spends half the run rediscovering missing dependencies, failing tests for environment reasons, or asking for permissions that would not exist on the right machine.
Match Task Shape To Machine Shape
Different work belongs on different hosts:
| Task | Better machine |
|---|---|
| UI work that needs visual review | Laptop or desktop |
| Heavy test suite | Fast workstation |
| Small docs or copy fix | Any configured daemon |
| Overnight maintenance | VPS or always-on box |
| Private service integration | Machine with network access |
| Experimental spike | Personal or isolated daemon |
| Team automation | Work daemon with approved auth |
This is also where Claude Code and Codex can be routed differently. You might prefer one provider for a refactor and another for investigation, but provider preference should not override machine fit. The best agent on the wrong machine still produces a messy run.
Check Credentials Before Starting
Every daemon keeps its own authentication. That is useful, but it means routing decisions need to include credentials.
Before a job starts, ask:
- Is Claude Code or Codex authenticated on this daemon?
- Is the GitHub CLI logged into the right account?
- Can this machine push branches to the target repository?
- Does this daemon have the environment variables the task requires?
- Is this machine allowed to access any external service the task may touch?
If the answer is unclear, do not start the run there. Fix the daemon or pick another one.
Use Availability As A Constraint
Machine availability matters. A laptop may be powerful, but it is a poor host for an overnight task if it sleeps. A VPS may be always on, but it may be slower or lack local services. A workstation may be ideal for builds but unavailable if someone else is using it.
Junction helps by making the daemon list and session state visible from one surface. You can see what is already running, which sessions are waiting, and where a new job would add load.
A practical rule:
- Use your laptop for interactive work.
- Use a workstation for expensive tests and builds.
- Use a VPS for bounded, repeatable, lower-risk work.
- Use Switchboard routes only after the target daemon has proven it can complete the same work manually.
A Concrete Routing Example
Suppose you have three machines:
macbook: active development, UI previews, browser testing.tower: fast CPU, full monorepo checkout, heavy tests.vps: always on, smaller service repos, Switchboard candidate.
Route a CSS layout bug to macbook because you need visual inspection. Route a backend test flake investigation to tower because it can run the suite quickly. Route a small Linear bug with clear acceptance criteria to vps only if that repo builds cleanly there.
The browser control surface stays the same. The execution host changes based on task fit.
How This Differs From Provider Choice
Provider choice asks which agent should do the reasoning. Machine routing asks where that reasoning should be applied. They are related, but not interchangeable.
For example, you might choose Codex for a narrow implementation task, but if Codex is not authenticated on the daemon that has the right checkout, the run should wait. You might choose Claude Code for a plan-first refactor, but if the only available daemon is a constrained VPS without the needed tooling, the better move is to run locally later.
Keep routing boring and explicit. Provider experiments are easier to compare when the environment is stable.
Tradeoffs
Routing adds discipline. You need naming conventions, daemon hygiene, and a habit of checking the target before launch. The payoff is fewer mystery failures and cleaner review history.
The main risk is over-automating too early. Do not create a route for every repo and every machine on day one. Start with one proven machine and one proven task shape. Add a second daemon when the first one is boring.
Where To Start
If you are still setting up, use the Junction setup guide first. If you are already managing several machines, read the broader guide to managing multiple AI coding agents across machines and compare plan limits on the pricing page.