openclaw - 💡(How to fix) Fix Community plugin: Thalamus, packet-handoff layer for multi-agent crews (review request) [1 comments, 2 participants]

Summary

I built a community plugin called Thalamus that adds a cognitive routing layer to OpenClaw multi-agent crews. The idea: instead of pasting whole transcripts when one agent spawns another, the spawning agent emits a 3-field reference (packet_id, resolver_key, inline_vector), and the receiver resolves only the relevant atoms from a local vector store.

It is now live on ClawHub and npm. It also runs in production on my own Pi 5 setup. I am opening this issue because I would like maintainers and community members to look at it and tell me what is wrong, what is overstated, and whether anything close to this is interesting enough to bundle by default.

I am not asking for a merge. I am asking for review.

Links

• ClawHub plugin: clawhub:openclaw-thalamus (clawhub package inspect openclaw-thalamus)
• npm (MCP server form): https://www.npmjs.com/package/openclaw-thalamus
• GitHub: https://github.com/msbel5/openclaw-thalamus
• License: MIT
• Companion plugins (also community): openclaw-aegis-signer (Ed25519 audit chain), openclaw-sga-mcts-atoms (plan-time atom retrieval)

Install:

openclaw plugins install clawhub:openclaw-thalamus

What it does

1. Packet store with content-hash resolver keys.
2. Vector store with 9 namespaces (atoms.code, atoms.audit, atoms.plan, atoms.memory, atoms.audio.raw/text, atoms.image.raw/text, atoms.crossmodal).
3. Encoder daemon: Qwen3-Embedding-0.6B Q4_0 GGUF (1024 dims) on CPU via llama.cpp.
4. FAISS RaBitQ (BBQ) codebook trained on 100K vectors for compression.
5. MCP server tools: thalamus_route, thalamus_resolve, thalamus_search, thalamus_search_with_vector, thalamus_promote_packet, thalamus_telemetry.
6. Optional Hailo HEFs for Whisper-encoder, CLIP-text, CLIP-image. The Hailo path is wired but is NOT used for Qwen3 (LLM/embedding GGUFs cannot run on Hailo10H, only audio/image encoders).

What is honestly measured

I want to be clear about which numbers are direct measurements and which are extrapolations.

Directly measured on the live Pi 5:

• Qwen3 Q4_0 cold load: 1.7 to 1.8 seconds. Encoder log shows multiple loads at this latency.
• Qwen3 warm embed: about 167 ms p50.
• BBQ codebook on 99,823 vectors (10 percent holdout): mean cosine 0.978, p10 0.985, p50 0.999. Trained on a desktop with an RTX 3070 in 17.6 minutes (the Pi rebooted three times during my first attempts under load).
• Protocol-level @-code compression: 19.1 percent token reduction on captain spawn context (telemetry rows in ~/.openclaw/thalamus/state/run_telemetry.jsonl, spawn_context_tokens 68 to compact_context_tokens 55).

Estimated, not directly benchmarked:

• "95.84 percent combined token reduction" comes from adding the @-code compression to a packet-handoff savings layer, where the second layer compares against a hypothetical naive transcript paste baseline that I did not directly run side by side. Take this number as a single-machine direction signal, not a comparative benchmark.

The raw paste-ins that back these numbers are in BENCHMARKS.md on the GitHub repo.

Asking for help

1. Is anyone interested in running this on their own OpenClaw setup and reporting back? Single-developer numbers are not enough to claim anything portable.
2. If you find that the directly measured 19.1 percent is the only honest claim, I am happy to rewrite README to reflect that and drop the 95.84 percent figure.
3. The plugin currently shells out to a Python signer for aegis-signer and a Python retriever for sga-mcts-atoms. The dangerous-code scanner correctly flags child_process use. I plan to refactor to native Node crypto.sign('ed25519') and better-sqlite3 so the scanner stops needing the --dangerously-force-unsafe-install flag. That refactor is on my list (PRD-R) but not done yet.
4. If maintainers think any of this is worth bundling by default, I would love guidance on what shape that would take. If maintainers think it is not, I would also like to know that early so I can stop pushing it that way.

Disclosure

• Solo developer. Mechanical engineer by training, test automation by day. I built this on top of OpenClaw, on a Raspberry Pi 5 in my apartment in Istanbul.
• I used an AI assistant for English grammar passes. The technical claims are mine and they are checked against the live state of my Pi.
• I am opening this issue knowing that some of the early framing of this work was overstated. The recent README rewrite (v1.0.1) and the breakdown above are my attempt to be cleaner about what is real.

Thanks for reading. Tear it apart.