Local-First

NEXUS's work — terminal sessions, canvas edits, mesh messages — happens entirely on the machine it runs on. The cloud is consulted for exactly two questions: who is this, and what is this account entitled to. Everything else is a local round-trip or no round-trip at all.

What this buys

No network dependency for the parts that matter most. A canvas write, a mesh message, and a tool call all resolve locally; none of them can be slowed down or interrupted by a network path to a server you don't control. The local MCP server reflects this directly: it opens no network port at all (see MCP Protocol) — its entire surface is stdio, tied to the lifetime of the session that spawned it.

A smaller trust boundary for credentials. Because capability tokens are consumed locally rather than presented to a remote service on every call, they can live in a file with owner-only permissions rather than needing to be minted, refreshed, and revoked against a remote session store. See Paths & Credentials for exactly where and how.

What it costs

Entitlement changes are not instant. The one place this architecture does depend on the cloud — checking what an account is entitled to — is cached, and a newly granted entitlement can take up to 300 seconds to take effect. That delay is the direct price of not making every capability check a live network call; see Entitlements.

Nothing here claims to be a sync layer. NEXUS uses the cloud for identity and entitlement, not for replicating canvas or mesh state anywhere else. Treat that scope as intentional rather than as a gap to route around.

The consequence for how you integrate

If you are building against NEXUS, most of what you need to reason about — protocol errors, write outcomes, message delivery — is fully determined by the local exchange in front of you. The entitlements endpoint is the one place a "why did this fail" investigation should expect cloud-side latency rather than a local bug. See Entitlements and Architecture.