L9Lesson 5

Hosted or Self-Hosted

After this, you'll be able to classify any background agent task as hosted-suitable or self-hosted-required, and explain the tradeoffs that drive that decision.

Before you start

Complete Stale Context Is Not a Stale Bug first; this lesson builds on coordination overhead so you factor branch-isolation complexity into the hosted-vs-self-hosted tradeoff.

The idea

Here is the before and after: You want to refactor a public utility module. You could connect it to Devin or OpenAI Codex cloud: paste the task, get a PR in 10 minutes, no setup required. Or you could run Claude Code in headless mode on your own machine: more setup, but it can read your internal fixtures, call your private APIs, and apply your custom CLAUDE.md rules. Which one? It depends entirely on what the task needs.

Hosted agents (Devin, OpenAI Codex cloud, GitHub Copilot Workspace) run in the provider's cloud. You give them a task, they open a PR. No machine to configure, no session to manage. The cost is less control: the agent uses the provider's environment, its tool set, and its data handling policy.

Self-hosted agents (Claude Code in headless mode, open-source orchestrators you run yourself) run on infrastructure you control. You can access your local environment, proprietary context, private API keys, and custom hooks. The cost is setup and maintenance.

The decision is simpler than it looks. Use hosted when: the task is bounded and well-specified, the codebase can be shared with the provider, no proprietary secrets are involved, and lower execution visibility is acceptable. Use self-hosted when: the task requires internal secrets or tools, the codebase cannot leave your infrastructure, you need custom approval hooks, or you need to call services with no cloud equivalent.

Desktop path: if you use Claude.ai web, hosted agents are your natural starting point. Connect your GitHub repo to a hosted provider and run bounded tasks there. For anything requiring your local environment, switch to Claude Code CLI in headless mode.

CLI path: `claude --headless` runs Claude Code as a self-hosted agent on any machine you control, with full access to your local context and custom CLAUDE.md.

Most production L9 teams use both. The skill is knowing which is which before you dispatch.

Try it (15 min)

Watch out for

Defaulting to self-hosted because it feels more in-control. Setup cost is real cost. If a hosted agent handles the task well, the infrastructure burden of self-hosted is pure overhead.
Sending proprietary secrets or internal API keys to hosted providers. Check the provider's data handling policy before connecting any production credential.
Assuming hosted agents cannot be customized. Most hosted providers allow custom instructions and repo-level configuration. Read the docs before concluding a task requires self-hosted.
Using hosted agents for tasks with Tier 3 blast radius. Any task that modifies production state or sends messages to real users needs approval gates you control.
Switching infrastructure mid-project. Pick one for a given task type and stick with it until you have a specific reason to change. Switching mid-run produces unresolvable state.

Paste this into Claude:

I want to classify my background agent tasks as hosted-suitable or self-hosted-required. Here are 5-6 tasks I run or want to run as background agents: [list your tasks, e.g. 'refactor a public utility module', 'update all doc comments', 'run the security scan and open an issue', 'generate integration tests using our internal test fixtures', 'update the public API changelog']. For each task, evaluate: (1) Does it require proprietary secrets or internal tools? (2) Can the codebase context be shared with a hosted provider? (3) Is the task well-specified enough for a hosted agent's standard environment? (4) What is the blast radius if the hosted agent makes an unexpected change? Then give me a hosted/self-hosted verdict for each task with a one-sentence reason.

What good looks like:

You classified each task with a specific reason, not just a gut feeling
At least one task moved from your assumed category to the other based on the evaluation
You identified any proprietary context or secrets that make a task self-hosted-required
You can describe what you lose and what you gain with each choice for your specific setup
You have a written rule for your team: 'We use hosted agents for X, self-hosted for Y'

When this breaks

Breaks when self-hosted is the default for tasks the provider could handle because the maintenance overhead of running your own infrastructure consumes more time than the agent saves, and the fleet stops paying for itself.
Breaks when proprietary secrets cross into hosted provider environments because the data handling policy you did not read becomes a compliance incident, and the breach surfaces months after the credentials leaked.
Breaks when the hosted-vs-self-hosted decision is made per-developer rather than per-task because team rules drift, the same task ends up on different infrastructure depending on who dispatched it, and the resulting inconsistency makes any incident impossible to debug.

Claude can do it for you

Say to Claude: 'I have these background agent tasks: [list]. For each one, tell me: hosted or self-hosted, and what is the deciding factor. Then draft the one-page decision guide I can share with my team so they can classify new tasks themselves.'

You can now

Classify five tasks as hosted or self-hosted with a specific deciding factor for each, and write a one-sentence team rule that any teammate could apply to a new task without re-litigating the decision.

Key takeaways

Hosted for bounded, well-specified, shareable tasks. Self-hosted for proprietary context, custom tooling, and tight blast radius control. Most mature setups use both.

Hosted agents trade control for setup cost. Self-hosted trades setup cost for control. The right answer is per-task, not per-team
Proprietary secrets, internal fixtures, and custom approval hooks are self-hosted markers. If any of those apply, hosted is wrong
Bounded, well-specified, public-code tasks are hosted-natural. Defaulting to self-hosted out of habit is paying setup cost for no benefit
Most mature L9 setups run both. The skill is classifying each task before dispatch, not picking one infrastructure for everything

Go deeper

I want to classify my background agent tasks as hosted-suitable or self-hosted-required. Here are 5-6 tasks I run or want to run as background agents: [list your tasks, e.g. 'refactor a public utility module', 'update all doc comments', 'run the security scan and open an issue', 'generate integration tests using our internal test fixtures', 'update the public API changelog']. For each task, evaluate: (1) Does it require proprietary secrets or internal tools? (2) Can the codebase context be shared with a hosted provider? (3) Is the task well-specified enough for a hosted agent's standard environment? (4) What is the blast radius if the hosted agent makes an unexpected change? Then give me a hosted/self-hosted verdict for each task with a one-sentence reason.

Say to Claude: 'I have these background agent tasks: [list]. For each one, tell me: hosted or self-hosted, and what is the deciding factor. Then draft the one-page decision guide I can share with my team so they can classify new tasks themselves.'