Wake on Prompts: prompt-triggered session lifecycle for Remote Control

Summary

Remote Control currently operates on a session-based model: a long-lived process must be running before any prompt can be received. The session is the infrastructure, and the user is responsible for keeping it alive.

I'm proposing a prompt-based model — Wake on Prompts (WoP) — where a prompt arriving at a registered machine triggers session creation on demand. The session becomes ephemeral; the machine identity and memory become the persistent layers.

Concrete scenario: a developer sends a prompt from their phone; their registered workstation wakes, processes it with full MCP context, and returns the result — no pre-existing session required.

The Problem

Today's Remote Control is essentially an extension cord — it increases the physical distance between you and your machine, but the fundamental constraint remains: a process must be alive and waiting.

This creates a fragile chain:

• Machine must be on
• Network must be connected
• Claude Code process must be running
• No CLI/MCP updates can interrupt the session

Any single link breaking = full rebuild cost falls on the user. For users running dedicated workstations as always-on AI endpoints — developers with MCP servers wired into their infrastructure, researchers with custom tool pipelines, small teams using a shared server as a team-wide AI surface — this maintenance overhead becomes a real productivity cost.

Why existing features don't solve this

• Channels (Telegram/Discord/iMessage): requires a running session. The prompt is delivered into an existing session, not creating one.
• Dispatch: spawns Desktop sessions on task arrival, but the spawn target is the GUI app — not a CLI session with MCP servers and project context. Each dispatch is isolated, no memory continuity.
• Scheduled tasks: time-based, not prompt-based.

WoP would be the first primitive where the prompt itself is the session creation signal, targeting CLI-based long-lived workflows.

Proposed Model

Inspired by Wake-on-LAN (packet wakes a sleeping machine) and serverless compute (request triggers execution), WoP flips the model:

Prompt (from any device)
  → Anthropic routing layer
  → Machine identity verification (registered runtime)
  → Cold-start or hot-takeover
  → Ephemeral session handles the prompt
  → Output + update persistent memory
  → Session ends (or stays warm for a follow-up window)

Core principle: decouple three layers currently bound together

| Layer | Current model | WoP model |
|--|--|--|
| Machine authorization | Tied to process | Persistent — registered once |
| Session | Long-lived, user-maintained | Ephemeral — spun up per prompt |
| Memory / context | Accumulated in session jsonl | Persistent — lives in memory layer, survives across sessions |

The metaphor

• Current RC: "I leave a door open and wait for you to walk in."
• WoP: "You call my name, and I'm there."

The latter is what "always available" actually means.

Benefits

1. No idle process cost — machine doesn't hold a warm Claude Code process indefinitely
2. Auto-updating — each prompt spawns with the latest CLI and MCP versions; no "restart to pick up updates" friction
3. Failure is cheap — a crashed session doesn't require manual rebuild; next prompt just spawns a new one
4. Context management shifts from user to system — persistent memory handles continuity, not session lifetime

Cold-start reality check

Prompt caching handles the LLM-side warmth. The remaining cold-start cost is MCP subprocess boot — keyring lookups, DB connections, vault mounts. This is mitigatable by keeping MCP servers warm independently of the Claude Code session, so only the thin CLI layer needs to spawn per prompt.

A "follow-up window" (session stays warm for N minutes after last interaction) handles rapid conversational turns without re-paying cold-start cost every message.

Security considerations

• Machine registration should require explicit user consent with a revocable token, similar in scope to today's RC session tokens.
• Prompt authentication must bind to the user's account, not just the machine — otherwise a compromised machine becomes an open Claude proxy.
• Per-prompt permission checks remain enforced inside each spawned session; WoP changes when the session is born, not what it's allowed to do. All existing allow/deny lists, defaultMode, and hooks continue to apply.

Suggested implementation path

1. Register — persistent machine identity endpoint (not a session), revocable by user
2. Route — Anthropic routes incoming prompts to registered machines with auth check
3. Spawn — cold-start with MCP boot, or hot-takeover if a warm session exists; keep alive N minutes post-interaction, then sunset

Memory-first context loading (read from persistent memory layer rather than replaying session jsonl) makes ephemeral sessions stateless at the runtime level while preserving continuity at the user level.

Related concepts

• Wake-on-LAN (hardware wake on network packet)
• Serverless / AWS Lambda (compute spins up on request)
• Cloudflare Workers (edge compute triggered by HTTP request)

---

You don't start a session to talk to your workstation. You just speak, and it's listening. Session-based is an extension cord. Prompt-based is true always-on.