its-over-9k (o9k)

What does the scouter say about his context level? IT'S OVER 9000!!!

o9k is a meta-framework for AI coding agents. It doesn't invent yet another technique — it combines the best token-efficiency and agent-quality frameworks into one coherent, conflict-free system of skills and plugins, wired to a persistent memory MCP. Primary packaging is a Claude Code marketplace; the same pillars also wire into Cursor, Codex, OpenCode, and Hermes via /o9k-init.

Every framework below saves tokens or improves output on its own. Combined naively, they fight each other — two plugins hooking SessionStart, two output styles rewriting your prose, two "plans" claiming to be the source of truth. o9k's job is the arbitration layer: each concern has exactly one owner, and the pieces multiply instead of colliding.

The Seven Pillars

| Pillar | Plugin | What it does | Standing on the shoulders of | |--------|--------|--------------|------------------------------| | Doctrine & arbitration | o9k-core | The rules of engagement: who owns which hook, which style, which plan. Loaded once, always on. | Anthropic context-engineering guidance | | Output compression | o9k-caveman | Telegraphic output style: ~50–65% fewer output tokens, with automatic fallback to full prose for anything safety-critical. | caveman (MIT) | | Context discipline | o9k-scout | Load structure, not files: search before read, targeted line ranges, one canonical repo map per session. | aider repo-map, codesight, ast-grep | | Subagent isolation | o9k-dispatch | Cost-gated fan-out: offload searches and decomposable work to isolated subagents that return results, not transcripts. Own skill (dispatch) with fan-out cost gate + RESULT-only contract. | Anthropic multi-agent research | | Memory | o9k-memory | A memory MCP so sessions never start from zero — compact briefing at session start, deep recall on demand, save-before-compact. | hmem (available default), TIM (planned) | | Discovery | o9k-recon | Find and classify companion frameworks; one-command companion bundle installs. | — | | Multi-agent roster | o9k-roster | Role→CLI×model fallback chains, subscription usage collector (multi-window ~/.o9k/usage.json), adaptive watcher, limit-watch + handoff, optional OpenRouter/AA score refresh, cross-CLI mailbox runs. See docs/MULTI-AGENT.md. | — |

Each pillar is an independent plugin. Install all seven or cherry-pick — o9k-core is the only one the others assume.

Why combining multiplies

• Less output → less context. Everything the agent says gets fed back into every later turn. caveman-style output doesn't just save this turn's tokens — it shrinks every future turn and delays compaction.
• Less context → better memory. What scout refuses to load blindly never has to be summarized away. What dispatch isolates in a subagent never pollutes the main context. Compaction fires later, loses less.
• Memory → less re-reading. A 300-token briefing from the memory backend replaces the 20k tokens of "let me look around the codebase" that every fresh session burns.
• Together: the agent's effective context — the fraction doing useful work — goes way past what any single technique achieves. It's over 9000.

Zero effort by design

The human should not have to do — or know — anything. After install, a SessionStart hook in o9k-core injects the doctrine automatically every session: the agent compresses its output, loads only what it needs, offloads noisy searches, and saves state before compaction — no commands, no reading, no habits to learn.

What automation can't do (a one-time hmem init, disabling legacy superpowers dispatch skills if still active), the agent handles conversationally: /o9k-init is the guided setup — it detects what's already on the machine, asks which companion bundle you want, installs git if you're missing it, and when something you already run collides with a bundle pick it explains why the pick is better and migrates your data before uninstalling anything (your call, either way). On the very first session the agent offers it automatically, and /o9k-guide brings back a one-minute orientation any time. The guide is personalized — it detects your actual setup and mentions only what's missing, offering to fix each item for you. A fully set-up install gets three sentences: everything runs by itself, nothing to do, /o9k-stats shows the effect.

Platforms

| OS | Core pillars (doctrine, caveman, scout, dispatch, memory, recon) | Multi-agent (roster, runs, collector) | |----|------------------------------------------------------------------|----------------------------------------| | Linux | ✅ full | ✅ full (systemd units for watcher/resume) | | macOS | ✅ full | ⚠️ needs brew install tmux; watcher/resume via launchd plists (plugins/o9k-roster/launchd/) | | Windows | ✅ hooks + update check work natively | ❌ tmux/expect/bash stack — use WSL |

/o9k-init prints this as a Platform line first and skips setup questions the host OS can't honor.

Install

Fast path (npm — Cursor, Codex, OpenCode, Hermes, and a global CLI):

npm i -g its-over-9k && o9k setup

o9k setup wires shared skills and session hooks for every detected host. Then optionally install the memory backend:

npm install -g hmem-mcp && hmem init

(Scoped alias @bumblebiber/o9k is prepared in-repo; install via its-over-9k until the scoped name is publicly resolvable on the registry.)

Claude Code (in-session marketplace):

/plugin marketplace add Bumblebiber/its-over-9k
/plugin install o9k-core@o9k
/plugin install o9k-caveman@o9k
/plugin install o9k-scout@o9k
/plugin install o9k-dispatch@o9k
/plugin install o9k-memory@o9k
/plugin install o9k-recon@o9k
/plugin install o9k-roster@o9k

