Why I built a Trust Control Plane for AI instead of another cost router

Ankit — Sat, 25 Jul 2026 19:34:58 +0000

Every AI router I tried optimized for one thing: cost. None could answer the question I actually cared about: how confident are we that this answer is correct, and what breaks if it's wrong?

So I built Hydra, a local-first CLI I'm calling a Trust Control Plane. Instead of routing purely on price, it routes on calibrated confidence, on your own hardware.

How it works

Run hydra probe and it discovers every model on your machine: CLI agents, API keys, and local servers. Then hydra dispatch classifies a task and routes it down a cost ladder to the cheapest head that clears your bar.

Three mechanisms drive the router:

Cost/quality Pareto routing. Single models are dots on a cost/quality plot. The routed curve reaches equal or better quality at lower cost by picking the best head per task, not one model for everything.
Optimal stopping (SPRT). It polls heads until a sequential probability ratio test crosses your target confidence (say 0.95), then stops early and banks the unspent heads.
Blast-radius awareness. It reads the code dependency graph and uses percolation kappa (k = <k^2> / <k>, the Molloy-Reed criterion) to raise the confidence bar for hub files with many transitive dependents. A change to a widely-imported file demands more certainty before any head touches it.

Routing runs on-device with ~0ms overhead and zero network calls to decide. Local Qwen sits at the bottom of the ladder as an always-on fallback, so a dispatch never hard-fails on a rate limit.

The bet

Your spend, code, and policy should stay on your own hardware, and routing should be about trust, not just price.

It's early and MIT-licensed. I'd genuinely like to be poked at on two things: is SPRT the right stopping rule for "is this answer good enough," and is kappa a fair proxy for blast radius?

DEV Community: Ankit

Why I built a Trust Control Plane for AI instead of another cost router

How it works

The bet

Links