1.0.0 is the line where Keating stops treating browser execution, local CLI execution, and cloud execution as separate worlds. The browser agent now starts by asking what runtime it is in, and remote-only work has an explicit path instead of an implicit server fallback.
Three Serving Modes
keating web now has an explicit agent mode. Browser-only is the free local default. Remote mode points at a self-hosted sandbox service. Cloud mode points at the canonical Keating backend.
keating web --browser-only-agent 3000 keating web --remote 3000 \ --remote-provider=microsandbox \ --remote-endpoint=http://127.0.0.1:8787 \ --remote-region=local \ --remote-snapshot=keating-base keating web --cloud 3000 keating web --cloud 3000 --cloud-endpoint=https://keating.help
The web server exposes /api/agent-runtime/config so the app can discover its mode, and /api/agent-runtime/remote/** as the controlled proxy path for remote/cloud execution. In browser-only mode that proxy returns a fallback error by design.
Runtime-Aware Tools
The web agent now gets agent_runtime and remote_execute. The first reports the current mode, capabilities, and fallback policy. The second posts remote-only operations to the configured server when available, or explains why the task cannot run in browser-only mode.
Shared Browser Agent Runtime
A new packages/browser-agent-runtime package provides the shared execution vocabulary: memory sandboxes, capability routing, transactional snapshots, rollback helpers, Daytona-shaped filesystem/process compatibility, a NodePod adapter seam, and an RPC relay protocol. The point is to make NodePod, Daytona, microsandbox, and future providers adapters behind one boundary.
What Stays Local
The free browser surface is intentionally browser-only. It is lower-risk than running arbitrary learner code on a shared Keating server, but it cannot provide native binaries, Docker or microVM isolation, durable background compute, unrestricted host filesystem access, public inbound networking, or server-brokered secrets. Those belong behind --remote or --cloud.
PDS and Educator Roadmap
The docs now separate private learning state, portable public educational artifacts, and operational sandbox state. AT Protocol and PDS integration is a good fit for public lesson packs, rubrics, maps, quizzes, educator profiles, and learner-approved portfolio artifacts. It should not become the default store for raw private tutoring transcripts, API keys, private goals, or classroom roster analytics.
Educator tooling is also being scoped as an explicit product layer: lesson packs, misconception banks, rubrics, class goals, review sets, portfolio artifacts, and privacy-preserving class analytics. The storage roadmap lives in docs/plans/storage-atproto-educator-tools.md.