How to set up the new Dell OptiPlex Plus 7020 alongside the Mac mini so the agent fleet can scale on the powerhouse, the way you pictured, while the Mac keeps doing the few Apple only things and nothing else.
Prepared by Sage · re-cut 2026-06-20 after you challenged the first draft and were right. See the correction section for what changed.
Bottom line
Recommended architecture
The orchestrator and the majority of the fleet move onto the Dell, where they scale on the Dell's own Claude login. A few agents stay resident on the Mac mini, on the Mac's own separate login, doing the Mac only work. The two talk over Tailscale.This is the picture you had: brains on the fast PC, hands on the Mac, and yes, you keep agents on both. The first draft told you the labels had to swap and that no agent could live on the Mac, because one Claude account could only run on one machine. That was wrong, and you caught it. Two independent research passes (Opus and Codex) confirmed it: credentials are independent per device, so the Dell logging in does not touch the Mac. The bulk scales on a 20 core machine with real headroom, and a handful of agents keep living on the Mac for the Apple only surface, each machine carrying its own login.
The Dell becomes the home of the orchestrator and the bulk of the reasoning. The Mac keeps a few agents of its own for the Apple only work and stops swapping because the heavy load leaves it. You get the scaling you wanted, you keep agents on both, and you lose nothing.
What changed from the first draft
Two claims drove the old plan. You challenged both. One was flat wrong, the other was real but softer than I made it.
Correction 1: one Claude account is NOT limited to one machine
The old draft said two machines on one Anthropic account would race the refresh token and lock each other out. That is wrong. Each machine holds its own login credential in its own store, so different computers do not share the one file that raced.
You already run Claude Code across many computers on one account without trouble. That is the proof.
The two hour lockout last week was a same machine problem: about ten agents on the one Mac all sharing the one stored credential, racing a single use refresh token. First one wins, the rest get locked out. A single file collision on one box, not a multi machine issue.
What this unlocks: the Dell can be a real, full agent host with its own login. This is what makes the fleet scalable and sellable.
Correction 2: the macOS hands constraint is real, but you drive it remotely
True part: Apple only runs GUI control inside a real logged in desktop session. Clicking, screen reading, native Mac apps, Safari for iCloud, all of it has to execute on the Mac in a logged in session.
The softer truth: what must happen on the Mac is the execution inside a real logged in desktop session. You can satisfy that two ways, and both are fine: a Dell agent tunnels in and drives a thin hands session, OR a few real agents live on the Mac itself and do the Apple only work directly. You wanted resident agents on the Mac and that works, each machine just runs its own login.
The one thing you cannot do is cold SSH in and fire GUI clicks. macOS blocks any process that is not inside a real logged in session with the right permissions. A persistent in session hands process solves that cleanly.
Net: nothing forces the whole fleet onto the Mac anymore, and nothing forces it off either. The Dell hosts the orchestrator and the bulk and scales. The Mac keeps a few agents on its own login for the Apple only work. You run agents on both, on purpose.
The setup
Two machines, one Tailscale network, the brains on the powerhouse and the hands on the Mac.
Dell OptiPlex Plus 7020 · new
Brains + Bulk · where the fleet lives
Runs the full Claude Code agent fleet with its own Claude login. This is the box that scales: parallel processing, many agents at once, room to grow.
cortextos daemon, Telegram control plane, the shared task bus and memory.
Browser workers over CDP, the free and cheap remote API helper jobs, transcode, embeddings, builds, bulk working files.
Can run multiple operating systems side by side for experiments and for packaging whole setups to sell to other clinics.
Reaches into the Mac over Tailscale when, and only when, a task is Apple only.
Mac mini · repurposed
A few resident agents + the hands
A few agents live here on the Mac's own separate Claude login, keeping a logged in desktop session awake with screen recording and accessibility permission. The majority of the fleet and the orchestrator stay on the Dell.
These Mac agents do the Apple only work directly, and a Dell agent can also tunnel in and drive them when the orchestrator on the Dell is the one deciding.
Handles the Apple only surface: native Mac apps, the iMessage history file, iCloud Drive files, anything that needs a real Mac session.
Frees most of its 16GB because the bulk of the fleet and the heavy load leave it. The swapping stops.
For a customer who is not on Apple, this box is optional entirely.
Will moving the fleet off the Mac actually help? Yes
The Mac mini is 16GB and not upgradeable (the RAM is soldered) and has been swapping hard to disk under load (440k pageouts measured). The pressure is the agents plus the offloadable layer, Chrome and browser automation (the documented OOM culprit), the dashboard server, transcode and builds.
When the fleet and the heavy load move to the 20 core Dell, the Mac is left with only the thin hands session. It stops swapping and the disk the swap file was eating clears.
More importantly, you stop being capped by 16GB at all. The fleet now grows on a machine you can actually expand, which is the whole point of buying the Dell.
How an Apple only task runs in this model
The whole point: the brain is on the Dell, the hands are on the Mac, and they meet over the tunnel.
An agent on the Dell decides it needs something Apple only. For example, reading an iMessage history file or grabbing an iCloud Drive file that is not on the web.
It opens a tunnel to the Mac mini over Tailscale and hands the instruction to the persistent hands session already running in the Mac desktop session.
The Mac hands session executes on the real Mac screen, using its screen recording and accessibility grants, and returns the result or the file.
The Dell agent continues. The brain never left the PC, the hands never left the Mac, and you did not have to host an agent on the Mac to make it happen.
After your content changes, the Mac is barely needed day to day
Instagram carousels over 10 slides: I deliver the images plus the caption, you paste them in. No iPhone Mirroring, no Mac.
iMessage: you do not use it. If history is ever needed it is a file the Mac tunnel can read. Note: iCloud.com in a browser does not include Messages, but does include Mail, Photos, and Drive.
iCloud Drive files: reachable two ways, icloud.com in any browser, or the Mac tunnel.
What truly pins you to a Mac day to day is essentially nothing. It becomes a box you reach into for the rare Apple only task, not a box you depend on.
Role split, line by line
If a task needs the macOS GUI or a native Mac app, a Mac agent does it (or the Dell drives it on the Mac). The orchestrator and the bulk live on the Dell.
Capability
Dell 7020
Mac mini
Claude Code agent fleet
Yes — majority + orchestrator
A few, Mac only work
cortextos daemon, Telegram, task bus
Yes
No
Reasoning, orchestration, scaling
Yes — grows here
No
Browser workers (headless Chrome over CDP)
Yes — primary
No
Free / cheap remote-API helper jobs
Yes
No
Video transcode, embeddings, builds, scrapers
Yes
No
Multiple operating systems in parallel
Yes — for experiments and selling
No
Computer-control, AX, screencapture
Decides and drives remotely
Executes — must, in session
Native macOS apps, Safari for iCloud
Drives remotely
Executes — macOS only
iMessage history file, iCloud Drive files
Requests over tunnel
Reads on the Mac
Local-LLM inference (optional)
Only if cutting API dependence
No
Bulk working storage
Big workdirs (or FleetStorage)
Small only
What the sources actually say
In your priority order. The corrected model lines up with the community split better than the first draft did.
1 · James Goldbach protocol — does NOT formally teach a brains/hands split
No lesson or skill on a two-machine hardware split, only conversational replies, and his own setup runs the inverse.
"I've opted to keep the agents on local machines and have pretty much everything else for cortext in the cloud."
James runs agents local, infrastructure cloud, and favors multiple agents on one machine for self-repair. Takeaway: the brains/hands hardware split is a community idea, not core curriculum. Not overstating him here.
2 · The community split = David Hunter (the name you were reaching for)
Property-management company, Skool post 135 "Mac mini VPS hybrid." This is the load-bearing source, and it matches the corrected model directly.
Brains = a separate box: role-specific reasoning agents that decide and apply company rules and never touch the browser.
Hands = Mac mini: browser-operator agents with persistent logged-in sessions. They observe the screen, execute, confirm. No business decisions.
The loop: brain box to Mac hands and back. Brain decides "open this, what do you see," Mac returns structured data, brain decides the action, Mac executes and confirms, brain logs the next step.
Moves worth stealing: separate thinking from doing, treat the Mac operators like scoped employees, one Chrome profile per operator, queue all browser work.
This is exactly the corrected model: brains on a non-Mac box, hands on the Mac, driven remotely. The only difference is your brain box is a local Dell instead of a cloud VPS, which saves the VPS cost and keeps everything on your own network.
"PC (i9 32gb ram) for heavy work loads / local LLM agents" while the Macs handle daily-driver, polling, and storage roles.
Almost exactly your hardware shape and your corrected split: a strong PC carrying the heavy agent load, Macs in lighter operator and appliance roles. Independent confirmation that people with this gear put the fleet on the PC.
4 · Independent research — two passes, reconciled, that shape the build
Opus 4.8 and Codex 5.5 each researched the credential question independently, then reconciled. Grounded in Anthropic and Apple primary sources plus a read of the Claude Code binary.
Verdict (both passes agree): credentials are independent per device. Each machine that runs its own login gets its own access plus refresh token lineage, and the Dell logging in does not invalidate the Mac. Codex confirmed it in the binary: the refresh request carries no device id, so the server keys off the token value itself, meaning each login is its own lineage. claude.ai itself lists multiple devices and multiple Claude Code tokens at once, which a single shared credential could never do. The old one account one host claim is dead.
Two build rules fall out, and one transport correction: (1) each machine runs its OWN login, never copy or sync the credential file between boxes. (2) each machine runs its own single writer keeper for the local race. (3) the cortextos task bus is file based with atomic renames and locks, which are unreliable over a shared network folder (SMB or NFS), so the Dell dispatches by running the bus command LOCALLY on the Mac over SSH rather than mounting a shared queue. Shared folders are fine for bulk artifacts, never for the live queue. Recommended transport: Tailscale + SSH + CDP.
Wiring the two boxes together
The Dell dispatches and tunnels into the Mac. The direction is the reverse of the old draft.
Layer
Use
Why
Network fabric
Tailscale (WireGuard mesh)
Encrypted, stable, no port-forwarding. Same on the home LAN or remote. A community member (Lewis Brown) uses exactly this to wrangle his machines.
Job dispatch
SSH, key-based, jobs wrapped in tmux
Lowest latency for non-GUI coordination. tmux survives disconnects and reboots.
Mac hands control
A persistent Claude Code or Codex session living in the Mac desktop session, addressed over the tunnel
This is the key piece. GUI work must run inside a logged in session, so the Dell talks to a session already there rather than spawning one cold over SSH.
Browser work
Playwright / CDP on the Dell (ws://dell:9222)
Headless browser scale runs on the Dell, off the Mac. Cross-platform.
Human peeking at the Mac
VNC (Screen Sharing) over Tailscale
For your eyeballs only, never the automation path.
Repo sync
git, pull-before-act, commit + push every change, never force-push
Per ADR-001 (multi-machine git). Both boxes share the cortextos repo, so the discipline matters.
The one trap to never build on
Cold SSH-spawning a macOS GUI script from the Dell. macOS blocks it because the spawned process is not inside a logged in session. Always route Apple only work through the persistent in session hands process instead. The fleet already proved this with the Argus operator.
Mac appliance setup
Three settings turn the Mac into a reliable remote hands box. Skip them and GUI control silently returns blank.
Enable auto-login so a real graphical session always exists after a reboot. Without it the Mac sits at the login window and every screen-control job returns NULL.
Run the hands session as a LaunchAgent scoped to the desktop session (LimitLoadToSessionType = Aqua), not a LaunchDaemon (those get zero GUI) and not a bare SSH-launched process.
Grant the permissions once (Accessibility, Screen Recording) inside the logged-in session. These cannot be granted from a pre-login or headless context. Keep the Mac awake (caffeinate) so the session never drops.
The refresh keeper, on each machine
The lockout fix still matters, just understood correctly now.
Single writer refresh, per box
The lockout was a same machine race: many agents on one box sharing one credential file, all trying to refresh a single use token at once. The cure is a single writer keeper that refreshes the credential early and alone, so no agent ever races.
This keeper runs on every machine that hosts agents. The Dell needs one, and the Mac needs its own too because it keeps a few agents.
Each machine has its own credential, so the keeper is purely a local concern on each box, not a cross machine handoff.
The cross machine question — now answered
Both research passes confirmed two machines refreshing on the same account do NOT rotate each other out, because the credentials are independent per device. This is no longer an open belief, it is the verified finding. The only thing left is a one time sanity check the day the Dell arrives: the Dell logs itself in while the Mac runs a heartbeat, and we watch the Mac keep working and both devices show up in the account session list. One way, read only on the Mac, stop instantly if the Mac ever blips. That confirms in the real world what the research already settled.
The 7020's storage — add a drive, never replace
You asked about this directly. Here is the exact slot layout and what to buy.
Slot layout — Dell OptiPlex Plus 7020 SFF (the 2024 i7-14700 model you bought)
2 × M.2 2230 PCIe Gen4 NVMe slots plus 1 × M.2 2280 PCIe Gen4 NVMe slot for fast SSDs.
2 × SATA 3.0 bays for a 2.5-inch SSD or a 3.5-inch hard drive.
Your 1TB ships in one of the M.2 slots. That leaves at least one free M.2 slot AND a free SATA bay. So you add a second drive, you do not pull the 1TB.
Caution: the old 2014 "OptiPlex 7020" has no M.2 at all. If you look up specs, make sure it says Plus 7020 or 14th-gen, or the numbers will be wrong.
When you'll need it
Sooner than the first draft implied, because the fleet now lives here. With large video and asset workdirs on external FleetStorage (the standing rule), the internal 1TB carries the OS, the full agent stack, repos, and any local models. Add the second drive when the 1TB crosses about 70% full, not before.
What to buy when the time comes
Best pick: a 2TB M.2 2280 PCIe Gen4 NVMe in the free 2280 slot (WD Black SN770 2TB or Samsung 990 series, roughly $120 to $150). Fast scratch for the fleet, transcode, and embeddings. Drop-in, no cables.
Cheaper bulk option: a 4TB 2.5-inch SATA SSD (Samsung 870 EVO) in a SATA bay if you want capacity over speed for archives.
Given the fleet plus transcode scratch want speed, the 2TB NVMe is the right call for this box's job.
Build sequence when the Dell arrives
Phase 1Base the Dell. OS, Tailscale, SSH keys with the Mac, Node, the cortextos stack, browser tooling, the free-API helper runtime. Give it its own Claude login. (Local models only if you opt in later.)
Phase 1Prove the link both ways. SSH-dispatch a trivial job between the boxes inside tmux. Then stand up the persistent hands session on the Mac and have a Dell agent drive one Apple only action through it end to end. Confirm both round-trips.
Phase 2Migrate the majority of the fleet to the Dell. Move the orchestrator, daemon, bus, memory, and the bulk of the agents onto the Dell with its own credential and a single writer refresh keeper. Verify the same machine race cannot recur. The Mac keeps a few resident agents on its own login for the Apple only work, plus the hands session.
Phase 2Confirm the Mac relief. Measure the Mac's swap and pageouts before and after the fleet leaves. Confirm the agents are healthy on the Dell with real headroom.
Phase 3Scale and harden. Add parallel workers on the Dell, auto-start every service on boot on both boxes, health-check the Tailscale link, and add both machines to fleet monitoring so a dead box or a dropped hands session pings you.
Phase 3Productize. Once stable, snapshot the Dell setup so a chiropractor's box can be stood up from an image, with the Mac appliance as an optional add-on only for customers who want Apple integration.
Open decisions and honest gaps
Windows or Linux on the Dell? Linux (or WSL2) is the cleaner path for the cortextos stack, headless Chrome, and SSH/tmux, and it is the easiest to image and resell. Windows is workable if you want native Windows automation surfaces too. Worth a quick call before Phase 1.
The two-machine refresh question is answered (independent per device, both research passes agree). The only remaining item is the one time live sanity check the day the Dell arrives, described in the keeper section.
No chiropractic-specific precedent exists. David Hunter is property management. His pattern transfers cleanly, but nobody local has split practice-management work across two machines, so we adapt and verify as we go.
Storage ownership between the boxes. Proposal: the Dell owns the fleet, its working storage, and the shared repo working copy; FleetStorage stays the overflow; the Mac keeps only what its hands session needs.