SkyClaw: An Open Agent Runtime Written in Rust

SkyClaw is an open-source agent runtime written in Rust, developed across 7 phases with 34 new features and 905 tests. The project has zero Clippy warnings and is available on GitHub.
Phase 0 — Hardened Foundation
- Graceful shutdown with task checkpointing — nothing lost on restart
- Provider circuit breaker with exponential backoff + jitter (handles 429/500/503)
- Streaming responses with edit-in-place on Telegram (throttled at 30 edits/min)
- Up to 200 tool rounds per task, 30-min timeout
Phase 1 — Agentic Core
- Task decomposition into a DAG of subtasks with topological execution order + cycle detection
- SQLite-backed persistent task queue — checkpoints after every tool round, survives process restarts
- Priority-based context/token budgeting across 7 categories (memory, learnings, history, etc.)
- Self-correction engine — after N consecutive failures on a tool, forces strategy rotation
- Cross-task learning — extracts lessons from completed tasks, injects into future context
Phase 2 — Self-Healing
- Watchdog monitors all subsystems, auto-restarts degraded ones
- State recovery with rollback/skip/escalate strategies
- Memory backend failover — automatic primary→secondary switch, auto-recovery when primary returns
Phase 3 — Efficiency
- Tiered model routing — simple queries hit cheap/fast models, complex tasks get premium
- Semantic history pruning — scores each message by importance, drops lowest first
- Output compression — extracts signal from verbose tool output, keeps first/last N lines + summary
Phase 4 — Ecosystem
- Channels: Telegram, Discord (serenity/poise), Slack (poll-based)
- Typed git tool with safety rails (force-push blocked by default)
- Skill registry — Markdown + YAML frontmatter, keyword-matched and injected into system prompt
- HTMX web dashboard, dark theme, <50KB, polls health every 10s
Phase 5 — Cloud Scale
- S3/R2 FileStore with multipart upload + presigned URLs
- OpenTelemetry metrics (provider latency, token usage, tool success rate, etc.)
- Multi-tenancy with full workspace/vault/memory isolation per tenant
- OAuth flows (GitHub, Google, AWS) with PKCE
- Horizontal scaling via Docker orchestrator
Phase 6 — Advanced Agentic
- Parallel tool execution (up to 5 concurrent, auto dependency detection via union-find)
- Agent-to-agent delegation — spawns scoped sub-agents, max 10/task, no recursive spawning
- Proactive triggers: file change, cron, webhook, threshold — disabled by default, rate-limited
- Adaptive system prompt — self-patches with confidence scoring, auto-expires underperforming patches
Phase 7 — Multimodal
- Vision support for JPEG/PNG/GIF/WebP — base64-encoded, works with both Anthropic and OpenAI provider formats
The developer is seeking feedback from the Rust community on what to build on top of this runtime.
📖 Read the full source: r/openclaw
👀 See Also

OmniRecall Beta: FAISS-Powered Memory Injection for Cloud LLM Chats
OmniRecall is a local mitmproxy bypass that intercepts traffic to cloud chat interfaces like DeepSeek, adding a permanent memory layer using FAISS indexing and sentence-transformers MiniLM-L6. It's currently in beta, requires CPU-only operation, and uses an aggressively restrictive source-available license.

Claude Code as a Compiler: A Practical Reframe for AI Development
A Reddit post argues Claude Code functions as a compiler translating English to working software, drawing parallels to historical computing breakthroughs like Grace Hopper's A-0 and FORTRAN. The author describes generating 400 lines across 6 files from a 3-paragraph English description, catching two issues in 25 minutes.

Claude wrote 3,000 lines of code instead of importing pywikibot — a case study in AI agents ignoring existing libraries
A developer tasked Claude Code (Opus 4.7) with fixing typos on Fandom wikis. The model wrote ~3,000 lines of Python reimplementing pywikibot, mwparserfromhell, and RETF rules rather than importing them. The post explores why this happens and how a two-minute search reduced the codebase to 1,259 lines.

Benchmarking Nemotron 3 Super 120B with 1M token context on M1 Ultra
A user tested Nemotron 3 Super 120B with a Q4_K_M quantized model using llama.cpp on an M1 Ultra, achieving a 1 million token context window that consumed approximately 90GB of VRAM. Performance benchmarks show token generation speeds ranging from 255 t/s at 512 prompt processing down to 22.37 t/s at 100,000 token context.