A Local Agent Panel Should Not Need a Cloud Project Mirror

A browser panel can make an agent system feel like a hosted product. That does not mean the project must be copied to a hosted product. APX takes a different boundary: the panel is a local interface to a local daemon, while APC keeps durable project context in the repository.

That distinction is practical. A project needs rules, agent definitions, reusable skills, and curated memory that can travel with its Git history. A running system needs sessions, conversation threads, logs, a scheduler, and active connections that should stay on the machine operating them. Treating both as one cloud-shaped data store weakens both jobs.

APC is the portable context layer. Its project contract lives in AGENTS.md and .apc/: files a teammate can review, version, and clone. APX is the daily-use runtime layer. It reads that context, runs agents, and keeps runtime state under ~/.apx/ instead of turning the repository into a session database.

The panel is a surface, not another source of truth

APX's web admin is served by the local daemon. By default, that daemon listens on 127.0.0.1:7430; the CLI, web panel, desktop window, TUI, and MCP bridge communicate with the same local process over HTTP. One runtime can therefore expose several interfaces without making each interface own a separate copy of projects, agents, or conversations.

Start with a normal status check:

apx status

If needed, APX starts its daemon. Opening http://127.0.0.1:7430 then shows the panel backed by that same daemon. The browser is useful because it is a good surface for browsing projects, sessions, messages, MCPs, and routines—not because it becomes a new project backend.

This design avoids a common drift problem. Imagine editing an agent role in a dashboard while the repository still has an older agent definition. Now a reviewer must ask which source an agent will actually follow. APC avoids that ambiguity by keeping durable project meaning in ordinary files. APX can index and use those files, but its live state remains runtime-owned.

Local by default, explicit when shared

A local panel is not automatically a network service. APX binds the daemon to loopback by default. To open the panel from another device on a LAN, the operator must opt in and pair that client. That is a meaningful boundary: browser access can expand deliberately without silently exposing the daemon on every network.

The same separation helps with recovery. Removing a project from APX's registered-project list does not delete project files. Cloning the repository elsewhere still brings the APC contract; it does not bring someone else's local conversations, tokens, or daemon process.

There is no claim that local runtime state eliminates every external dependency. An agent may call a configured model provider or an MCP server. The point is narrower: APX does not require a public server merely to give a local project a usable agent dashboard.

Use the boundary as a design test. If a fact should survive a clone and code review, put it in APC. If it only exists because an agent is running right now, let APX keep it local. The panel can be rich without becoming a cloud mirror of your project.