Chatbot Framework Rebuilt in Rust: 10MB Binary

What It Is

Femtobot is a Rust-based chatbot framework that compiles to a single 10MB executable. The project emerged from frustration with supposedly “lightweight” Python frameworks that routinely require 350MB or more in dependencies before running a single line of bot logic.

The framework handles agent-style workflows through Telegram integration, maintains conversation memory using local SQLite with vector storage, and executes tools including shell commands, file operations, and web requests. Built on rig-core, it provides the core functionality developers need for conversational agents without the typical runtime bloat.

The codebase prioritizes simplicity and quick iteration over idiomatic Rust patterns, making it approachable for developers who want to understand and modify the internals without navigating complex abstractions.

Why It Matters

Resource-constrained deployments have become increasingly common as developers look to run AI agents on edge devices, older hardware, and budget VPS instances. A Raspberry Pi 3 with 1GB RAM can comfortably run Femtobot, while traditional Python frameworks often struggle or require careful dependency management to fit in similar environments.

The 35x reduction in disk footprint compared to typical Python setups matters beyond just storage costs. Smaller binaries mean faster container builds, quicker deployment cycles, and reduced attack surface. Teams managing dozens of bot instances across multiple servers see meaningful infrastructure savings when each deployment drops from half a gigabyte to 10MB.

Rust’s memory safety guarantees also eliminate entire classes of runtime errors common in long-running bot processes. Bots that need to maintain uptime for weeks or months benefit from the language’s prevention of memory leaks and data races without garbage collection pauses.

The project demonstrates that modern AI tooling doesn’t require heavyweight frameworks. Developers building custom automation, internal tools, or experimental agents gain a viable alternative to the Python ecosystem’s default assumptions about acceptable resource consumption.

Getting Started

Building Femtobot requires a Rust toolchain and takes just a few commands:

The compiled binary appears in target/release/ and runs standalone without additional dependencies. Configuration happens through environment variables for API keys and bot tokens.

The repository at https://github.com/enzofrasca/femtobot includes example workflows showing how to wire up tool execution and memory persistence. Developers familiar with Rust can extend the tool set by implementing additional handlers in the main execution loop.

For Telegram integration, the bot uses polling rather than webhooks, simplifying deployment on networks where exposing public endpoints proves difficult. This design choice works particularly well for personal projects and internal tools running behind firewalls.

Context

Python frameworks like LangChain and LlamaIndex dominate the chatbot ecosystem, offering extensive integrations and active communities. These frameworks excel at rapid prototyping and provide pre-built components for common tasks, but their dependency trees grow quickly as projects add capabilities.

Femtobot trades ecosystem breadth for resource efficiency. Teams needing extensive third-party integrations or frequent framework updates may find Python options more practical despite the overhead. The Rust implementation shines when deployment constraints matter more than feature velocity.

Other lightweight alternatives exist in different languages. Go-based frameworks offer similar binary size advantages with simpler concurrency models, while Node.js bots can achieve reasonable footprints using bundlers. Femtobot’s vector storage integration and agent workflow patterns differentiate it from simpler webhook handlers.

The framework’s current limitations include less mature tooling around prompt engineering and fewer pre-built integrations compared to established Python libraries. Developers should expect to implement custom tool handlers for specialized use cases rather than finding ready-made solutions.

For production deployments requiring high availability, teams will need to add their own monitoring and restart logic around the binary, as the framework focuses on core bot functionality rather than operational concerns.