{
  "$type": "site.standard.document",
  "bskyPostRef": {
    "cid": "bafyreig3mbsgsoq352hx6hrgqvwpor4rnbpw3pfs4sid33pjtzpjvjmsoi",
    "uri": "at://did:plc:pgryn3ephfd2xgft23qokfzt/app.bsky.feed.post/3mpnvncwcyuv2"
  },
  "path": "/t/show-hf-a-local-first-runtime-ai-gateway-for-coding-agents-built-in-mcp-local-model-orchestration/177316#post_4",
  "publishedAt": "2026-07-02T10:08:40.000Z",
  "site": "https://discuss.huggingface.co",
  "tags": [
    "(click for more details)"
  ],
  "textContent": "Hmm… For now, organizing this as far as I can tell:\n\n* * *\n\nI read this less as “another local model runner” and more as a **local development control plane for coding agents**.\n\nThat framing makes the three questions easier to answer:\n\n  1. **Containers / VMs / bare-metal:** I would not choose one by ideology. I would choose by the boundary I want the agent to operate inside.\n  2. **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.\n  3. **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.\n\n\n\nSo my short version is:\n\nGoal | I would look first at…\n---|---\nTouch real local DB / DNS / SSL / web-server state | ServBay-like local runtime / control plane\nReproducible team or CI-like setup | Dev Containers, Docker Compose, DDEV-style setups\nReducing blast radius for autonomous actions | VM / sandbox / disposable environment\nAPI key governance | Local gateway with scoped virtual keys, budgets, revocation, audit\nLocal LLM experiments | model × runtime × parser × client × task matrix\nHelping future readers evaluate the system | public tool manifest + approval/audit examples + small reproducible traces\n\nThat 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**.\n\n1. 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)\n\nMy main suggestion would be: keep showing the feature list, but also publish a few small **evaluation artifacts** :\n\n  * a public MCP tool classification table\n  * one or two end-to-end agent traces\n  * example approval prompts\n  * example audit logs\n  * a rollback matrix\n  * a local model compatibility matrix\n  * a gateway key-scope / budget example\n\n\n\nThat would make the idea easier for other developers to test, compare, and adopt without needing to infer the boundary from marketing copy or screenshots.",
  "title": "Show HF: A Local-First Runtime & AI Gateway for Coding Agents (Built-in MCP + Local Model Orchestration)"
}