# Agent-friendly Remote Development > Persistent remote workspaces for directing coding agents across devices, repositories, and harnesses - HTML version: https://robbiepalmer.me/projects/agent-friendly-remote-development - Status: in_progress - Started: 2026-09-06 # What I am building A private remote computer for directing coding agents from a phone or laptop. Work continues after the client disconnects, and I can return without rebuilding the development environment. The workspace belongs to a person rather than a repository. It can hold related first-party repositories, third-party dependencies checked out for inspection or forking, worktrees, local services, and several agent harnesses. T3 Code provides the current control interface for Codex, Claude Code, OpenCode, Grok, terminals, browser tools, and requests that need human attention. This is separate from the Home Lab. The current deployment happens to run there, but the product question concerns remote agent workspaces, identity, access, and continuity. # What has been validated [Pull request 1183](https://github.com/Robbie-Palmer/personal-site/pull/1183) deployed the first environment to a Hetzner CX33 running NixOS and K3s. It has an encrypted persistent volume and private Tailscale access. It is now my main way of working. My laptop has become the fallback. Phone access works for directing and monitoring real work, not merely checking status. People at work are also using T3 Code. That validates the T3 interaction model and the value of remote access for me. It does not yet prove that another person can adopt my complete hosted setup, or that several user workspaces can share one machine without unacceptable interference. # Brother pilot The pilot should reuse the Hetzner server I already pay to run continuously. It does not need another VM, per-user billing, infrastructure spend caps, or a new secrets product. My brother gets: * his own K3s namespace, T3 Code process, pod identity, persistent volume, and private endpoint; * his own GitHub and model-provider logins; * access through Doppler's existing user and temporary-access controls; * resource requests and limits that protect the shared host from accidental exhaustion; and * an independently restorable and removable home directory. The workspace must not mount host filesystems, the container runtime socket, or Kubernetes credentials. It runs as a non-root user and cannot reach another user's service or volume. This remains a trusted-user container boundary, not a claim of hostile multi-tenant security. The pilot is free while it fits inside spare capacity. I will measure node pressure and operator interventions. I will not build per-user cost accounting until adding users causes a new infrastructure bill. # The first platform experiment [Coder Community](https://coder.com/pricing) looks like the most useful component to test. It is free for unlimited self-hosted workspaces. Coder can [install into Kubernetes using Helm](https://coder.com/docs/install/kubernetes), and its official [Kubernetes workspace template](https://registry.coder.com/templates/kubernetes) creates a pod with a persistent volume mounted at `/home/coder`. Coder Community is open source under the [GNU Affero General Public License v3.0](https://github.com/coder/coder/blob/main/LICENSE). Coder ships its developer-productivity tools in the open source edition. The source in the repository's `enterprise` directory has a [separate Coder license](https://github.com/coder/coder/blob/main/LICENSE.enterprise) and its production use is subject to Coder's terms or another agreement. Coder gates Premium tools behind a license key. I can charge for hosting the AGPL edition. If I change Coder and let customers use that version over a network, I must offer them its corresponding source under the AGPL. This repository already uses AGPL-3.0, so that obligation matches the intended product model and does not block a Coder Community fork. Keep project-specific code separate only where the technical boundary helps, and avoid Coder's separately licensed enterprise code. That means it can plug into the existing K3s setup. A template could package the current T3 Code image, volume, Doppler bootstrap, private application URL, and resource limits. Coder would supply user accounts, workspace ownership, provisioning, start and stop operations, and an API. T3 Code would remain the agent interface inside each workspace. The experiment should compare two implementations on the same server: 1. the smallest direct K3s definition for my brother; and 2. the same workspace managed by Coder Community. If Coder removes enough custom account, routing, and lifecycle work to justify its control service and PostgreSQL database, use it. Otherwise keep the direct K3s version. Neither option changes the Hetzner compute bill until the node runs out of capacity. Coder does not support SQLite. The standalone server can download and run a bundled PostgreSQL, but the official Kubernetes installation expects a PostgreSQL service. For this experiment I can run a small database in K3s or try my existing Neon setup. Coder uses persistent connections plus `LISTEN` and `NOTIFY` and recommends database latency below 10 ms. Neon closes session state, including listeners, when compute scales to zero. Test an unpooled Neon connection before choosing it for Coder's state. The experiment is worthwhile because Coder manages more than the database. It owns users and workspaces, runs Terraform for create, start, stop, and delete, keeps the persistent and ephemeral resources straight, tunnels private apps and terminals, tracks workspace health, and exposes the lifecycle through its UI, CLI, and API. My own alternative could be much smaller. It only needs this product's K3s workspace shape and could store its state in SQLite or the existing Neon database. The Coder test is still useful. It will show which lifecycle work I would inherit, which parts I do not need, and whether a narrow implementation is actually simpler. Time-box the test to one day and leave my current workspace untouched. It earns a place only if one template can create my brother's workspace, expose T3 Code, preserve his home across stop and start, and revoke his access with less custom code than the direct K3s definition. # Cost comparison The requirement is access at any time and uninterrupted execution while an agent is working. The table uses 730 running hours to expose the worst case where T3 Code or a task prevents automatic sleep. It excludes model subscriptions, tax, egress, and support. | Runtime | Assumed environment | Approximate monthly runtime cost | Fit | | ------------------------------- | ------------------------------------------ | -----------------------------------------------------------------: | ----------------------------------------------------------------------- | | Current Hetzner CX33 | 4 shared vCPU, 8 GB, one public IPv4 | €8.99 net in Germany or Finland | Baseline; adding another pod costs nothing while capacity remains | | Coder Community on current host | Existing K3s capacity | Same €8.99 net host bill, plus control-service overhead | Best next experiment | | Fly Sprite | Average 0.6 CPU, 1.5 GB RAM, 10 GB storage | $83.75 if it never sleeps | Attractive only if T3 and idle sessions allow reliable sleep | | Daytona | 2 vCPU, 4 GiB RAM, 10 GiB storage | $121.68 | Managed lifecycle, but far above the current always-on cost | | GitHub Codespaces | 2 cores, 8 GB, 8 GB storage | $131.96 list price, or about $120.60 after a GitHub Free allowance | Capable environment, but stops after inactivity | | Modal Sandbox | 2 vCPU, 4 GiB RAM, 10 GiB volume | About $174.61 | Maximum sandbox lifetime is 24 hours, so it is a poor persistent home | | Ona Core | 4 vCPU, 16 GB for 730 hours | About $183 to $190 from the published OCU examples | Managed product and support, but much more expensive for continuous use | | Runloop Basic | 2 CPU, 4 GB RAM, 10 GB storage | About $233.76 | Built for agent execution rather than a cheap personal workstation | Sources: [Hetzner server pricing](https://docs.hetzner.com/general/infrastructure-and-availability/price-adjustment/), [Hetzner IP pricing](https://docs.hetzner.com/cloud/servers/primary-ips/overview/), [Fly pricing](https://fly.io/sprites/), [Daytona pricing](https://www.daytona.io/pricing), [Codespaces billing](https://docs.github.com/en/billing/concepts/product-billing/github-codespaces), [Modal pricing](https://modal.com/pricing), [Ona pricing](https://ona.com/pricing/), and [Runloop pricing](https://runloop.ai/pricing). The Hetzner figure combines the €8.49 CX33 list price with one €0.50 public IPv4. Like the other provider figures, it excludes VAT, paid networking or egress add-ons, backups, and support. The Hetzner deployment is unusually cheap. Managed providers become competitive when they suspend idle environments, but that needs a real T3 Code test. Fly counts open TCP connections as activity, so a persistent connection could turn a sleep-priced design into an $80 or higher monthly environment. The cost difference supports charging more than £5 for users who value continuous availability. The brother pilot remains free. The first non-family price to test is £15 per month with BYOK and no SLA, followed by £25 only after three users renew twice. That price sells avoided setup and maintenance. People willing to operate the open source deployment on their own Hetzner account remain the cheapest competitor. # Price break-even and likely customer The fixed monthly price matters only when compared with how long somebody would run an alternative. Using the providers' published rates and the [European Central Bank reference rates for 4 September 2026](https://www.ecb.europa.eu/stats/policy_and_exchange_rates/euro_reference_exchange_rates/html/index.en.html), £1 was about $1.353. The table shows the active runtime at which each alternative would cost more than the proposed monthly price. Where a provider charges for inactive storage, the calculation keeps it allocated for the whole month. Active runtime includes unattended agent work, not only time at a keyboard. The unit is one running workspace, not one agent session. Two to five agents inside the same T3 Code workspace share the same clock. Parallel agents increase the bill only when they need separate environments, consume more metered CPU, or force the workspace onto a larger machine. The estimates below assume one environment at the listed size. | Alternative | £15 becomes cheaper after | £25 becomes cheaper after | Important assumption | | ------------------------ | ------------------------: | ------------------------: | ------------------------------------------------------------------------------------- | | Runloop Basic | 64 hours | 106 hours | Suspend and resume requires its $250 Pro plan | | Ona Core | 81 hours | 121 hours | Uses the included 80 OCUs, then whole 40-OCU add-on packs | | Modal Sandbox | 82 hours | 139 hours | A sandbox can live for at most 24 hours | | Daytona | 122 hours | 203 hours | 2 vCPU, 4 GiB RAM, and 10 GiB storage | | GitHub Codespaces | 173 hours | 248 hours | Includes the personal GitHub Free allowance of 60 runtime hours on a two-core machine | | Fly Sprite | 176 hours | 294 hours | Assumes an average 0.6 CPU, 1.5 GB RAM, and 10 GB storage while active | | Self-hosted Hetzner CX33 | Never | Never | €8.99, or about £7.72, remains cheaper before the owner's time and operational risk | For metered products, the calculation subtracts any fixed monthly base or storage fee from the monthly price, then divides by the active hourly rate. Fly's hot storage is part of that active rate; its lower cold-storage rate runs for the full month. Codespaces adds its first 60 runtime hours on a two-core machine. Ona rounds up to the next OCU pack. These are bill break-even points, not claims that the products are equivalent. They exclude tax, egress, model usage, and the value of support. They also favour products that can sleep. An open connection or unattended agent can keep the meter running. At 160 hours, the estimated bills are about £13.30 for Codespaces, £13.68 for Fly, £19.71 for Daytona, £28.81 for Modal, £29.56 for Ona, and £37.87 for Runloop. A £15 workspace sits just above the two cheapest metered choices and below the other four. Its persistent, multi-repository workflow can justify the small difference from Codespaces or Fly. A £25 price needs value beyond runtime. These thresholds describe the customer's alternatives, not my margin. Spare capacity on the current host costs nothing more. Even assigning the whole £7.72 net CX33 and IPv4 bill to one £15 customer leaves £7.28 before tax, payment fees, backups, and support. Sharing a larger host improves that figure. The unknown is how many people and concurrent agents fit before contention forces an upgrade. The best early customer treats the environment as their main development computer. They need persistent multi-repository state, remote access, and unattended execution. They could self-host, but would rather pay somebody else to handle deployment, updates, backups, and recovery. At £25, the cost case against Daytona, Codespaces, and Fly becomes strongest at about 203 to 294 active hours each month. People may still pay sooner for the workflow, but the price is harder to justify on infrastructure savings alone. Someone using agents for 20 to 60 hours each month, someone who enjoys operating their own server, or a company that needs an SLA is not the initial customer. # Work graph value The [Work Graph](/projects/work-graph) could make the subscription worth more than its compute. Paid task trackers already establish a price for shared work state. [Linear](https://linear.app/pricing) charges $10 per user per month for Basic and $16 for Business when billed yearly. [Jira](https://www.atlassian.com/software/jira/pricing) lists $7.91 for Standard and $14.54 for Premium. At the same exchange rate, those prices span roughly £5.85 to £11.83 per user per month. At 160 workspace-hours, Codespaces plus Linear Business totals about £25.13 per month and Fly plus Linear Business totals about £25.51, before Linear coding sessions. Linear charges each coding session for model tokens at the provider's published rate, without markup, plus $0.25 for every 20-minute sandbox block. At launch, Linear granted eligible workspaces a shared pool of promotional AI credits equal to $20 multiplied by the number of unsuspended users. The grant does not recur monthly. The sandbox charge alone makes a one-hour session $0.75. Twenty one-hour sessions cost $15 plus tokens; 40 cost $30; and 160 session-hours cost $120. Add the $10 Basic or $16 Business seat price. Parallel sessions each have a sandbox, so five agents running for one hour cost $3.75 plus tokens. Five agents sharing this product's persistent workspace still consume one workspace-hour, provided the host has enough capacity. Against Linear itself, £15 becomes cheaper than Basic after about 14 coding session-hours per month and cheaper than Business after about six. At £25, the thresholds are about 32 hours for Basic and 24 for Business. Those calculations exclude token charges, so real usage crosses the threshold sooner. That makes a £25 combined product credible if its work graph really replaces the paid tracker or the user runs many coding sessions. It does not support £25 for someone who would otherwise use a free tracker and rarely run an agent. That is category evidence, not money I can add to every savings claim. Linear's free plan includes 250 issues and Jira is free for up to ten users. Linear also has an agent platform, MCP access, and cloud coding sessions using Codex and Claude Code. It is becoming a direct competitor. The combined product earns £15 to £25 only if the work graph replaces another tracker or coordinates agents well enough that users choose it despite the free options. The difference I can test is one persistent, multi-repository BYOK environment where external agents claim work, leave evidence, and hand tasks over without tying execution to one tracker or model provider. Codespaces is more capable than a browser version of VS Code. It provides a full Linux development container, supports arbitrary installed CLI harnesses, permits [SSH through `gh codespace ssh`](https://docs.github.com/en/codespaces/developing-in-a-codespace/using-github-codespaces-with-github-cli), and has a [lifecycle API](https://docs.github.com/en/rest/codespaces). It can also request access to [additional repositories](https://docs.github.com/en/codespaces/managing-your-codespaces/managing-repository-access-for-your-codespaces). Its default inactivity timeout is 30 minutes and the user-configurable maximum is [four hours](https://docs.github.com/en/codespaces/setting-your-user-preferences/setting-your-timeout-period-for-github-codespaces). That repository-first lifecycle conflicts with a continuously available personal agent home. # Identity and secrets Doppler remains the only secrets system for the pilot. It controls which person can access each project or config and can grant temporary access during onboarding or support. Agent identity solves a later, different problem. A Doppler user grant controls the human's access. It does not let one runtime agent use a narrowly scoped resource without giving every process in the workspace the underlying secret. The [Better Auth Agent Auth model used by Recipe Site](/projects/recipe-site/adrs/061-agent-auth) is useful for that future resource gateway. T3 Code currently authenticates clients to a whole environment. Its thread and subagent identifiers are not resource principals. The pilot does not need a T3 fork. A later per-agent authorization experiment will need T3 to carry a durable thread principal and short-lived runtime grant into MCP and other resource calls. I would first propose that as an upstream extension and keep policy enforcement outside T3 Code. # Remaining tests * Can my brother reach useful work after one guided setup? * Does Coder save more custom platform work than it adds? * Will people pay £15 rather than operate the open source deployment themselves? * How many concurrent agents fit on the current CX33 before memory or build contention becomes annoying? * Which files and processes must remain available continuously, and which can survive a stopped workspace? * Can one user be backed up, restored, and removed without affecting the other? * Can an external resource gateway revoke one agent without exposing its upstream credential? The immediate milestone is two people completing real work through separate T3 Code instances on the existing server. The next machine should be purchased only after measured contention makes it necessary. ## Initiatives - [Semi-autonomous Software Development](https://robbiepalmer.me/initiatives/semi-autonomous-software-development.md): A connected system that keeps useful work moving, asks for human judgment when it matters, and learns how to need less intervention next time ## Architecture Decision Records - [ADR 000: Portable Per-user Agent Workspaces](https://robbiepalmer.me/projects/agent-friendly-remote-development/adrs/000-portable-per-user-workspaces.md) — Proposed, 2026-09-06 - [ADR 001: Early-cohort Pricing](https://robbiepalmer.me/projects/agent-friendly-remote-development/adrs/001-small-cohort-pricing.md) — Proposed, 2026-09-06 - [ADR 002: Delegated Resource Access](https://robbiepalmer.me/projects/agent-friendly-remote-development/adrs/002-delegated-resource-access.md) — Proposed, 2026-09-06 --- Markdown index of this site: https://robbiepalmer.me/llms.txt