What it is
PocketBridge started as an OpenAI-compatible gateway that routes requests across providers, local models first and cloud tiers after, under a cost-aware policy. It grew from there into something closer to a full local agent platform: a hub-and-spoke Rust daemon with a workflow and scheduler engine, an MCP client, a model router, and persistent memory, with a Theia-based desktop shell sitting on top.
Why it exists
Working across a lot of AI tools means your agents, context, and history end up fragmented across vendors. PocketBridge is the other bet: a daemon you own and run locally that fronts every provider through one API and keeps agent state in one place you can actually audit.
Engineering highlights
- Rust daemon, hub-and-spoke. Providers, tools, and clients all attach as spokes, and the hub owns routing, persistence, and audit.
- Cost-aware policy routing. A request falls through a provider chain, local before cloud, with bounded failover, so a dead provider degrades the service instead of hanging it.
- An audit chain by design. Agent runs and memory writes land in SQLite behind schema migrations, with a versioned event schema so anything reading downstream can trust a replay.
- Release engineering. The v0.1.0 tag closed a 15-blocker OSS-readiness audit: a CVE gate in CI through cargo-audit, structured tracing, a pinned toolchain, changelog discipline, and honest labels on the surfaces that are still experimental.
The gate
Here is the part I would actually defend in an interview. v0.1.0 is tagged and the repository is release-ready, and it is still not public. What holds it there is a rule I wrote for myself: built is not proven. The public flip is gated on a real dogfood run, one actual task carried end to end through the platform, with a written report on whatever broke. When the release-prep momentum quietly carried past that gate, I caught the slip, wrote it into the record, and reaffirmed the gate rather than waving it through. The shipping discipline is part of what the system is for.