SlimClaw integration — ClawRouter under the hood + mutual blocking issue #45
Description
Hey team! 👋
I built SlimClaw — a token optimization plugin for OpenClaw (now on npm) — and integrated ClawRouter as the primary classifier in a hybrid routing setup.
What we did
ClawRouter is running under the hood in SlimClaw as the intelligence behind model routing. The integration uses a hybrid approach:
- ClawRouter as primary classifier — analyzes prompt complexity and recommends the optimal model tier
- Heuristic fallback with circuit breaker — kicks in if ClawRouter is unavailable
IRoutingProviderinterface — abstracts routing so the classifier is swappable
The system classifies prompts into tiers (simple, mid, complex, reasoning) and maps them to models. In testing, the combined approach (windowing + routing) shows potential savings of ~97% — windowing cuts ~60% of tokens, routing saves ~92% on model costs, and they stack multiplicatively.
The data when we join forces
| Metric | SlimClaw alone | ClawRouter alone | Combined |
|---|---|---|---|
| Token reduction | 60-80% (windowing) | — | 60-80% |
| Cost reduction (routing) | — | ~92% | ~92% |
| Combined savings | — | — | ~97% |
SlimClaw handles what gets sent (trimming history, caching, breakpoints). ClawRouter handles where it gets sent (picking the right model). Complementary, not competitive.
The blocking problem we both face
Here's the thing — we're both stuck on the same wall: OpenClaw's hooks are observation-only.
Right now SlimClaw runs in observation mode: we classify every prompt with ClawRouter, log the recommendation, calculate what we would save... but can't actually route to a different model or trim the history. The llm_input hook returns void.
There's a PR (openclaw/openclaw#20426) that adds prompt and assistantTexts mutation, but it doesn't include historyMessages or model — which is what we'd need for both windowing and routing to actually work.
I've been pushing for historyMessages support in openclaw/openclaw#20416 — the maintainer (chandika) agreed it makes sense but wants to land the current PR first, then open a follow-up.
Curious how you're approaching this on your side? Are you hitting the same limitation, or do you have a different integration path?
What each of us does differently
| Concern | SlimClaw | ClawRouter |
|---|---|---|
| Context optimization | ✅ Windowing, importance scoring, summarization | — |
| Cache optimization | ✅ Breakpoint injection, cache hit tracking | — |
| Model classification | Heuristic fallback | ✅ Primary classifier |
| Cost calculation | Per-request metrics + dashboard | Built-in pricing |
| Metrics/Dashboard | ✅ Real-time web dashboard | Stats via API |
Links
- SlimClaw: npm · GitHub
- Integration PR: evansantos/slimclaw#2
- OpenClaw blocking issue: openclaw/openclaw#20416
Would love to hear your thoughts on the integration and how we can push the hook mutation forward together. The combined value proposition is way stronger than either project alone. 🤝