> ## Documentation Index > Fetch the complete documentation index at: https://tesser.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Vision > The principles that keep tesser small Tesser gives local coding agents remote development compute — and the wiring between it — through a small CLI. The coding agent stays on the developer's laptop. It reads and edits the local working tree with its normal tools. When it needs compute, a persistent dev server, an isolated environment, or a running copy of the rest of the architecture, it invokes `tesser` the way it would invoke `git` or `pnpm`. The remote machine is a **box**: a deliberately low-level primitive — persistent compute, a synchronized workspace, one running service. Tesser does not model tasks, agent sessions, or what a repository "is". On top of boxes it adds exactly one new idea: a **mesh**. Services find each other by name, resolved per box, so a frontend on one box, a backend on another, and a shared `main` worker form a working system with zero application configuration. > Remote development compute, and the wiring between it, for local coding > agents. ## Principles ### Local is the source of truth The agent edits local files; sync mirrors them out. Remote edits are never merged back. Boxes hold **no important state** — every box is reproducible from its content source and manifest recipes, which is what makes aggressive sleeping and reaping safe rather than brave. ### The CLI is the product surface Agents know a small set of stable verbs and opaque IDs — never AWS, instance types, security groups, or tunnels. Creating commands print their ID as the only stdout; progress goes to stderr; remote exit codes pass through verbatim. Every workflow an agent needs is a pipeable one-liner. ### Callers own every start There is no reconciler. Nothing in the cloud starts, restarts, or resurrects a named thing on its own — every instance start traces to an agent, a human, or CI. The control plane may start only anonymous warm-pool blanks, and it may turn things **off**. A bug in auto-stop costs a re-warm; a bug in auto-start costs money forever. ### Cells decide, never carry The control plane is small single-writer actors holding decisions: registries, defaults, overrides, routing tables, presence, policy. Data — sync, exec, logs, mesh traffic — moves over SSH and VPC private IPs and never touches the control plane. If the control plane dies, running boxes keep routing on their last tables and SSH keeps working. ### Names are globally meaningful, locally resolved A service name means one thing across the org; which *instance* it reaches is decided by each box's own table. Your boxes prefer your instances; the shared mesh resolves only to shared instances. There is no global route anywhere — per-user routing conflicts aren't forbidden, they're unrepresentable. ### Config declares facts; callers make judgments A manifest holds what is true about a service: where it lives, what it listens on, how to set up, run, and health-check it, what it needs. When to restart, when to test, what else to install — judgments — belong to the agent, expressed through verbs and flags. There are no behavior knobs in config. ### Apps need zero changes Dependencies materialize as loopback ports — the `localhost:5001` already in the repo's `.env` simply *is* the dep, on a box and on the laptop alike. No SDK, no injected env convention, no DNS, nothing installed on the host OS. The browser gets `.localhost:` for free. ## Non-goals Per-request routing (identity headers, interception) · overlay networks · reconcilers of any kind · forge credentials on boxes · running the agent inside the box · modeling tasks, previews, or checkpoints · billing and plans — though lifecycle events are recorded so billing needs no redesign later.