OctoClaw

English | 简体中文

Auto-delegation, status truth, and cost-aware model routing for OpenClaw agents.

OctoClaw keeps the main agent responsive by moving slow or uncertain work into native OpenClaw sub-agents, then reports durable task truth back to Slack, Feishu, WeChat, and the CLI.

---

The problems it fixes

Your main agent stalls on one big task. You ask it to write a script, do a bit of research, or run a test pass — then it sits for several minutes with no signal, sometimes ten-plus. You can't tell if it's still working or already dead, and you're not brave enough to interrupt.

Every turn burns your most expensive model. "Can you check xxx for me?" lights up a frontier model's input tokens. Small asks, heavy artillery, end-of-month bill shock.

Your main context gets buried. Raw sub-task output, intermediate reasoning, tool-call logs — they all pile into the main conversation. Thirty turns later the agent is still dragging the trash around.

"Task completed" but nothing to show. You know "it finished running" but can't tell whether it actually produced a result, where the artifact is, or whether the failure was the task's or the substrate's.

OctoClaw fixes those four things.

---

What it does

• 🧠 Automatic sub-agent delegation — reply | delegate decides per turn whether the main agent answers directly or spawns a background sub-agent
• 🪶 Lightweight judge — a local Ollama model or a cheap remote endpoint decides the route, so your main model never burns tokens just to decide "reply vs delegate"
• 💰 Cost-aware model selection — shadow mode compares "what if we'd used a cheaper model?" on real traffic, only promotes when the data holds
• 📚 Auto-discovered model intel — prices and capabilities pulled from OpenRouter, models.dev, and OpenClaw's provider catalog; cross-source disagreements are flagged, not silently overwritten. Uses PinchBench / Aider / SWE-bench / BFCL as cold-start priors — but your local replay data always outranks any leaderboard
• 🧹 Main context stays clean — sub-agents run with their own context; only compact result packets come back, never raw transcripts
• 📊 Trustworthy status — lifecycle truth comes from OpenClaw's native TaskFlow; metadata lives in SQLite; states like running_slow / stalled / timed_out / degraded_completed_without_result have crisp meanings
• 🔁 Recoverable tasks — delegation tickets, retry attempts, amendment protocol (steer_child / queue_after / cancel_and_respawn)
• 💬 IM out of the box — Slack (streaming + thread), Feishu (thread), WeChat (plain text), with explicit degradation per tier
• 🔧 One CLI for everything ops — octoclawctl handles install, deploy, status, nightly review, calibration gates

Release status

OctoClaw is approaching the 0.6.x release line.

Surface	Status	Notes
OpenClaw runtime plugin	✅ release candidate	Built against OpenClaw 2026.5.12 native TaskFlow and Slack plugin contracts
Slack	✅ live-smoked	Streaming, ACK, footer truth, native final delivery, and parallel child status are covered by stability full
Auto Router	✅ gated live for delegated lanes	Uses local config, model pricing/capability snapshots, health cooldowns, and local promotion evidence
Feishu	⚠️ adapter ready; target smoke required	Card/status/onboarding paths exist, but release migration should smoke on the Feishu-only target machine
WeChat / Telegram / Discord	⚠️ adapter tiers	Plain/rich delivery contracts are present; not all channels have live acceptance harnesses

• Release checklist: docs/release-checklist.md
• Release notes draft: docs/release-notes-v0.6.0.md
• Migration and Feishu-only runbook: docs/octoclaw-migration-onboarding-feishu-guide.md

---

Why it's built this way

1. Built on OpenClaw's native TaskFlow — no wheel reinvented

Lifecycle truth (running / completed / failed / timeout) comes from OpenClaw itself. OctoClaw does not run a second task-state machine. An earlier iteration tried that — the state engine drifted from the substrate, restarts left "completed" tasks with no artifact, and operators lost trust. Never again.

Three layers, each with a clear job:

Layer	Authority	What it owns
OpenClaw native TaskFlow	execution lifecycle	whether the process is alive, whether runId was accepted, whether native announce delivered
SQLite runtime ledger	metadata + audit	WorkContract, route seal, spawn intent, event log
task-state.json	rebuildable status cache	deletable; the two layers above can reconstruct it

No resident daemon. No runner pool.

2. Sub-agent first; multi-agent later, only if the data says yes

Multi-agent looks sexy but only pays off when concurrency buys latency, isolation buys correctness, and specialization buys quality — all three at once. Otherwise it's pure cost multiplication plus coordination overhead plus hidden state drift.

OctoClaw stays on solo_worker: the main agent is a coordinator; it spawns one sub-agent per scoped task. When nightly data actually proves a multi-agent topology is cheaper / faster / better for a given task class, we'll turn on advisor_assisted or threaded_subagents for that class. Not before.

3. A cheap judge routes, so your main model doesn't have to

Letting the main model decide "should I reply or delegate?" has three costs:

• Slow — frontier-model first-turn latency is 2-5 s before any visible output
• Expensive — you're paying frontier input-token prices just to pick a route
• Polluting — that reasoning stays in the main context for every subsequent turn

OctoClaw's judge is a separate layer:

• Runs locally — Ollama + Qwen3 0.6B works as a judge,