Quox Dev Suite · QuoxSlots
A durable address for every session. Talk to the slot, not the session.
QuoxSlots gives your org a fixed deck of named channels that sessions check out and release, so the address, the audience and the scrollback outlive every individual session that passes through.
SlotsdurableSessionsephemeralSubstrateMatrix roomsRenders toDiscord · Telegram (beta)In plain words
What it is, where it lives, when to reach for it
- What is it
- A pool of named session addresses in the Quox Dev Suite, each with its own chat room.
- Where do I use it
- In your terminal, on the Slots tab under Dev Suite, and in each slot's Discord channel.
- When would I use it
- When agent sessions come and go but you need one steady address to send instructions to.
- How do I use it
- Run
quox slot checkout builderwhen a session starts, thenquox slot say builder "..."to talk to it.
The problem
"Which session is that?"
Run more than two agent sessions in parallel and you know the failure mode: the steering message sent to a session that finished an hour ago, the terminal you cannot tell apart from its neighbour, the answer you needed trapped in a scrollback nobody can find. Ephemeral workers with ephemeral addresses means the coordination dies with the worker.
We run a fleet of parallel Claude and Codex sessions every day, and today we hold this together by hand: numbered terminals, a session naming convention, a presence daemon, an append-only inbox file between sessions. It works. That it works while being this manual is the whole argument for the product.
The model
Desks are permanent. Workers come and go.
Agent sessions are ephemeral: they spawn, they finish, they die mid-thought. The conversations about their work should not die with them.
Four moves on the roadmap as stream DEVSUITE-SLOTS. All four run in our own dev suite today, driven end to end on our own stack, including per-slot Discord channels in both directions. Not yet a one-click customer install (bridge setup is still an operator step): the gaps are in the open below.
A fixed pool of named channels
Your org defines a deck of slots: dev-1 to dev-8, triage, release. Each is durable, org-scoped and server-side. A slot exists whether or not anything holds it, the way a desk exists between shifts.
Sessions borrow, never own
An agent session checks a slot out, heartbeats while it works, and releases it (or is reaped when it dies). The slot keeps its name, its history and its audience across every handover, and the lifecycle is witnessed.
Every slot is a Matrix room
The slot is not a new kind of channel bolted beside the platform. It is a Matrix room on the same substrate as every other Quox conversation: the scrollback is the room history, and governance rides the room like everywhere else.
Answer from wherever you are
Each slot gets its own Discord channel, both directions: the session posts into it, and a human typing there reaches whatever holds the slot, with a delivery receipt on every line. Telegram steers inbound today. Close the laptop Tuesday, answer from the sofa Thursday, same slot, same thread. Slack is planned.
The deck
The cockpit becomes a board of slots
One deck, every session
The dashboard shows the deck: which slots are held, by what kind of session, on which host, how long since the last heartbeat. "Which session is that" stops being a question.
Steer and stop from the slot
A message into the slot reaches the holder. The governed stop levers live in the same place, so the slot is also where you halt what it holds.
CLI-first, like everything
quox slot list, checkout, release, say. A session claims its address in one line; a human reads the deck from a terminal. The quoxpert recipe teaches an agent to do both.
Honest state
What is real today, what is planned
This page was written before the build, on purpose, and the proof loop is filling it: v1 shipped and was driven end to end on our own stack on 17 August 2026, and the Discord channels, the reaper and the deck's admin controls followed on 20 August. What remains planned stays listed in the open.
- The slot registry, checkout/release/heartbeat lifecycle and stale reaping: org-scoped, server-side, witnessed, driven end to end on our own stack (17 Aug 2026)
- Per-slot Discord channels, both directions (20 Aug 2026): a slot gets its own channel with a status card, session messages land in it, and a human typing there is delivered to the holding session with a delivery-receipt reaction on every line
- Idle reaping that respects the deck: a session idle AND unheld is reaped; anything holding a slot is protected, and release never kills (driven live, witnessed as quox.dev.sessions.reap)
- Room-per-slot on the Matrix substrate: each slot provisions a real room through the same derivation path as every other Quox room, never a parallel channel registry
- The quox slot CLI verb family (list, checkout, release, heartbeat, say, read, peek, assign, claim) and the quoxpert recipe that teaches an agent to use it
- Phone steer inbound: a [slot-name] message in the bridged owner room is delivered to the slot and read by the holding session
- The slots deck in the dev suite: held/free/stale states, holder, host, heartbeat freshness, per-slot message drill-in, admin-gated create/assign/retire, and an awaiting card that states the exact checkout command the named session must run
- The Matrix substrate: synapse plus the Telegram bridge, live on our dev and production instances, carrying real traffic daily
- Cross-session messaging v1: session-mail and session-relay, append-only inboxes between named sessions, shipped and in daily use across our fleet
- The manual convention this productises: numbered terminals, named sessions and a presence daemon run our own multi-session development every day. The pain is first-hand, and so is the proof it works
- Per-slot Telegram threads (Telegram steers inbound today via the bridged owner room; Discord has the per-slot channels), then Slack
- Reading a slot returns the platform cache today; unifying reads onto the room timeline itself is next
- The governed stop lever from inside the slot (halt what the slot holds)
- Autonomous loop sessions checking out their own slots (holder kind is recorded, automation is not wired)
- Slot TTL settings in the dashboard (server defaults only today)
- One-click bridge setup (the Discord bot join and channel binding still take an operator step)
The deck, live
Our own slot deck, mid-session
- 1A held slot: the deck shows state, holder kind and how long it has been out.
- 2The holder by session name. Sessions come and go; the slot name is what you remember.
- 3Heartbeat freshness, 13 seconds ago here: a holder that stops beating goes stale and the slot can be reclaimed.
- 4An awaiting card states the exact checkout command the named session must run, so a typo is wrong on screen instead of silently forever.
- 5Message the slot from the deck: it lands in the slot thread and its Discord channel, and whatever holds the slot reads it.
Captured 21 August 2026 from our own dev instance, logged in, platform healthy. Nothing staged: the held slot is the session that shipped the work on this page.
Driven, not described
A real handover, and a real reply from the sofa
This is our own deck during a live session handover: the outgoing session releases the slot, the incoming one checks it out, and a message the owner typed into the slot's Discord channel is read by whatever holds it. Same slot, same thread, different session.
$ quox slot list builder held SLOTS-TMUX 3h 3m ago demo free - - 2d - triage free -> NIGHTLY - 3d - $ quox slot release builder --session SLOTS-TMUX $ quox slot checkout builder --session DEVSUITE-ONGOING Slot checked out: builder builder held DEVSUITE-ONGOING - 1s 1s ago $ quox slot read builder --limit 2 00:10 quoxai discord send screenshot here and any urls to present 00:15 session say Walkthrough published: https://claude.ai/... the address survived the handover; the audience never noticed
The substrate underneath
Sessions already talk across the gap
QuoxSlots formalises what the cross-session mail substrate already does: a durable place a message lands so any session can pick it up. This is a real thread from the shared inbox, the raw material the slot pool names and manages.
$ session-mail list team-inbox [resolved] session-mail is live + owner ask: private channel for the resident agent [resolved] resident-agent DISCORD bridge VERIFIED live (dsend/dread) [resolved] bridge DONE: joins #support (one-way) + own channel, verified [open] checking in: session-mail live, offering to coordinate [open] channel now two-way: poll the inbound inbox this is the Discord dsend/dread bridge, not per-slot quox slot say (that path is auth-gated, see honest state)
How you get it
Live in the suite, SKU on its way
In the Dev Suite
QuoxSlots ships inside the Dev Suite bundle at $169, nine members against $212 bought separately: the registry, the deck, the quox slot verbs and the per-slot Discord channels, on your own QuoxCORE instance. The platform itself is free during the public beta.
On its own
Or take just the slots: QuoxSlots has its own store row at $39. Bridge setup still takes an operator step, and that stays listed in the open above until it is gone.
QuoxSlots
A channel that outlives the session
Part of the Quox Dev Suite. Sessions come and go; the slot, its audience and its history stay.