Why you should be able to self-host your agent runtime

In May, Cognition put self-hosted Devin into maintenance mode. The reason they gave was blunt: "hosting even our best Tab model would require a full rack of frontier GPUs to serve." A month earlier, Anthropic started blocking third-party harnesses from running against the Claude Code subscription, which pushed power users back onto the official harness. Two retreats in two months, and one lesson for anyone evaluating an agent for a regulated environment: if your agent runtime depends on a single vendor's billing model, regional availability, or ban policy, your team is one announcement away from a forced migration.

This post is not a case for everyone running their own infrastructure. Most teams should not. It is a case for the option existing, and for being clear-eyed about which parts of an agent actually have to run on your hardware when your compliance posture requires it.

Two recent retreats

Cognition retires self-hosted Devin

On 2026-05-12, Cognition moved self-hosted Devin into maintenance mode. Their stated reasoning is worth reading in full, because it is an engineering constraint and not a growth tactic. Alongside the frontier-GPU line, they wrote that "self-hosted will, within time, not be the answer for over 99% of developers." For a customer who had already deployed Devin inside their own network, the practical translation is that the on-prem path they bet on stops receiving new capability. If a compliance requirement was the reason you chose self-host, the vendor has told you that reason is not on their roadmap. We walked through the wider Devin tradeoffs in Nairi vs Devin.

Anthropic blocks third-party harnesses

In April 2026, Anthropic began blocking third-party harnesses from the Claude Code subscription. The Hacker News reaction was less about the specific policy than about the pattern it fit. One commenter: "people become irate when they feel there's been a bait-and-switch." Another was already shopping for an exit: "I'll be downgrading my subscription to the $20/month plan… and will figure out a better provider for the agentic tooling." It rhymes with Cursor's 2025 pricing migration, which a long-time user summed up as "classic enshittification on the formerly premium options. Very frustrating for long term supporters."

The common thread is not that any one of these vendors did something malicious. It is that the terms under which your agent runs can change without your input, and when they do, you have very little recourse if the whole stack lives on someone else's infrastructure.

What buyers actually need

If you are the engineer signing off on an agent for a regulated workload, four properties matter more than any feature list.

Self-host the runtime, where the data actually is. The model calls, code edits, tool invocations, and secret access have to happen inside your network boundary. Inference-only "self-host," where the model sits in your VPC but the orchestration stays vendor-side, does not solve data residency, because the agent's actual work still crosses the boundary. This is the property to interrogate hardest, and it is where you should demand a precise answer rather than a marketing one. We will be precise below about the line Nairi draws here, because it is not a claim of self-hosting the entire stack.

Harness choice. Whether your agent runs Claude Code, Codex, OpenCode, or Cursor should not be dictated by the workspace tool you happen to buy. Cognition's Devin Cloud locks you to Devin's harness. A runtime that lets you pick the harness per agent keeps you from betting the team on one vendor's model access surviving the next policy change.

Customer-controlled LLM costs. The provider bill should pass through to your own key, whether that is Anthropic, OpenAI, or Google, with no abstraction layer like ACUs sitting between the tokens you spend and the price you pay. Then a vendor changing its own subscription terms does not silently reprice your agent.

No mid-year metering changes. When a vendor reprices, your budget breaks. Pre-committed terms, in a contract, are the only thing that stops a Tuesday-afternoon pricing post from becoming a migration project.

The honest concession

Full self-hosting has real costs, and pretending otherwise would be its own kind of dishonesty. You take on the ops burden of running the runtime, the security responsibility for the box it runs on, and the scaling work when usage grows. For most teams that math does not favor self-host, which is exactly why Cognition's retreat is rational rather than villainous. Serving a frontier model on-prem genuinely does want a rack of GPUs, and supporting that path for a shrinking share of customers is expensive. The claim here is narrow. It is not that everyone should self-host. It is that if your compliance or risk posture needs it, the option should exist, and the vendor should be honest about which parts of the system it actually covers.

What Nairi does today

Here is the precise line, because vague answers are the problem we are trying to avoid.

The agent runtime, nairid, is open source and runs on your hardware. Model calls, file edits, branch pushes, PR creation, secret access, and tool calls all happen on your side. The event-orchestration backend, the service that turns a Slack mention or a scheduled job into a routed event and delivers it to your runtime over a WebSocket, is closed source and runs on Nairi's infrastructure. We are not going to pretend that part is open. Managed orchestration is what makes the Slack and Discord first multiplayer experience work at all, and a single-tenant backend per customer would defeat the point of a shared team agent.

That split is the right architecture for data residency, because the agent's work and its access to your code and secrets never leave your infrastructure. It is not the right architecture for full vendor-independence, because trigger routing still depends on our backend being up. Both of those are true at once, and a buyer deserves to hear both. The self-hosting docs lay out exactly where the boundary sits.

On the other three properties: you pick the harness per agent across Claude Code, Codex, OpenCode, and Cursor. You bring your own LLM key so the provider bill is yours at cost, with the details on the pricing page. And for most readers, managed hosting stays the default. What we sell is the option to move the work onto your hardware when you choose to, not an obligation to. If you are comparing this against Anthropic's own team offerings, we broke those down in Nairi vs Claude Managed Agents and Nairi vs Claude Code for Slack.

What Spotify's Honk tells us

There is a version of this that the most sophisticated engineering orgs are already building for themselves. At Anthropic's developer conference, Spotify's Niklas Gustavsson described Honk, a background coding agent his team built on the Agent SDK and wired into Spotify's internal tool catalog and migration platform. His conclusion was that the same standardization that makes human teams effective, firm guardrails and a shared catalog, makes agents effective too.

Every CTO who watched that talk now has some version of "build our own Honk" on a roadmap doc. Most of them will not staff it, because a multi-tenant, sandboxed, tool-aware agent platform that runs from chat is a serious platform-team project before it is wired into secrets, approvals, and scheduling. That is the gap we build for. The architecture Spotify described, background agents wired into a shared tool catalog with firm guardrails, is the one we productized, so a team that cannot dedicate a platform team to the problem still gets to run its own agent on its own terms.