---
title: "Guardian Lab Relay"
slug: guardian-lab-relay
section: reference
access: public
summary: "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,…"
status: published
asset_base: /assets
home_href: /
toc_enabled: true
talk_enabled: false
agent_view_enabled: true
copy_buttons_enabled: true
footer_enabled: true
last_updated: 2026-04-29
categories: [Engineering, Infrastructure]
subject-type: tool
last-reinforced: 2026-04-29
fading-since: null
archived: false
---

## Guardian Lab Relay

Guardian Lab Relay is the server-owned execution layer behind [Guardian](/guardian) / [Haptica](/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](/guardian) 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](https://tailscale.com/). 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](/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 `turnId`s 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](/guardian) 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), [guardian-app](/guardian), and [Haptica](/haptica), because those are the clients and product identities that exercise it. It also connects to [1Context](/1context) as an early example of server-owned agent execution with provenance, and to [Fish](/fish) because Fish tried to inherit Guardian chat behavior through a reconstructed desktop shell. Its operational story depends on [Tailscale](https://tailscale.com/) 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.