Bring your own machine

Run pipelines on your own hardware with your own Claude Max subscription. No per-token markup.

Why BYOM

BYOM (Bring Your Own Machine) is the lower-friction tier. You provide the hardware and the Claude account; PipedAI provides the orchestration. Three common reasons to choose it:

Already on Claude Max. If you have an active Max subscription with usage you're not maxing out, running pipelines through it has near-zero marginal cost.
Data sensitivity. Your MCP endpoints stay on your network. The worker invokes claude -p locally; only the run results (token counts, exit code, short message) flow back to PipedAI.
Predictable cost. No per-token markup, no metered surprises — the only ongoing cost is the Claude Max subscription you already pay for.

What you need

A machine that can stay online roughly as often as your triggers fire
Node 22+ and Claude Code CLI installed
A Claude Max account with claude login completed
Network reachability to your MCP endpoints (and to PipedAI on outbound 443)

Or: api-key mode

If you don't have Claude Max, run the worker with AUTH_MODE=api-key and ANTHROPIC_API_KEY=sk-…. Claude usage bills directly to your Anthropic console — same model, different payment plumbing.

How sticky assignment works

Every trigger is bound to one specific worker. The same machine runs every firing of that trigger until you reassign it. Predictable, easy to debug, easy to reason about MCP token scoping.

If a worker goes offline (no heartbeat for 3 minutes), the trigger's queued runs accumulate but don't execute until either the worker comes back or you reassign the trigger to a different worker. The dashboard surfaces a banner when there's offline-worker-with-active-triggers state.

Cost model

BYOM is the platform's entry tier — no per-token markup. The platform subscription covers the dashboard, run history, audit log, multi-tenancy, and encryption-at-rest. Your machine and your Claude account cover the actual execution cost.

The Marolence-Managed Worker tier is the alternative — Marolence runs the worker fleet for you, billing token usage on a passed-through model. See the pricing summary on the landing page for the up-to-date comparison.

Operational tips

Run as a system service (systemd / launchd / nssm) so the worker restarts on crash and survives reboots.
Use the dashboard's overview page to spot stale workers — the “Online Workers” card surfaces 0 if no machine has heartbeated in the last three minutes.
For redundancy, configure a failover worker per trigger (open the trigger editor, scroll to “Failover worker”). When the primary hasn't heartbeated in 10+ minutes, the failover atomically takes over the trigger's queued runs on its next poll and the takeover is recorded in the audit log as run.failover-claimed.