PrimeSwarm vs Blue

Not a competitor — an adjacent layer, and a genuinely useful one to study

Blue (BlocksOrg/blue) is a very young project — MIT-licensed, created 2026-09-03, still shipping daily commits — but well-architected enough to be worth a real comparison rather than a dismissal. It solves a different problem than PrimeSwarm does, and reading its source turned up a real gap in our own code that's now fixed.

What Blue actually is

Blue is a self-hosted "metaharness" — a control plane plus a workstation CLI (blue codex, blue claude, blue kimi, blue opencode) governing which coding-agent CLI a developer launches and how it's configured: allowed harness versions, MCP server and plugin distribution, OIDC/SCIM identity, and an optional inference gateway that keeps provider credentials server-side. From Blue's own security model:

"Blue governs agents through configuration; it is not a sandbox and does not contain what an agent can do on a developer's machine." — SECURITY.md

That sentence is the whole comparison in one line. Blue's authority ends at launch time. What the agent then actually does — which action executes, whether authority granted at proposal time still holds by execution time — is explicitly out of scope for Blue, and squarely PrimeSwarm's job.

Where the two would stack, not compete

Layer	Blue	PrimeSwarm
When	Before the agent process starts	On every proposed action, and again at execution
Unit of control	Which CLI, which version, which MCP servers	Which action, for which identity, under which policy
Identity	OAuth device flow, OIDC, SCIM provisioning	OIDC-verified identity bound to signed tokens
Revocation	Deactivate a user, rotate a session	Revoke an actor mid-lifecycle — proven live to cascade through a delegation chain

A developer launching blue claude and a DGV-gated action inside that session aren't in tension. Blue decided the session was allowed to start with this configuration; DGV decides, per action, whether it's still allowed to run. A customer running both isn't running two competing governance products — they're running two different layers of the same stack.

What Blue's own code turned up — a real fix, not a marketing point

Blue's evidence-upload flow presigns a client upload directly to blob storage, then has its Control API "verify object size and SHA-256 metadata before registering the artifact" — the server never receives the raw bytes, but it never trusts the declared hash either. Checking our own code against that standard found a real gap: DGV's evidence registration accepted a content_ref and a declared SHA-256 with no way to ever confirm they matched — verified sat permanently at false, on pure self-report.

Fixed this month: POST /evidence/artifacts/:id/verify fetches an https:// reference itself, hashes it, and flips verified on an actual comparison — proved live, including the deliberate-mismatch case staying correctly unverified. That's the direct, traceable value of reading a much smaller, much newer project's source carefully instead of only benchmarking against the largest names.

What we are not claiming

• We are not claiming Blue is a competitor. It solves a real, different problem — pre-execution CLI and configuration governance — that PrimeSwarm doesn't touch.
• We are not claiming our evidence-verification fix was originally our idea. It wasn't — it's Blue's pattern, adapted to a gate that doesn't (yet) have its own object storage.
• We are not claiming Blue is mature. It's two weeks old at the time of writing. Worth tracking as it grows, not treating as settled.

Where to look

• Read the full technical positioning note, including three more concrete things worth learning from Blue's architecture beyond the one we've already shipped.
• The evidence-verification fix itself, live-tested, is documented in the "Public, Chained, Provable" update.