Epic: Hosted mode. Run the agent on a server instead of the laptop / local machine

[suleimansh]

Epic: Hosted mode. Run the agent on a server instead of the local machine

Direction question, not scheduled work. Splits into a small phase 1 and a much bigger phase 2. I mainly want a yes/no on phase 1, and on which credential model phase 2 would use.

The pain

Install on your machine, run node, add a project by local path. Fine for one dev, but concurrency is capped by the laptop's CPU and the laptop has to stay awake for the whole run.

Phase 1: connect to your own server (small)

The daemon is already the thing that spawns the agent CLI. Point the client at a remote daemon and runs execute there. The run path itself does not change.

• The dashboard is already client/server (Vike SPA over Telefunc), and startDashboard already takes a host. It just defaults to 127.0.0.1 and the daemon never overrides it.
• So this is: bind non-loopback, add a shared token, and let the client hold connection profiles (Local / My VPS).
• This is where App instead of localhost? #411 fits. A desktop app is the client, and the server becomes swappable. Keep it thin (a window plus connection profiles) so the SPA stays same-origin with its daemon. Bundling the SPA and pointing RPC at an arbitrary origin would drag in CORS and more auth for no gain.
• Credentials are a non-problem here: one user per server means you run claude once on your own box, exactly like your laptop today. No stored tokens.
• No accounts, no database, no tenancy, so it does not collide with Epic: Daemon + gateway split — headless 24/7 runtime, composable frontend #605 / Database #313.

Non-negotiable: the daemon has no auth at all today (no token, session, cookie or origin check anywhere). Its security is entirely "it is bound to loopback". An exposed daemon that spawns processes is remote code execution for anyone who finds the port. A shared token is the minimum, and it ships in the same change as the non-loopback bind, not after.

Phase 1 alone removes the CPU ceiling and the lid problem, which is the pain we actually started from.

Phase 2: one server per org (big)

Many users on one server. Sign in with GitHub and that is the whole setup: repos are there, runs execute on the server, PRs come back to GitHub.

What phase 1 does not give us:

1. Identity. GitHub login as a GitHub App, which yields the user, the org (our tenancy boundary), repo access, and a token to clone and open PRs. Today all git and PR work rides on the machine's ambient git and gh.
2. Projects stop being local paths. $HOME/.the-framework.json is one user on one machine pointing at existing checkouts. Hosted, a project is a repo the server clones. .the-framework/ stays the source of truth, so git-as-data survives. The server needs only users, org, tokens, project list, run index. SQLite is enough.
3. Isolation. A run is spawn(detached) inheriting the machine's ~/.claude. With N users on one box, each run needs its own worktree and sandbox, plus per-user quota.
4. Per-user auth on every write. A read-only relay is fine unauthenticated. A multi-user daemon is not.

The phase 2 blocker: whose subscription

