Running AI Coding Agents in Production: My 2026 Stack

An independent developer published a detailed account of running AI coding and automation agents in production as of August 2026, combining opencode, Claude Code/Codex, and Nous Research's Hermes across three gateways (OpenRouter, Merge, and Vercel AI Gateway). The setup routes all model calls through gateways to centralize credentials and enable kill switches, keeps secrets out of agent context via a runtime injection layer, and uses the developer's open-source 'trustless' credential broker with DLP scrubbing and per-call authorization. The developer argues that an unattended coding agent is an ops problem rather than a coding problem, citing agents leaking API keys into logs and debug output as the recurring failure.

Everyone has an opinion about AI agents. Almost nobody publishes their actual production setup — the gateways, the MCP servers https://agentjournal.dev/blog/mcp-server-security/ , the credential handling, the monthly bill. This is mine, as of August 2026, with real numbers and the failures included. I run coding and automation agents daily for real work: this site, open-source tooling, and the automation that runs my infrastructure. Here's the stack, layer by layer. The agents division of labor I don't use one agent for everything. Using the right tool per task is the cheapest optimization available: - opencode — my open-source coding agent for repository-scale work. Runs with a local provider config, executes code, verifies results. It's the workhorse for feature work where I want full control of the loop. - Claude Code / Codex — used for sessions where their specific strengths apply long-context refactors, or tasks tuned to their model families . I treat them as specialists, not a default. - Hermes Nous Research — the automation layer. Cron jobs https://agentjournal.dev/blog/cron-job-monitoring/ , scheduled pipelines, monitoring: things that run while I sleep and message me when they break. This is the agent that writes the drafts for this site, runs my infrastructure checks, and handles repetitive ops. The rule I've landed on: a coding agent that runs unattended is an ops problem, not a coding problem. Which is why the layers below matter more than which agent you pick. The gateway layer Routing through gateways instead of calling providers directly is the single biggest sanity improvement. I use three: - OpenRouter — the default router for experimentation. The free tier covers low-stakes calls, and the model catalog means I can A/B test providers without touching config. OpenRouter https://openrouter.ai/ - Merge — my main paid gateway. One API for the models I use daily, with cost tracking https://agentjournal.dev/blog/merge-gateway-pro/ across agents. At $10/mo it pays for itself in what it stops me from overspending on direct API calls. Merge https://merge.dev/ - Vercel AI Gateway https://agentjournal.dev/blog/vercel-ai-gateway-free/ — for the projects already on Vercel's stack. Its free tier $5 of credits per 30 days handles the low-volume path fine; I only reach for it when the project is already there. Vercel https://vercel.com/ Why gateways and not direct API keys? Because every agent that holds a direct provider key is a credential you're one prompt injection away from leaking. Gateways centralize the key, give you a kill switch, and make the bill auditable. This matters more than any model choice. Credential handling the part nobody writes about This is where most agent setups are a disaster waiting to happen. My rules: 1. Secrets live in pass / Bitwarden, never in agent context. Agents get credentials via an injection layer at runtime, not by reading a .env that sits in the repo. 2. I maintain trustless https://github.com/ikkun1222/trustless — an open-source credential broker that serves secrets to agents through a local proxy, with DLP scrubbing and per-call authorization. It exists because I watched agents echo API keys into logs, chat history, and debug output. Once per week was too often. 3. Long-lived keys are the enemy. Refresh tokens that rotate, short-lived sessions, and per-service keys scoped to exactly one tool. When a key leaks it will , the blast radius is one service, one function. MCP servers and tooling The MCP layer is where the real leverage is. Currently running: - Filesystem + git servers — for agent access to repos without shelling out into the filesystem blindly - Web search / fetch servers — the ones that make agents useful for research without hallucinating URLs - Home-grown servers for my own infra — including a server that wraps my credential broker so agents can request secrets through a structured interface instead of me pasting them The lesson: a well-scoped MCP server beats a prompt telling the agent to "be careful" every time. If the agent can't reach it, it can't break it. Networking and self-hosted pieces - Tailscale — all agent access to my infra goes over the tailnet; SSH is not exposed publicly. Agents reach services by tailnet name, which also means the public attack surface https://agentjournal.dev/blog/tailnet-for-agents/ is ~zero. Tailscale https://tailscale.com/ - Cloudflare — DNS, Pages this site , Workers, and the edge layer. The free tier covers everything this site needs. Cloudflare https://cloudflare.com/ - Qdrant https://agentjournal.dev/blog/qdrant-selfhosted/ + Mem0 — self-hosted memory/vector layer for the automation agent. Running my own instance means the agent's memory never leaves my server. Qdrant https://qdrant.tech/ - vLLM — for the local models I run a small Japanese-optimized model does embedding and light extraction work . Keeping boring inference local cuts gateway spend measurably. The bill real numbers Monthly, as of this writing: | Layer | Cost | | Gateways Merge Pro + Vercel free tier + OpenRouter free | ~$10 | | Cloudflare DNS + Pages + Workers | $0 | | Self-hosted infra cloud free tiers, one cheap VPS | ~$5 | | Total | ~$15/mo | The trick is boring: route the expensive calls through the free tiers, self-host the repetitive work, and let the gateways absorb the variance. I've seen the same setup run $200+/mo when the routing is lazy. What I'd change / what's broken - Context management is still the bottleneck. Long-running agents degrade; I still restart sessions more than I'd like. - The agents occasionally fight each other — two automation runs touching the same state. File locking and job ownership markers helped, but it's not solved. - Model quality is uneven across providers. The gateway makes switching cheap, but "cheap to switch" means I spend more time evaluating than I'd like. The agent you pick matters less than the plumbing around it: gateway routing, credential hygiene, scoped MCP access, and a tailnet. Get those right and you can swap models and agents freely — which is exactly what you'll want to do, because this space moves monthly. This is the first post in what will be a series on the details: MCP server design, gateway cost engineering, and credential handling for agents. If you're running agents in production too, I'd like to hear what your stack looks like https://github.com/ikkun1222 . Disclosure: some links in this post are affiliate links — see disclosure https://agentjournal.dev/disclosure/ . Originally published at agentjournal.dev https://agentjournal.dev/blog/running-ai-coding-agents-in-production/ .