Launched this week
CrabTalk
The agent daemon that hides nothing. 8MB. Open Source
260 followers
The agent daemon that hides nothing. 8MB. Open Source
260 followers
An 8 MB daemon that streams every agent event to your client — text deltas, tool calls, thinking steps, all of it. Connect what you need, skip what you don't. One curl to install. Bring your own model.
CrabTalk
I write systems software. I looked at OpenClaw — 1.2 GB. Hermes — 40+ bundled tools. Why does your agent ship someone else's choices?
CrabTalk is a daemon. 8 MB. You put what you need on your PATH — your search, your gateway, your tools. They connect as components. They crash alone. They swap without restarts.
You could build any of those apps on top of CrabTalk. You can't build a CrabTalk underneath them.
Open source. Rust. One curl to install.
@clearloop What's a real-world workflow where CrabTalk's 8MB modularity saved you time vs. bloated agents like OpenClaw?
CrabTalk
@swati_paliwal
CrabTalk is Rust. One binary, 8MB, no dependencies to install. It's running before your prompt returns, why it stays that small: native I/O, minimal allocation, no GC.
For the real-world cases, let's just talk on JSON, JSON encoding and decoding are extremely important in LLM-based applications — often one of the most critical reliability bottlenecks in production systems.
Every agent request is JSON in, JSON out — over a few hundred requests, Rust's serde spends seconds where a Node.js runtime spends minutes on encoding alone. ~8MB resident, no runtime heap bloat, no OOM at 3am.
When you're running always-on agents in production, that predictability is the difference between infrastructure and babysitting:
OpenClaw is a personal AI assistant — 20+ channels, massive ecosystem, great for that.
CrabTalk is production agent infrastructure.
DMs open if you want to dig in.
streaming thinking steps alongside tool calls in one feed is what almost nothing does by default. curious what happens with concurrent tool calls - does the stream stay coherent? also 8MB is impressive, what's the runtime?
CrabTalk
@mykola_kondratiuk Valuable questions 🦀
1. Concurrent tool calls
An updated version is exactly in my TODOs, see crabtalk#90, there are mainly 2 cases about this:
agent request batch tool calls — LLM APIs natively support multiple tool calls in response, we simply spawn a future to `join_all` for performing the concurrency execution
agent spawn multiple agents doing M x N tool calls, this is recursive case of above, since we delegate agent is a tool call in our design, this case is natively supported as well
2. What's the runtime
This question is direct and also very challengeable!
To be specific, CrabTalk is a daemon (you can imagine it's a pg service or a `dockerd`), we have the TUI client and people can develop any client of it based on our base protocol
For the runtime, referenced from the layering
it's somewhere we babysitting the agent standard stuffs (e.g. tools, MCP, skills)
plus a super light memory based on fs and BM25 (yes, the memory can be swapped by your customized memory).
And if we count on the daemon stuffs, we'll have context isolation, cron jobs, event loop, protocol configs.
For the size, if we kick out the TUI, the runtime + daemon may have just 2~3 MB, and the http related stuffs for model API and related MCP implementations are taking the most of the size
good to know it's tracked - following the issue. appreciate the transparency on what's roadmapped, makes it easier to evaluate whether to adopt early.
CrabTalk
@mykola_kondratiuk Thanks for the feedback!
btw, CrabTalk is actually managed with the RFC-like process, see the book!
RFC issue -> implementation -> Stabilized into the book
The daemon will stay as it is, what we'll do will be just optimizing the performance, stability and security of it, repeat.
Beyond the daemon, there will be frequently used components developed inside the repo as well which could be easy installed via `crabtalk <xxx>`, the cargo style solution, also, soon we'll have our desktop version released!
that RFC process is underrated for small open source projects. keeps the scope creep out and gives contributors a clear path in.
MacQuit
The Unix philosophy applied to AI agents. Most frameworks today bundle everything and ship a bigger binary. But if you've run agents in production, you know the bloat is where the bugs hide.
8MB with native Rust and no GC is the kind of foundation you want for agents running continuously. "Components crash alone and swap without restarts" is how real infrastructure works. Refreshing to see that mindset in AI tooling.
As someone who builds native Mac apps and cares about binary size and resource usage, I appreciate tools that respect the machine. Curious about memory profile under sustained load with multiple agents running at once.
CrabTalk
@lzhgus Thanks — that's exactly the kind of question we want.
Binary: 5.1MB after a recent pass that stripped vendored OpenSSL, replaced a bloated MCP client library with a 250-line inline one, and swapped aws-lc-rs for ring. No syntax highlighting blobs, no unused protocol variants.
Runtime memory: Agents are stateless tokio tasks — they don't hold conversation history. Sessions do, but auto-compaction kicks in at ~100k tokens and summarizes history down, so they don't grow unbounded. Memory entries (our persistence layer) are individual markdown files scored with BM25 — no database, no embedding model, no background indexing. Everything is on-demand.
Multiple agents: They share a single daemon-level memory instance behind a RwLock. No per-agent copies. Tool dispatch goes through channels with oneshot replies — one async task per tool call, no thread-per-agent.
What to watch: Sessions aren't evicted when idle (user closes them explicitly), so a long-lived daemon accumulates session state. That's the main thing — the agent infrastructure itself is negligible.
The memory system design is documented in rfc#0038 if you want the full rationale — we deliberately chose files + BM25 over graph databases and vector stores to keep the operational weight near zero.
btw, I just created an issue Support pluggable memory provider for tracking your need, feel free to join the discussion!
MacQuit
@clearloop Really appreciate the detailed breakdown. The auto-compaction at ~100k tokens is a smart approach to keeping memory bounded without losing context. And the decision to use markdown files + BM25 over vector stores makes a lot of sense for keeping operational weight low. Sometimes the simplest data structure that works is the right one.
The session accumulation point is good to know. For a long-running daemon, having some kind of idle timeout or LRU eviction would help, but I can see why that's a separate concern from the core agent infrastructure.
I'll check out rfc#0038 and the pluggable memory issue. Thanks for being so transparent about the design decisions.
Apparent for Gmail
Been nipping at your heels all day. Congrats on the launch, amazing product!
CrabTalk
@apparentforgmail Hey, thanks! Been fun having you right behind me all day.
Honestly, I used to think a weekend launch would be simpler… but I’ve been stressed out the whole time 😂
Apparent for Gmail
@clearloop Literally all day.
I forget this is also people's livelihoods, so makes sense. I'm somewhere in between you and SlapMac, and have been enjoying the ride!
CrabTalk
@apparentforgmail I'd say both SlapMac and your product are interesting, while mine is a bit too boring at the current stage, will catch you up soon!