CLI Subscription Bridging Explained

You already pay for an AI coding CLI. Maybe it's Claude Code, maybe Cursor, maybe Codex or Aider. That subscription includes a model allowance you've already bought. So why would an orchestration tool ask you for an API key and bill you per token on top of that?

That's the "bring your own key" (BYOK) model, and it quietly charges you twice. SwarmADE doesn't do BYOK for the coding work. It bridges the CLI you already run. This post explains the difference and why it matters for your bill.

The double-billing trap

Here's the BYOK arrangement most agent tools ship with:

You pay:  CLI subscription  ($X/month, includes model usage)
        + orchestrator's per-token API key usage  ($Y, metered)
        ───────────────────────────────────────────
        = the same model work, billed on two meters

The orchestrator never touches your subscription. It opens its own API connection with your key and meters every token through it. Your CLI sub sits idle while you pay retail per-token rates for the exact capability you already subscribed to.

For light use this is annoying. For agentic workloads — where a single feature can drive thousands of model calls across planning, editing, and iteration — it's the whole cost.

What bridging actually does

A Worker in SwarmADE is not an API client. It's your real CLI, launched as a local subprocess and driven over its own interface. When the Queen dispatches a task, the bridge starts (or reuses) a CLI process on your machine, feeds it the task, and streams the result back.

          your machine                         SwarmADE cloud
┌────────────────────────────────┐         ┌────────────────────┐
│  CLIBridge ──spawn──▶ claude    │         │       Queen        │
│       ▲               (your sub)│◀─task───│   (plans the DAG)  │
│       │                  │      │         │                    │
│       └──result──────────┘      │──done──▶│  Drones audit it   │
└────────────────────────────────┘         └────────────────────┘

Two consequences fall out of that picture:

1. The model work runs on your subscription. The CLI authenticates the way it always has. SwarmADE never sees your key, never opens a parallel API connection, never meters those tokens. The capability you bought is the capability that does the work.
2. The code never leaves your machine to get written. The Worker edits files locally, in your repo, with your CLI's permissions. SwarmADE orchestrates; it doesn't host your source to run an agent over it.

Then what is Honey for?

If Workers run on your own subscription, what does SwarmADE charge for? The server-side orchestration: the Queen planning your spec into a DAG, and the Drones auditing each result. That work runs on our infrastructure and consumes Honey, the credit unit included in your plan.

This is why the bridge matters beyond ideology. It's the mechanism that lets the pricing be honest: we bill for the part we actually run, and we don't put a second meter on the part you already pay for.

"But I use three different CLIs"

Good — so does the Queen. The bridge is a registry, not a hard-coded integration. Each supported CLI ships a small adapter that knows how to launch it, hand it a task, and parse its output:

interface CLIBridge {
  id: string;                       // "claude" | "codex" | "cursor" | ...
  spawn(task: Task): WorkerProcess; // launch the local subprocess
  parse(output: string): Result;    // normalize its result
}

Adding a CLI is a new adapter, not a change to the orchestrator. The Queen dispatches to whichever Worker the task calls for, and a single Hive can mix them — one Worker on Claude Code, another on Aider, on the same plan.

Local execution, local permissions

Because the Worker is a subprocess on your machine, it runs with your permissions, in your working tree, behind whatever guardrails your CLI already enforces. If your CLI asks before editing files, it still asks. If it's sandboxed to a directory, it still is. SwarmADE doesn't widen that surface — it hands the CLI a task and reads back the result.

That also keeps the trust boundary where you'd want it. The cloud side sees the plan and the task outcomes it needs to coordinate and audit; it does not need a copy of your repository to spawn an agent over, because the agent is already where the repository is. Bridging isn't only cheaper than BYOK — it's a smaller blast radius.

So what

BYOK quietly assumes you have no subscription, or don't mind paying as if you didn't. Bridging assumes the opposite: that the subscription on your machine is the asset, and an orchestrator's job is to coordinate it — not to replace it with a metered API connection you're now paying for in parallel.

If you already pay for a coding CLI, that's the Worker. SwarmADE plans the work and audits the results; your subscription writes the code.

• The mechanics: Bringing your CLI and CLI bridging.
• The economics: Honey, explained.

Ready to point your CLI at a real plan? Start a Hive.