LOCI Advanced

An experiment: agentic LOCI as the execution scaffold, colibrì as the MoE serving substrate, testing whether several agents can collapse into several logical roles over one MoE model instance without losing specialisation.

Desktop/LOCI Advanced/
├── colibri/                        upstream, unmodified  (JustVugg/colibri v1.10.2)
├── ConversationalAgenticMemory/    upstream, unmodified  (Jonas-Schewior/…, "MnemOS")
├── integration/                    everything this experiment adds
│   ├── loci_advanced/              the library
│   │   ├── colibri_gateway.py      speaks colibri's engine serve protocol over stdio
│   │   ├── roles.py                RoleSpec: a prompt + sampling, never a model
│   │   ├── harness.py              architectures A / B / C / D
│   │   ├── memory.py               Blackboard + EpisodicMemory (MnemOS EngramDB)
│   │   ├── tools.py                prompt-level tool calling (OLMoE has no native)
│   │   ├── metrics.py              .coli_usage / ROUTE_TRACE parsing, scoring, IO
│   │   ├── tasks.py                the 5 benchmark tasks + their rubrics
│   │   └── config.py               paths and knobs
│   ├── run_experiment.py           the A/B/C/D benchmark (--greedy control)
│   ├── run_all.sh                  everything, in order
│   ├── demo_end_to_end.py          one task, printing role -> model-instance map
│   ├── cam_bridge.py               upstream MnemOS agents against colibri over HTTP
│   ├── tests/                      pytest: execution / serving / integration
│   ├── tools/                      build_engine.sh, verify_model.py,
│   │                               reaggregate.py, summarize.py,
│   │                               combine_runs.py, expert_overlap.py
│   ├── patches/                    olmoe-route-trace.patch (measurement only)
│   ├── _build/                     patched build of colibri's c/ (generated)
│   └── _vendor/colibri-bin/        upstream Windows release binaries (downloaded)
├── models/olmoe_merged_int8/       the converted model container (generated)
├── results/                        runs, traces, JSON/CSV (generated)
├── ARCHITECTURE_ANALYSIS.md        what the two repos actually contain
├── HYPOTHESIS.md                   the claim, and how to falsify it
└── EXPERIMENTS.md                  what was measured

Both upstream checkouts are untouched — git -C colibri status --short and git -C ConversationalAgenticMemory status --short are both empty. The one change to colibri's C source (7 lines, measurement only) is applied to a copy in integration/_build, from integration/patches/.

---

What it does

Four configurations run the same roles on the same model.

A  task -> single agent                                     -> 1 instance,  1 call
B  task -> planner | researcher | critic, then tool,
           then aggregator                                  -> 5 instances, 5 calls
C  task -> planner -> tool -> researcher -> critic -> synth -> 1 instance,  5 calls
D  the same pipeline as C, one instance per role             -> 5 instances, 5 calls

EnginePool(shared=True|False) is the only architectural switch. D is the control: it is byte-for-byte the same harness, prompts and call order as C, differing only in whether the roles share a process. B vs C varies topology and instance count; C vs D varies instance count alone. The gateway records the engine pid and an instance_id on every generation, so "five roles, one model" is a fact in the trace rather than a claim in a README.

Per request, colibri's engine itself reports completion tokens, tokens/second, the expert-cache hit rate for that request, and its resident set size. Those numbers are copied through unmodified. Metrics this stack cannot produce (VRAM, concurrent batching, native tool calls) are listed with reasons in metrics.UNAVAILABLE and are never filled in with estimates.

---

Model

Host used for the recorded runs: AMD Ryzen AI MAX+ 395 (16 cores / 32 threads), 63.6 GB RAM, Radeon 8060S iGPU (unused — the engine is CPU-only), Windows 11, Python 3.12.10.

Second scale: GLM-5.2 on a DGX Spark

