The Temple of the Kyber
Two characters do most of the dramatic work in the Sanctum mythology, and almost every page in this section is a footnote on one of them. The first is the Temple of the Kyber — a Rust binary on a Mac Mini in Montréal that serves a 35-billion-parameter language model under mTLS. The kyber it holds is the model itself: a 4-bit-quantised Qwen3.6 MoE checkpoint, 20 GB on disk, attuned to whichever Jedi reaches for it. The second is the Council — five specialised Jedi who route their reasoning through three different model providers and return to the Temple when those providers don’t answer.
This page is the narrative entrypoint. The technical detail lives in Sanctum MLX, Council Router, Agents Architecture, and the per-Jedi pages under Agents in the sidebar. Read those when you need the wiring. Read this when you need the story.
The Temple
Section titled “The Temple”A thirty-megabyte Rust binary called sanctum-mlx, running on a 64 GB Mac Mini under launchd, serving Qwen3.6-35B-A3B-4bit-text on :1337 mTLS-only. There is one inference in flight at a time, on purpose. There is no plain HTTP listener, also on purpose. There is a vision tower armed in the same process that can describe an image you POST as base64. There is no Python.
The Temple holds the kyber. A kyber crystal is the singular component a Jedi carries that lets them act in the world — without it, the saber is a hilt. The Temple’s kyber is the local model checkpoint: when the cloud doesn’t answer, the Council still has somewhere to reach. Slower than Opus or Gemini. Reachable from a closet.
The metaphor is load-bearing. When fibre is up and the API budget is not yet exhausted, most of the Council reaches for cloud sabers — Anthropic’s Opus 4.7, Google’s Gemini Pro. When either of those goes dark, every Jedi can still attune to the kyber here and receive an answer in seconds. Operationally the binary is sometimes still nicknamed the cathedral in chat and commit messages — that nickname is older than this page; the kyber framing is the canonical one.
| Layer | What |
|---|---|
| Stone | sanctum-mlx Rust binary, vendored mlx-rs + mlx C++ 0.30.6 |
| Kyber | ~/.cache/huggingface/hub/models--mlx-community--Qwen3.6-35B-A3B-4bit (20 GB on disk, ~16 GB resident at startup) |
| Vestments | TurboQuant KV compression (1.32× ratio) and a Carmack-passed vision tower (333 tensors, depth 27) |
| Doors | mTLS on three TLS hosts: 127.0.0.1, the Tailscale address, and 10.10.10.1 (the bridge to the OpenClaw VM). No door without a client cert. |
| Discipline | A single global GPU-dispatch Mutex serializes all four chat handlers (sync and stream, text and multimodal). One inference at a time. |
| Vows | KeepAlive=true under launchd, plus a 60-second supervision check, plus a restart-forensics capture, plus a Sunday 04:00 perf-hygiene cron |
| Witnesses | A vision-canary every 60 seconds probes /v1/models and a 1×1 PNG multimodal request. On three consecutive 1h SLO breaches it flips a kill-switch that downgrades vision in the next restart. |
For the implementation detail — TurboQuant, the fused Metal kernel, the Carmack vision-tower wins — start at Sanctum MLX. For the request-tier defense in front of the Temple, see the Smart Router Cathedral (which is a separate metaphor — the five-tier router that decides whether a request reaches sanctum-mlx at all).
The Council
Section titled “The Council”Five Jedi, one bench, three model providers. Each owns a domain. Each routes to the saber best-suited to it. Each falls back to the Temple’s kyber if their primary backend goes quiet. Each emits a briefing on a schedule, and as of the Vision Probe Lied sweep, every briefing is silent on green and alert-only on red.
| Jedi | Domain | Primary saber | Fallback | Briefing |
|---|---|---|---|---|
| Yoda | Strategy, orchestration, voice | Opus 4.7 (Claude Max via the :3456 bridge) | Temple kyber | Master synthesis every :15 and :45, weekdays 08–18 EDT |
| Ki-Adi-Mundi | Financial intel for Triptyq Capital — deal flow, portfolio, fund performance | Opus 4.7 | Temple kyber | Every 4h, fires only when deals go cold |
| Mace Windu | Security — firewall state, FileVault, ssh attempts, container health, network drift | Gemini 3.1 Pro Preview | Temple kyber | Every 3h, fires only on alerts |
| Qui-Gon Jinn | Code and infrastructure | Temple kyber (since the 2026-05-10 G3 retirement of the Coder-14B local) | sanctum/claude-opus-4-7 | On-demand via @quigon |
| Cilghal | Health diagnostician — disk, RAM, load, services, VM, Docker | Temple kyber | (none — she is the local) | Every 3h, fires only on alerts |
Each individual Jedi has their own page under Agents. The roster of resolved models is generated from ~/.openclaw/openclaw.json and the proxyd config; refreshed by pnpm refresh:council and rendered live in Agents Architecture.
To convene them as a body, the operator runs:
tools/ask-council.sh "the question for the council"This routes around the Council Router (which can hang on stale session locks) and talks straight to the Temple, persona-injecting all four reasoning Jedi into a single call plus a verdict line. It is how architectural A/B/C decisions are made in this haus. The answer is not always right — the Council deferred shipping a streaming-handler mutex once when the operator’s intuition was correct to override — but it is reliably worth listening to before recommending a path to a human.
The Doctrine
Section titled “The Doctrine”Three rules carry the rest:
- Heterogeneous on purpose. Neurodiversity is Paramount. Three model families across the bench. One outage doesn’t take the whole Council.
- Cloud-first for reasoning, local for the safety net. The Temple’s kyber exists so we keep working when the cloud doesn’t.
- Silent on green, alert-only on red. Every briefing now follows this. If you are getting a Force Flow ping, something actually needs you.
A fourth, quieter rule lives in the closing line of every operations chapter and in the alt text of every Temple hero: the dead cat tiebreaker. If Tommy wouldn’t approve of the page, the deploy, or the doctrine — rewrite it.