The default way to use a coding agent in 2026 is still a CLI pointed at someone else's API. Over the past three months a visible number of Hacker News launches have argued against that default, each from a different angle: run it yourself, sandbox it, give it its own wallet, or make it part of the application it acts on.
This is a survey of eleven of them, grouped by what they are actually for.
Harnesses that drive agents you already subscribe to
The strongest argument for self-hosting is cost, and Munder Difflin makes it bluntly. It is a free, open source multi-agent harness for Claude Code, Codex and more, and its pitch is that it runs an entire office of AI employees against the subscriptions you already pay for, using hourly limits rather than separate metered billing. It ships for macOS, Windows and Linux. The design acknowledges a reality the API-only players have to ignore: many developers already pay a flat subscription and would rather use the headroom than open a second billing relationship.
Matt Pocock Skills is a smaller contribution to the same stack, but a useful one for anyone building their own. It is a published .agents directory of skills that work in practice, not a framework. Read your first few skill files from somewhere real rather than inventing conventions, and this is the cheapest way to do it.
Sandboxing and the secrets problem
The reason most teams do not let agents loose is not capability, it is liability. OneCLI is built directly against that objection. It describes itself as an open-source sandboxed agent harness for teams, aiming to give every employee a secured personal agent. The interesting part is the credential handling: secrets are routed away from the agent rather than handed to it, which is the difference between a pilot and an abandoned pilot.
Docker Agent solves the adjacent problem of reproducibility. Being an AI agent builder and runtime from Docker Engineering, it packages an agent and its dependencies as a container, so a run that works on a laptop works identically in CI. If your team already runs Docker, this is the least alien way to add agents to a pipeline; if you do not, the extra build overhead will feel like a tax.
Terminal-first agents with a different loop
Not every harness assumes the standard observe-decide-act tool-call loop. Bough flips it: the model writes one program that does the work rather than calling tools one at a time. Twenty tool calls become one script, which cuts latency and tokens on multi-step tasks, at the price of a larger unit of code to review. It is very early and single-purpose, which describes most of this category accurately.
Kli takes the opposite bet. It is a coding agent written in Common Lisp built to be radically extensible, so behaviour is changed by rewriting the agent in Lisp rather than by toggling options. If you already write Lisp this is obviously appealing; if you do not, it is interesting mainly as evidence that the harness layer is now contestable.
Agents inside applications
The most conceptually distinct tool in this batch is Legion, an Elixir runtime for AI agents that live inside your application and act by writing code. You decide which functions the agent may touch, and the same agent can then sit behind a chat window, be served as an MCP server for Claude or Cursor, or run as a background worker that clears a queue overnight. That last deployment shape is the one worth thinking about: it is an agent as infrastructure, not an agent as a chatbot.
StemJSON takes the integration idea further with a declarative JSON language that turns descriptions into native mobile app features, shipped with an MCP server so an agent can generate UI from chat. It targets the case where you want the agent to extend a running application rather than talk to it.
Workspaces you can point at an agent
AgentsDock is an IDE designed for agentic AI research that supports Claude Code, Codex, OpenCode and Cursor in one workspace, with desktop and mobile clients. Its differentiator is the phone: the pitch is checking how a run is going from a train instead of needing the laptop that started it, and receiving images and results back.
Masala is a research workspace where an agent works beside you, combining chat, PDFs, notebooks and files in one dock, and building custom panes on request. Agent-built panes are the genuinely unusual part; most workspaces render whatever the agent says, whereas here the agent can construct the interface it needs to show you something.
ENZO rounds out the group as the self-hosted workspace play. It runs agents, skills and tools such as Gmail and Calendar on your own provider API keys, supporting Groq, OpenRouter, NVIDIA, Hugging Face and Google AI. For organisations that cannot send data into a hosted AI workspace, bring-your-own-key is the only shape that passes review.
Letting agents spend
Two tools in this batch handle money, which is a smaller category than it should be. OpenSpender is a self-custodial wallet for agents: you define limits and an address, and agents spend and send money to each other from an allowance. It is a better primitive than an API key with a large cap, and it is early.
Recurse approaches the same problem from the spending side rather than the holding side. It gives an agent access to hundreds of APIs through one account, so you build and deploy API-powered tools without wiring a key and client for every provider. Both add a dependency, and in both cases the value is entirely in how often your agents make paid calls.
What to pick
If you run one coding agent on your own machine and it works, none of this is for you yet. The moment a second agent, a second person, or a second environment enters the picture, the failure modes these tools exist to prevent arrive together: irreproducible runs, shared credentials, no visibility into spend, and no way to check on a job that outlives your laptop.
The reasonable order is reproducibility first (Docker Agent), then the credential boundary (OneCLI), then whatever your specific workload needs from the rest.
