Show HF: A Local-First Runtime & AI Gateway for Coding Agents (Built-in MCP + Local Model Orchestration)
Hmm… For now, organizing this as far as I can tell:
I read this less as “another local model runner” and more as a local development control plane for coding agents.
That framing makes the three questions easier to answer:
- Containers / VMs / bare-metal: I would not choose one by ideology. I would choose by the boundary I want the agent to operate inside.
- API key security: I would care less about the number of supported providers and more about scoped virtual keys, revocation, budget caps, redaction, and auditability.
- Local LLMs for coding agents: I would separate “can write code” from “can complete an agentic tool loop.” The second depends on the model, runtime, chat template, tool-call parser, client, and task.
So my short version is:
| Goal | I would look first at… |
|---|---|
| Touch real local DB / DNS / SSL / web-server state | ServBay-like local runtime / control plane |
| Reproducible team or CI-like setup | Dev Containers, Docker Compose, DDEV-style setups |
| Reducing blast radius for autonomous actions | VM / sandbox / disposable environment |
| API key governance | Local gateway with scoped virtual keys, budgets, revocation, audit |
| Local LLM experiments | model × runtime × parser × client × task matrix |
| Helping future readers evaluate the system | public tool manifest + approval/audit examples + small reproducible traces |
That is not a criticism of the approach. I think the interesting part is exactly that it names a layer that many coding-agent setups currently leave half-manual: local development infrastructure as something the agent can inspect and operate through a controlled interface.
- How I would think about containers vs VMs vs bare-metal (click for more details) 2. MCP tool surface: I would make the boundary visible (click for more details) 3. API key security: I would evaluate the gateway by governance, not provider count (click for more details) 4. Local LLMs: I would separate code generation from agentic tool-use (click for more details) 5. Small reproducible traces that would be useful (click for more details) 6. The evaluation map I would use (click for more details)
My main suggestion would be: keep showing the feature list, but also publish a few small evaluation artifacts :
- a public MCP tool classification table
- one or two end-to-end agent traces
- example approval prompts
- example audit logs
- a rollback matrix
- a local model compatibility matrix
- a gateway key-scope / budget example
That would make the idea easier for other developers to test, compare, and adopt without needing to infer the boundary from marketing copy or screenshots.
Discussion in the ATmosphere