"Sufficiently large" is the load-bearing word in the hypothesis, and 1.3B active parameters over 64 experts per layer is not it. The same harness was therefore run a second time against a model two orders of magnitude larger in expert count, on different hardware and a different colibri engine:

Nothing in integration/ is model-specific: the family is selected by LOCI_FAMILY, and the engine's placement policy is passed through verbatim in LOCI_ENGINE_ENV. The only code the second model needed was a second chat template and a numeric request id — see ARCHITECTURE_ANALYSIS.md §2.

---

Reproduce

Everything below is run from Desktop/LOCI Advanced.

0. Python environment

python -m venv --system-site-packages .venv
./.venv/Scripts/python.exe -m pip install safetensors huggingface_hub pytest
./.venv/Scripts/python.exe -m pip install -r ConversationalAgenticMemory/requirements.txt

1. Get the engine binaries

Upstream ships prebuilt Windows binaries — no compiler needed for the stock path:

mkdir -p integration/_vendor && cd integration/_vendor
curl -sL -o colibri-win.zip \
  https://github.com/JustVugg/colibri/releases/download/v1.10.2/colibri-v1.10.2-windows-x86_64.zip
python -c "import zipfile;zipfile.ZipFile('colibri-win.zip').extractall('colibri-bin')"

Optional but recommended — build the patched engine so per-role expert traces work (needs a mingw gcc; see the header of integration/tools/build_engine.sh):

bash integration/tools/build_engine.sh

2. Convert the model (~14 GB download, one time)

./.venv/Scripts/python.exe colibri/c/tools/convert_olmoe_merged.py \
  --repo allenai/OLMoE-1B-7B-0125-Instruct --out ./models/olmoe_merged_int8

Resumable: rerun the same command if it stops. Then prove it loads:

cd integration && ../.venv/Scripts/python.exe tools/verify_model.py

That writes models/olmoe_merged_int8/.loci_ready, which is what the engine-dependent tests key off.

3. Tests

cd integration && ../.venv/Scripts/python.exe -m pytest tests -q

The stub-engine tests run in under a minute with no model. The engine-backed tests are skipped until .loci_ready exists.

Upstream's own suite still passes untouched:

cd ConversationalAgenticMemory && ../.venv/Scripts/python.exe tests/run_all.py

4. Demonstration

cd integration && ../.venv/Scripts/python.exe demo_end_to_end.py

Prints the role → model-instance → pid map, the tool step, per-role engine statistics, expert routing, and the final answer.

5. Benchmark

cd integration && ../.venv/Scripts/python.exe run_experiment.py
# subsets:
../.venv/Scripts/python.exe run_experiment.py --arch C D --tasks t1_moe_routing

Writes results/run-<timestamp>/results.json, runs.csv, one .coli_usage history per engine and (patched build only) one ROUTE_TRACE stream per engine. Then derive the tables:

../.venv/Scripts/python.exe tools/reaggregate.py     # recompute aggregates
../.venv/Scripts/python.exe tools/summarize.py       # the comparison table
../.venv/Scripts/python.exe tools/combine_runs.py ../results/run-*/

5b. The decisive control

colibri seeds its sampler once per process (sample.h), so a shared instance and per-role instances walk different random streams from identical prompts. Run C and D greedily to take the sampler out of the comparison:

../.venv/Scripts/python.exe run_experiment.py --arch C D --greedy   --out ../results/run-greedy
../.venv/Scripts/python.exe tools/reaggregate.py ../results/run-greedy

5c. Per-role expert routing (needs the patched build)

../.venv/Scripts/python.exe tools/expert_overlap.py

5d. The GLM-5.2 arm (DGX Spark)

# on the Spark, with colibri's GLM container already converted
cd ~/loci-advanced && bash run_spark_glm.sh      # ~5 h, all five steps
python3 integration/tools/spark_report.py ~/loci-advanced/results

run_spark_glm.sh runs, in order: the per-role routing study, C, A, the concurrency comparison, and the instance-count probe (which is expected to end in a refusal — that is the measurement). Per-step commands are in EXPERIMENTS.md §11.