BYOS (#495) works because the CLI runs under your own local login. Fine with one user per server. With many users there is no single login.

• (a) Per-user token server-side. User pastes a claude setup-token once, we run their agent on their subscription. Keeps BYOS economics. Cost: we hold user credentials.
• (b) Org API key. Simplest to run, but pay-per-token, which throws away the reason BYOS exists.
• (c) Claude Code on the web (Drive Claude Code on the web instead of the CLI (MVP shortcut: free worktrees + PR, 0% local CPU) #610). Zero CPU for us too, but the fire API gives no stream and no read-back, so live logs, turn gates and the whole AWAIT layer stop working. A fire-and-forget run mode, not the architecture.

I would do (a) by default, (b) as an org option, (c) later as a per-run offload.

Related

• App instead of localhost? #411 (desktop app) is phase 1's client, not a competing direction.
• Epic: Daemon + gateway split — headless 24/7 runtime, composable frontend #605 is the right home for the runtime half. It commits to "no database and no real server are needed", and Database #313 says the same (.the-framework/ is the database). Phase 1 respects that. Phase 2 is the first thing that stance cannot express, so it is a decision to make rather than drift into.
• Epic: Org layer — company / department / project scopes #607 assumes members and scopes but files no auth mechanism. Phase 2 supplies it. Epic: Collaboration layer — agents as teammates in the comms layer #606 assumes a user system too.
• Syncing UI<->data #454 (source of truth) should not be answered separately from phase 2.
• Nothing is filed today for accounts, GitHub login, deployment, authz, tenant isolation, per-user credentials, or billing.

Ask

1. Build phase 1? It is small and standalone.
2. Is phase 2 the shape of the product (hosted per org, local install as the OSS/dev mode), or is local-first the product and hosted a later paid tier?
3. If phase 2: which credential model, (a), (b) or (c)?

[suleimansh]

🤖 curated · Fable 5, effort high

Status update, five weeks on.

Phase 1 is built. Non-loopback bind behind a generated shared token, saved remote devices (dashboard here, agents on another machine's daemon), and the no-auth gap is closed (#1387, #1517). Ask 1 is answered.

Option (c) is stale. Cloud sessions now stream: the Driver tab (#1332) mirrors the conversation turn by turn and questions are answered from the dashboard. It is a real run mode, not fire-and-forget.

Phase 2, reframed (Discord with Rom, 2026-08-25). Not a multi-tenant per-org server with accounts and a DB — one private box per team:

• the daemon + shared sandboxes for humans and agents
• optional self-hosted models for privacy / on-prem teams
• price = box size × agents they run; tokens stay with Anthropic/OpenAI, the margin is the box + orchestration
• credential model is (a) on the team's own box, so nothing leaves the team and BYOS economics hold
• viable only zero-touch: one image, one command, no snowflake servers

If TF becomes "a bunch of skills" (Rom's idea from the same conversation), the box's job shrinks to scheduler + sandboxes + human inbox, which fits.

Numbers (rough, Aug 2026 list prices)

What a box costs us, and what a team would pay for it:

Box	Runs	Our cost	Team price
Shared 4 vCPU / 8 GB (Hetzner CX3x)	2–3 agents	~€10/mo	~€40/mo
Shared 16 vCPU / 32 GB (CX52)	~10 agents	~€35/mo	~€100/mo
Dedicated 8 vCPU / 32 GB (CCX33)	~10 agents, no noisy neighbours	~€140/mo	~€300/mo
+ GPU for self-hosted models (GEX44 class, 20 GB)	one 30B-class model	~€185/mo	~€400/mo

Reference points: E2B Pro is $150/mo flat; Daytona/E2B compute is ~$0.05 per vCPU-hour. A team running 10 agents 8 h/day on E2B-style per-second billing lands in the same €100–200/mo band, so the box prices above are market-normal, not a discount.

What that adds up to: a team pays €40–300/mo (€400–700 with a GPU), we keep roughly 2/3 of it before support. 100 teams ≈ €10–20k/mo gross. That is a product line, not a company — the tokens (10–50× the box cost for an active team) stay with the model vendors. It only stays profitable if deploy and upgrades are zero-touch; one hand-held server per team eats the margin.

Self-hosted models

The GPU row is the privacy/on-prem option, not a cost saver: ~€185/mo of GPU buys roughly what €100–200/mo of DeepSeek/Qwen via API buys, so it only wins when code cannot leave the box or the GPU runs near-full. Plumbing is cheap — Claude Code takes ANTHROPIC_BASE_URL, so a vLLM/Ollama endpoint on the box is a driver-picker knob. The fit is the auto-model-chooser from VISION.md: open model drains quick-win / low-uncertainty tickets, Claude does the hard ones. A 20 GB card runs a 30B-class coder for ~2–3 agents; 70B-class needs the €900/mo 96 GB card.

Revised ask: is the per-team box the shape of hosted mode? If yes, the open items are the image/deploy story and sandbox sharing; identity, tenancy and per-user auth from the original phase 2 mostly fall away.

[suleimansh]

The feature list, security first — since that's the pitch to companies:

Security

• Agents run in containers on the team's box, never on a developer's machine
• One vault for secrets; each agent gets a scoped, short-lived token
• Egress allowlist: an agent reaches GitHub and the model vendor, nothing else
• Audit log of every action an agent took, per run

Compliance

• Code never leaves the team's box or region (EU box for EU teams)
• Self-hosted model on the GPU row for repos that can't go to a vendor at all

Control

• Budget cap per team (agents, tokens); approve or kill any run from the dashboard
• SSO login, roles per repo

Always-on & shared

• Routines run 24/7, independent of anyone's laptop
• One queue and one "what's running" view for the team; sandboxes and previews teammates can open

Zero ops

• Log in and it works; we ship the image and the upgrades

Phase-1 remote daemon already covers the always-on row for a single user; everything under Security and Control is new work and is what a company would pay for.

🤖 curated