Then run /o9k-init in a session — it detects your setup, walks you through the companion bundle choice, and handles conflicts and migration.

Works with Claude Code, Codex, Cursor, OpenCode, and Hermes on the same machine: /o9k-init (or o9k setup) syncs shared o9k skills and wires session hooks on every detected host (it never installs missing CLI binaries — see the o9k-init skill).

TIM is a planned backend — not yet published. Once it ships, o9k-memory will auto-detect it (tim resolve-project) and prefer it; until then the hook falls back to hmem automatically, so nothing to change. Track it at Bumblebiber/tim.

Migrating from [email protected] (clean reinstall)

1.x was the old hmem CLI (bin: hmem / hmem-curate), not this meta-framework. Do a clean swap — do not leave the old global install in place:

npm uninstall -g its-over-9k
npm install -g hmem-mcp && hmem init          # memory backend (replaces 1.x)
npm install -g its-over-9k@latest && o9k setup

After that, which o9k should point at the new CLI and which hmem at hmem-mcp. If either still points at a stale path, clear your shell hash (hash -r) or open a new terminal.

One command for the companions

Don't hand-install the third-party frameworks below. o9k-recon ships a bundle installer that wires up a whole tested stack at once:

/plugin install o9k-recon@o9k

then run the companion-bundles skill (or install/o9k-companions.sh recommended --run). Bundles: minimal, recommended, max — see docs/BUNDLES.md.

Doctor & uninstall

o9k writes symlinks, rules, and hook wrappers across host config dirs — two scripts keep that auditable:

node plugins/o9k-core/scripts/o9k-doctor.mjs        # read-only: list artifacts, flag dangling/stale
node plugins/o9k-core/scripts/o9k-uninstall.mjs --dry-run   # then --run to remove them

The doctor flags dangling skill symlinks and wrappers whose baked marketplace path no longer exists (e.g. after moving the clone — fix via update-check.mjs --refresh-hosts). Uninstall removes only provably-o9k artifacts, strips o9k entries from host hook configs without touching foreign ones, keeps ~/.o9k user data, and prints the manual follow-ups (/plugin uninstall, systemd/launchd units).

Playing with others

o9k deliberately does not re-implement workflow methodology, issue tracking, docs injection, or symbol-level navigation — excellent frameworks exist for those. This matrix covers every o9k-compatible companion and how each pair gets along:

• 🟢 complement each other — worth more together than apart
• ⚪ don't touch — no interaction, safe by construction
• ⚠️ one rule needed — works once you name a single owner (see notes)
• 🔴 block each other — same concern, never both active

| | o9k | Ponytail | Context7 | ccusage | superpowers | beads | Serena | ast-grep | hmem/TIM | task-master | BMAD·spec-kit | |---|:--:|:--:|:--:|:--:|:--:|:--:|:--:|:--:|:--:|:--:|:--:| | o9k | — | 🟢 | 🟢 | ⚪ | ⚠️¹ | 🟢 | 🟢 | 🟢 | 🟢 | ⚪ | ⚪ | | Ponytail | 🟢 | — | 🟢 | ⚪ | 🟢 | ⚪ | ⚪ | ⚪ | ⚪ | ⚪ | ⚪ | | Context7 | 🟢 | 🟢 | — | ⚪ | 🟢 | ⚪ | 🟢 | ⚪ | ⚪ | ⚪ | ⚪ | | ccusage | ⚪ | ⚪ | ⚪ | — | ⚪ | ⚪ | ⚪ | ⚪ | ⚪ | ⚪ | ⚪ | | superpowers | ⚠️¹ | 🟢 | 🟢 | ⚪ | — | ⚠️² | ⚪ | ⚪ | ⚪ | ⚠️² | 🔴 | | beads | 🟢 | ⚪ | ⚪ | ⚪ | ⚠️² | — | ⚪ | ⚪ | ⚠️³ | 🔴 | 🔴 | | Serena | 🟢 | ⚪ | 🟢 | ⚪ | ⚪ | ⚪ | — | ⚪ | ⚪ | ⚪ | ⚪ | | ast-grep | 🟢 | ⚪ | ⚪ | ⚪ | ⚪ | ⚪ | ⚪ | — | ⚪ | ⚪ | ⚪ | | hmem/TIM | 🟢 | ⚪ | ⚪ | ⚪ | ⚪ | ⚠️³ | ⚪ | ⚪ | — | ⚠️³ | ⚪ | | task-master | ⚪ | ⚪ | ⚪ | ⚪ | ⚠️² | 🔴 | ⚪ | ⚪ | ⚠️³ | — | 🔴 | | BMAD·spec-kit·SuperClaude | ⚪ | ⚪ | ⚪ | ⚪ | 🔴 | 🔴 | ⚪ | ⚪ | ⚪ | 🔴 | —⁴ |