5e. Watching it happen — the serving-layer GUI

The role can also be pushed below the prompt, as a serve-protocol command that re-places hot experts before prefill. That needs the lobe port:

python patches/apply_colibri_lobes.py --colibri _build_glm/c/colibri.c   # build copy only
python tools/make_lobes.py results/spark-glm/.../route_trace.txt \
       --out lobes_loci --per-layer 8                                    # one .coli per role
python -m loci_ui.server --live --port 8770 \
       --engine _build_glm/c/colibri --lobes lobes_loci \
       --record ui_session.jsonl --vram-gb 24 --ram-gb 40 --pin-gb 32

Open http://<host>:8770. The grid is 78 layers × 256 experts; per turn it shows which experts the router woke, which of those were already pinned (hit) and which were not (miss), the tier/pin placement the engine does at load — the hot pins, filled before any token — and every [LOBE] / [REPIN] / [PREFILL] line the engine prints.

A recording replays with no server at all:

python tools/make_ui_artifact.py ui_session.jsonl --meta meta.json --out page.html

The recorded GLM-5.2 session is in results/spark-glm/ui-session/. Read EXPERIMENTS.md §12 before drawing conclusions from it: the mechanism works and costs ~85 ms per switch, but on a 2458-slot hot store it moved zero experts, because AUTOPIN had already pinned 86–92 % of every role's manifest.

6. Upstream MnemOS against colibri over HTTP

cd integration && ../.venv/Scripts/python.exe cam_bridge.py

Starts colibri's own openai_server.py on the OLMoE engine and drives the unmodified agents.engram.Engram against it.

---

Configuration

Environment variables, all optional:

integration/run_spark_glm.sh and run_spark_glm2.sh set all of these for the GLM-5.2 arm; the placement values in them are copied from colibri's own run_glm.sh rather than invented here.

---

Headline result

At temperature=0, configuration C (five roles, one model instance) and configuration D (the same five roles, one model instance each) produced byte-identical answers on all five benchmark tasks — while C used 8.06 GB against D's 39.95 GB (4.96x less) and was slightly faster. Sharing one MoE across logical roles cost nothing measurable.

The other half of the hypothesis failed at that scale: every role routes to essentially every expert (1022–1024 of 1024 slots, near-uniform), so OLMoE's internal experts are not what differentiates the roles.

Re-run on GLM-5.2 (19,456 experts, DGX Spark) it comes out the other way. Each role touches 57–66 % of the expert grid, per-layer entropy is 6.50 of 8.00 bits, and on the length-controlled comparison role identity moves the router more than topic does (Δcosine +0.0876, against +0.0395 on OLMoE). The "every role uses every expert" result was an artefact of having only 64 experts to use.

And the cost argument stops being an argument: five GLM-5.2 instances cannot be started on a 119 GB machine at all — colibri refuses the fifth rather than be OOM-killed — so the traditional multi-agent configuration is not expensive but unbuildable, while the five-role shared-instance pipeline runs in one 41 GB process. What the second scale takes away is the case for the pipeline: five roles cost 6.4× the latency of a single agent for a score the rubric can no longer tell apart. Details and caveats in EXPERIMENTS.md §10.

Reading the results

• EXPERIMENTS.md — the measurements, each labelled Verified experimentally, Partially verified, Not verified, Blocked by hardware or Blocked by repository limitations.
• HYPOTHESIS.md — F1…F6, the conditions under which the idea is wrong.
• ARCHITECTURE_ANALYSIS.md — what is actually in the two repositories, including the things that do not work.

Credits

• colibrì — https://github.com/JustVugg/colibri (Apache-2.0)
• ConversationalAgenticMemory / MnemOS — https://github.com/Jonas-Schewior/ConversationalAgenticMemory
• OLMoE — Allen Institute for AI, allenai/OLMoE-1B-7B-0125-Instruct