QuoxSlots

Durable named addresses that survive the ephemeral agent session behind them.

Overview

Agent sessions are ephemeral. They start, they work, they die, sometimes unexpectedly. If the way you address a session is the session itself, then every handover costs you the thread, and every crash costs you an address.

QuoxSlots inverts that. You get a fixed, org-scoped pool of named slots. Sessions check a slot out, hold it while they work, and release it when done. You talk to the slot. Whatever session is currently holding it receives what you said.

The analogy that fits: a slot is a desk, not an employee. The desk exists between shifts. You leave a note on the desk without needing to know who is sitting at it today.

The lifecycle

bash

quox slot create backend-1          # the desk now exists
quox slot checkout backend-1        # a session takes it
quox slot heartbeat backend-1       # ...and keeps proving it is alive
quox slot release backend-1         # the desk is free again

A held slot must heartbeat. When the heartbeat lapses, the slot goes stale and frees itself. This matters more than it sounds: without it, a crashed session wedges its address forever, and the pool degrades one dead slot at a time until someone notices.

assign and claim cover the handover case, where you know which session should end up holding a slot before that session exists:

bash

quox slot assign backend-1 my-session-name   # reserved, still free
quox slot claim                              # the session takes everything assigned to it

Talking to a slot

bash

quox slot say backend-1 "the migration is applied, carry on"
quox slot read backend-1
quox slot peek backend-1        # the last 10, shorthand for read --limit 10

Each slot has its own chat thread backed by a Matrix room. say writes into that room, and the holder reads it there. Because it is a real room and not a private channel, the conversation survives the session that was in it.

Bridging to a chat app

A slot's room can render into a chat app you already have open:

bash

quox slot bridge set <slot> telegram <target>
quox slot bridge set <slot> discord <target>
quox slot bridge list <slot>

Bridge configuration never returns the credential. Listing a bridge shows the target's identity (for a webhook, its ID) and never its token. This was a real leak, found and fixed on 2026-08-19: the endpoint previously returned the full webhook URL, token included. It now redacts, and fails closed on any https target it does not recognise rather than assuming an unrecognised URL is safe to print.

Limits and honest status

8 slots per org on the paid tier, 500 messages of history per slot. The free tier has zero slots: this is a paid capability with no free mode.
Stale detection is heartbeat-based, so a slot frees itself some interval after its holder dies, not instantly.
Bridge delivery is per-target and reported per-target. A bridge to two destinations where one fails reports exactly which one failed, rather than a single aggregate success.
A slot is an address, not a mailbox. It does not queue for an absent holder. If nothing holds the slot, what you say lands in the room and waits to be read, rather than being delivered.

For the current per-surface maturity map, see STATUS_AND_LIMITS_DEVSUITE.md in the dashboard repo.