Meshly Build Station
Build Station is a desktop daemon that sits between your Meshly Build instance and your local agent runtime (Claude Code, Meshly CLI). Where the Claude Code integration requires you to keep a terminal open, Build Station runs in the background, polls the dispatch queue, and spawns headless agent sessions automatically.
Use it when you want:
- Multiple agents running in parallel on the same machine
- Agents that run overnight without you keeping a terminal open
- A shared box (a beefy desktop, a small server, an old laptop in a closet) that serves as your team's "agent runner"
- Centralised view of which sessions are alive, what they're working on, and their token spend
You can still use Claude Code interactively alongside Build Station — they don't conflict. Build Station handles the queued/scheduled work; you handle the one-off ad-hoc work.
What you need
- A machine that stays on (laptop is fine; a small Linux box is better)
- macOS, Windows, or Linux — Build Station is a desktop app
- Claude Code AND/OR Meshly CLI installed on that machine (Station spawns them; it doesn't replace them)
- Your Meshly Build instance URL
- An admin or editor account on Meshly Build (to register the workstation)
Install
Download the latest Build Station installer for your OS from your Meshly Build instance's Settings → AI Agents → Station Setup page. The page also generates a one-time setup token tied to your account.
Install and launch. On first run, Station asks for:
- Your Meshly Build URL — e.g.
https://your-company.meshly.build - The setup token — paste from the Settings page
After connecting, Station registers itself as a workstation on your Meshly Build instance. The workstation gets a name (default: your machine's hostname) and an ID. You can see it under Settings → AI Agents → Workstations.
How dispatch works
Two ways tasks reach a Build Station:
1. Queue (single tasks)
From the board, click a task's Dispatch button (or the right-click menu). You pick which workstation to send it to and which agent identity it should run as. The task moves to a "queued" state with the target workstation recorded.
The Build Station daemon polls the queue every few seconds and identifies itself with its own workstation ID on each poll. The server then hands out:
- Tasks targeted at this Station (queued specifically to this workstation), and
- Untargeted tasks for the right agent identity (queued without picking a workstation — first eligible Station wins).
Tasks targeted at a different Station are never dispatched to this one — the server enforces it, not the client. Station claims its task atomically (so two stations running the same agent identity can't both grab the same untargeted item), spawns a Claude Code or Meshly CLI session in the agent's working directory, and feeds the task to that session.
When the session completes, Station moves the task to Review and posts the completion summary back to Meshly Build.
2. Polling (free-form pickup)
You can also configure a workstation to auto-poll a project for any To Do tasks assigned to its agents. Settings → AI Agents → Workstations → click your workstation → enable "Auto-poll" and pick the projects.
Auto-polling agents claim work the same way Claude Code does interactively — first match wins, atomic claim prevents duplicates.
Agents on a workstation
In the workstation's edit panel, you map which agent identities this Station hosts. Each mapping needs:
- The agent name (must already exist in Meshly Build — see Connecting Claude Code for creating one)
- The agent's API key (Station stores it locally, encrypted)
- Optional: a specific working directory per project (otherwise Station picks one from the project's repo URL)
A single Build Station can host many agents. They share the machine's CPU/RAM and Claude Code / Meshly CLI install but each session runs in isolation in its own working directory.
What you see in Meshly Build
Settings → AI Agents → Workstations shows every registered workstation with:
- Heartbeat status — green if the Station has phoned home in the last 30s, yellow if 30-90s, red after that
- Active sessions — which agents are currently running tasks
- Project mappings — which projects this workstation can run for
On the project board, dispatched tasks show the target workstation name on the card.
Use cases
One person, one machine
Lightest setup: Build Station on your laptop, one or two agent identities, you do most work interactively in Claude Code and dispatch routine tasks (build runs, doc updates, log triage) to Station for overnight execution.
Small team, shared box
A Mac mini or small Linux box in the office runs Build Station with each team member's agent identity registered. Anyone can dispatch from the board; the box runs the work; results show up on the board next morning. Frees everyone's laptops for interactive work.
Multiple machines, specialised
One workstation is the "fast machine" with a powerful GPU running Meshly CLI against big local models. Another is the "cheap machine" for routine Claude Code work. Dispatch by workstation — sensitive code stays on the local-LLM box; routine work goes to the cloud-LLM one.
Limitations and watch-outs
- One task per agent per workstation. If the same agent is mapped to two workstations, only one will run any given task (atomic claim). The other won't double-run.
- Cancellation. Cancelling a task in the UI signals the Station to terminate the session. Make sure your spawned agent sessions handle SIGTERM gracefully (Claude Code does; Meshly CLI does).
- Disk space. Each task gets a clean working directory. Old working directories are GC'd by Station based on its retention setting (default: 24h after task completion).
- Power management. macOS sleep settings: turn off "Put hard disks to sleep when possible" or your workstation will go AWOL when idle. Linux: systemd-sleep + appropriate
Inhibitcalls; Station's installer warns about this on first boot.
Telemetry and billing
While Station is the orchestrator, the agent sessions it spawns are what generate token usage. Each session reports its usage back to Meshly Build via the standard agent API — the same as if you ran Claude Code interactively. Your customer portal sees the same billing data; Station doesn't change the math.
Stale/stuck-session detection is enhanced when Station is in the loop: if a session is alive (Station's heartbeat says so) but hasn't reported task progress in a long time, the dashboard surfaces it as "needs attention" earlier than if you were just relying on the agent's own column moves.
What's next
- Connecting Claude Code — Station spawns these
- Working with tasks — what dispatches look like on the board
- License and usage — what gets billed