1. o9k × superpowers: o9k-dispatch owns subagent isolation by default; superpowers owns methodology. Disable stock dispatching-parallel-agents only if it is still enabled.
2. superpowers × beads/task-master: a plan store beats plan files — the store owns plans, disable superpowers' plan markdown. One plan owner.
3. plan stores × memory: the store owns work items, memory owns lessons/decisions. Never track the same work in both.
4. Grouped entries block each other too — BMAD, spec-kit, and SuperClaude all claim the methodology spine; any two of them collide.

Not in the matrix — replacements, not companions. Some frameworks claim a concern an o9k pillar owns; they never share a setup with o9k, so their pairings are moot. Run them instead of the pillar they displace, or not at all: claude-mem / mem0 (vs the memory backend), Graphify / claude-context / codebase-memory-mcp (vs scout's overview), token-optimizer-mcp (vs caveman+scout).

Full per-framework notes and install mechanisms: docs/COMBINING.md. The same facts exist machine-readable as a compatibility layer (plugins/o9k-core/compat/registry.json): detection, arbitration, and the export-first migration driver (o9k-migrate.mjs) are all registry-driven — /o9k-init uses it to detect rivals, argue the trade-off, and migrate data before anything is uninstalled.

Scouting for new frameworks

The ecosystem moves weekly (9,000+ marketplace entries and climbing). o9k-recon ships framework-scout — a GitHub Scout skill that tells the agent where to hunt (Trending, Topics, the plugin directory, awesome-lists), how to score a candidate (concern → stars → freshness → license → install mechanism), and how to slot it into the matrix above (symbiotic / orthogonal / blocking) before proposing a bundle or matrix update. See plugins/o9k-recon/skills/framework-scout/SKILL.md.

Status

Early but functional. Seven pillars; hooks and multi-CLI wiring ship for the hosts above.

• SessionStart (o9k-core) — injects a ~70-token doctrine directive (never documentation) so all installed pillars apply automatically; flags open arbitrations; offers /o9k-guide once on the first session. Disable via O9K_CORE_HOOK=off.
• SessionStart update check (o9k-core) — reports which pillars/companions are updatable, instantly from a cache; the actual version check runs detached in the background (once per O9K_UPDATE_INTERVAL_HOURS, default 24h), so it never slows session start. O9K_UPDATE_CHECK=notify (default) reports; auto also applies the safe npm-global updates (companions + its-over-9k when installed via npm); off disables. Claude marketplace plugins stay notify-only — never clobbered. After /plugin marketplace update o9k or npm i -g its-over-9k@latest, run /o9k-update --refresh-hosts (npm --apply already refreshes hosts when its-over-9k itself was updated).
• SessionStart (o9k-memory) — detects the memory backend (TIM via tim resolve-project, else hmem) and injects a compact loading directive (never memory content). Stays silent if the backend's own hooks are already installed — one owner per concern. Disable via O9K_MEMORY_HOOK=off.
• PreCompact (o9k-memory) — fires the backend's checkpoint (tim checkpoint / hmem checkpoint) in the background before compaction summarizes the session away. Never blocks or delays compaction.
• Limit watch (o9k-roster) — reads ~/.o9k/usage.json (no provider API calls) and warns / instructs handoff when a provider, CLI, or usage window crosses its threshold: burst windows like claude:5h/claude:session (reset in hours) hand off at limits.handoff_at_burst (default 0.8); week/monthly windows like codex:weekly hand off at limits.handoff_at (default 0.95). Wired on all hosts; model choice stays in roster.mjs, never in LLM reasoning.
• Subscription usage collector (o9k-roster) — optional adaptive watcher + roster usage --refresh populate per-window fractions for Claude/Codex/Cursor (claude -p "/usage" fast path; PTY for interactive tables). pick/dispatch gate per model; pre-dispatch refresh when cache is stale. Install: o9k-usage-watcher.sh (symlink or O9K_ROSTER_SCRIPTS + systemd drop-in). Spec: docs/superpowers/specs/2026-07-17-o9k-roster-usage-collector-design.md.
• Cross-CLI runs (o9k-roster, opt-in) — disk mailbox under ~/.o9k/runs/<id>/, blocking runs.mjs wait, systemd o9k-resume.service. Only when ~/.o9k/roster.json exists; single-agent installs stay on dispatch path A. Spec: docs/superpowers/specs/2026-07-17-cross-cli-run-resume-design.md.

o9k-core also ships /o9k-guide (personalized setup orientation backed by a read-only detector script), /o9k-update (check pillars & companions for newer versions and apply the safe ones), and /o9k-stats: a zero-dependency analyzer over Claude Code's session transcripts — output share, cache hit profile, avg output per turn — so the savings are measured, not vibes.

Credits & prior art

o9k adapts ideas (and gives full credit) from: caveman by Julius Brussee (MIT), superpowers by Jesse Vincent (MIT), beads by Steve Yegge (MIT), aider's repo-map, LLMLingua, and Anthropic's multi-agent research system write-up. Memory by hmem (with TIM planned). Compatibility research also covers Context7, ccusage, claude-mem, claude-context, and the spec-driven crowd (spec-kit, BMAD, task-master) — see docs/COMBINING.md.

License

MIT