Skip to content

Contributing

Roadmap

What is being worked on, how items are prioritized, and what shipped recently.

The roadmap lives in roadmap/README.md, grouped by area (Kernels, Inference, Harness, Loading, Networking, Room, UI, Infra, Tests). Design notes sit next to it as numbered files, and the pinned issue #83 has the same list as a checklist.

Priority Meaning
P0 Now. Broken, wrong, or the biggest thing holding rooms back.
P1 Next. Planned and ready to build.
P2 Later, or needs a design note first.

Issues get the area: label of their section.

  • Prefill speed (P0, #2). Prefill is the biggest gap against native llama.cpp. On one GB10, the first token of a 172-token prompt takes about 1.0 s on the MoE, against about 0.07 s natively.
  • Split MoE rooms that end answers mid-call (P0, #68). A two- or three-device MoE room must match a single device.
  • Coop GEMV with 8 rows per workgroup returns wrong values (P0, #47).
  • Hand the host role to another device when the host leaves (P1, #58).
  • Pinned model revisions and weight hashes (P1, #19), so an upstream re-upload can’t mix old and new ranges.

Some roadmap lines and issues lag behind merged work. As of September 30, 2026:

  • Done: TURN relay for strict networks (#1); room checkpoints on disk (#69); tokenizer checked against llama.cpp (#70); prefix-cache reuse across Code mode turns (#73); harness audit fixes (#76); delete one cached model (#59); GPU tests that print FAIL exit nonzero (#81); npx @pooled/cli serve with tool calling (#4); converted weights cached in the browser (#77).
  • Partly: self-hosted signaling (#15: fallback list and ?signal= shipped); longer context (#71: ?kv=q8 exists, off by default); actionable errors (#16: no diagnostic report button yet); Code mode agent robustness (#74); automatic re-deal (#3: experimental, on by default); keeping worker tabs alive (#78, #44).
  • run_js in production (#75) is closed, but needs a preview site on a second domain, which pooled.run doesn’t have yet (#79).
  1. Find an item in the roadmap and read its design note, if it has one.
  2. Comment on its issue before you start, so two people don’t build the same thing.
  3. P2 items and anything that changes the protocol, the model output or what peers can see need a design note first. See Contributing.

Benchmark reports from hardware we don’t have always help. See Benchmarking.