Guardian Lab Relay
Guardian Lab Relay is the server-owned execution layer behind Guardian / Haptica chat. It exists so the phone app can send prompts, detach, resume, and reconcile answers without pretending a mobile socket is the unit of truth. As of April 21, 2026, it is still lab infrastructure, centered on the B650 relay host, but it has grown into a durable turn service with lanes, telemetry, uploads, provenance, and a known unresolved credential problem.
Origin
Guardian Lab Relay appeared on April 7, 2026, when guardian-app needed a real phone demo with live memory behind it. It began as an empty directory and became a TypeScript Express server on haptica-b650-pro-rs.tail5714b3.ts.net:3000, reachable from a Pixel over Tailscale. The relay could run in /home/haptica/GitHub/Guardian_testing, call the Guardian MCP memory path, and stream an answer back to the Android app.
The initial pressure was practical. React Native transport behaved differently between dev and release builds, Android cleartext rules blocked ordinary HTTP, and the app needed something stronger than a local mock. The relay gave the phone one stable target while the server kept custody of the memory-aware Claude run.
Role in 1Context
Within 1Context, Guardian Lab Relay is not the central memory store. It is a proving ground for service-owned agent execution, mobile reconciliation, and authority boundaries. It consumes Guardian project memory through the lab repo and MCP configuration, then produces conversation turns, stream events, SQLite continuity, request logs, and app-facing error states.
Its most important design rule arrived on April 10: execution is server-owned; streaming is observation. A client may watch a stream, lose the stream, or resume later, but the answer belongs to the relay until the turn completes. That rule connects the relay to broader 1Context concerns: durable evidence, scoped callers, machine credentials, and the difference between a human-facing app state and a canonical server record.
History
April 7 established the first working relay/app contract. The relay gained health, conversation, message, streaming, and resume paths, then SQLite continuity, rename support, auto-titles, structured SSE events, and restart persistence. Commit e85f1ed474601bbd02cd200fa90af5b78d0799b3 marked the Android proof that native relay chat could complete through XHR rather than broken fetch().body streaming.
April 9 turned the relay from a running process into an operated service. After the B650 disappeared from Tailscale following a power reset, the relay was installed as a user systemd service at /home/haptica/.config/systemd/user/guardian-lab-relay.service. The same day fixed a subtle SSE lifecycle bug: req.on('close') was canceling streams when the POST body finished, rather than when the event stream truly disconnected.
April 10 changed the architecture. Durable turns landed through /api/conversations/:id/turns, turn replay, queued same-conversation sends, telemetry, lane scripts, and architecture docs. The phone app then learned to bind pending assistant rows to accepted turnIds and resume from canonical relay state.
April 11 added provenance: release metadata, prompt versions, durable conversation_messages, and /readyz fields that reported what the relay believed it was running. April 15 and April 17 explored model configuration, including Claude fast mode, speed metadata, and experimental Opus 4.7 high-effort lanes.
April 18 exposed the relay’s biggest authority problem. Stable lanes first failed because claude-opus-4-6[1m] required extra usage, then later because the account hit a usage cap. Commit 94811ba made those failures app-visible as upstream_usage_limit rather than generic internal errors. Inspection then found the service was using Claude.ai OAuth credentials tied to a human subscription, not an Anthropic Console API key.
By April 21, the relay had also grown experimental uploads v2: signed upload URLs, orphan sweeps, thumbnails, conversation-member scoping, ffmpeg keyframe extraction, and parallel video handling. That work connected guardian-app attachments to the relay contract, while also exposing an ordering race where a message could be sent before upload finalization.
Current State
As of April 21, Guardian Lab Relay remains the lab execution service for Guardian/Haptica chat. It has durable turns, lane configuration, service management, SQLite continuity, stream error classification, prompt and release provenance, upload primitives, and a growing harness suite. It is operationally useful, but its model access story is not settled.
The current constraint is credential authority. For a service, model access cannot depend on a person’s Claude.ai quota reset. The relay now reports that failure more honestly, but the service still needs proper API-key or equivalent service credentials, clearer model policy, and usage controls that match phone-user expectations.
Relationship to Other Subjects
Guardian Lab Relay is closest to Guardian, guardian-app, and Haptica, because those are the clients and product identities that exercise it. It also connects to 1Context as an early example of server-owned agent execution with provenance, and to Fish because Fish tried to inherit Guardian chat behavior through a reconstructed desktop shell. Its operational story depends on Tailscale and the B650 lab host, while its future authority model belongs with 1Context’s broader auth and machine-token design.
Open Questions
The main open question is service authentication for model execution. The second is whether the relay remains lab-specific or becomes a reusable 1Context execution service. The third is how attachments, tool traces, prompt versions, and turn state should be retained once Guardian conversations become part of a longer-lived memory record.