fast-crewai vs CrewAI: 34× faster serialization
fast-crewai is a Rust+PyO3 layer for CrewAI, the role-based multi-agent framework. Same Python API; Rust serialization, tool dispatch and knowledge store.
$ pip install fast-crewai fast-crewai is a Rust-backed drop-in for
CrewAI. Same API, faster hot paths.
Install: pip install fast-crewai.
34× faster agent serialization (10ms vs 340ms, typical 5-agent crew).
fast-crewai vs CrewAI: the facts
34× faster agent serialization (10ms vs 340ms, typical 5-agent crew).
Pure-Python pydantic-based serializer; allocates a Python object for every agent field.
Zero code changes: `import fast_crewai` before `import crewai`.
Direct Python import.
MIT licensed, prebuilt wheels, Python 3.9+.
MIT licensed.
Benchmarks
Reproduction instructions in the project README. Numbers measured on AMD Ryzen 9 7950X, 64GB DDR5, NVMe SSD, Python 3.12.
| Metric | fast-crewai | CrewAI |
|---|---|---|
| 5-agent crew serialization | 10ms | 340ms |
Where the time goes in a CrewAI run
A crew step is mostly waiting on a model, and that part of the clock does not move. What fast-crewai targets is the work CrewAI does around the call: turning agent, task and tool objects into a serialisable form, dispatching a tool invocation, and reading from the embedded knowledge store. On a small crew that overhead is noise. On a crew with several agents and a large shared context it becomes a measurable share of each step, and it is paid again on every step.
The 34× figure quoted above is the serialisation path on a five-agent crew, not the end-to-end run. A run dominated by model latency will show a much smaller overall change, and we would rather say that here than let a reader infer a 34× crew. The rule of thumb is that the win scales with how many agents, fields and tool definitions have to be serialised per step.
What stays exactly the same
fast-crewai does not fork CrewAI and does not define its own agent model. Crews, roles, tasks, delegation, custom tools and the knowledge store are declared exactly as before. Integration is one import placed ahead of the CrewAI import, and removing that line restores the pure-Python path with no other change.
That constraint is deliberate and is applied across the accelerator family: a compatibility shim that requires you to rewrite anything has failed at the thing that makes it adoptable. The reasoning is set out in drop-in compatibility as a design principle.
Where CrewAI alone is the better answer
If your crew has one or two agents, serialisation is already cheap and adding a native extension buys nothing while adding a dependency. If you are pinned to a CrewAI version outside the tested range, the shim will detect the mismatch and fall back, so you carry the install for no benefit. And if your bottleneck is prompt size or retry behaviour rather than framework overhead, the honest diagnosis is in the GIL ceiling in Python AI frameworks — profile before you install anything.
When to use fast-crewai
- You run CrewAI crews with 5+ agents and serialization is in the hot path.
- You want a 10-30× win with zero code changes.
- Your crew carries a large shared context or many tool definitions, so every step re-serialises a lot of state.
When NOT to use fast-crewai
- You only run 1-2 agent crews and serialization is negligible.
- You are pinned to a CrewAI version outside the tested range — the shim will detect it and fall back, so you gain nothing.
- Your bottleneck is model latency or retries rather than framework overhead. Profile first.
Frequently asked questions
Does fast-crewai work with all CrewAI features?
Yes. The acceleration applies to the serialization layer (the bottleneck) and the tool dispatch path. Role-based orchestration, task delegation, and the knowledge store all work as normal.
Will my custom tools and agents work with fast-crewai?
Yes. fast-crewai is a drop-in; it does not change the API for defining agents, tasks, tools, or crews.
Does fast-crewai change my CrewAI version?
No. It sits beside the CrewAI you already have, detects the version it finds, and patches only the paths it recognises. If the version is outside the tested range it does nothing and the pure-Python implementation runs.
How do I confirm the accelerated path is active?
The package exposes what it patched at import time, and the acceleration can be disabled entirely without uninstalling. Checking both is the fastest way to attribute a behaviour change correctly.