Own project
2026 · Flagship · Open source
Cerberus AI
A cross-language agent runtime: a Python API bridged into a C/C++ execution core, so a long-running agent session holds a flat memory profile instead of a sawtooth. This is the architecture, the measurements, the method behind them, and what is still wrong with it.
- Built
- 2026
- Languages
- C++17 · C11 · Python 3
- Bridge
- Pybind11
- Cold-start RSS
- 208 MB
- Formerly
- IronAgent
01Architecture & measurements
Execution path
A single agent step, from Python call to arena write.
The GIL is released across the bridge, so the C++ loop and Python callers do not serialise
on each other. Everything below the bridge allocates out of the arena. No per-step
malloc traffic. No garbage collector to pause the session.
Measurements
Cold-start resident memory, Cerberus versus LangChain on the same task.
Cold-start RSS, lower is better. Same task, same machine, measured at process steady state after first agent step.
Method & caveats
Numbers were taken on my own Linux workstation, not a controlled lab. RSS was sampled after the first completed agent step so that lazy imports and model client initialisation are included on both sides. Allocation and prune timings are medians over repeated runs inside a warmed process. They are directionally reliable and I can reproduce them on request. But they are single-machine figures, and I would not present them as vendor benchmarks.
What's still wrong with it
The roadmap, stated plainly.
The FFI boundary is the ceiling
Pybind11 copies at the Python↔C++ boundary. Once the core got fast, that copy became the dominant cost in the hot path. The arena wins are partly spent crossing back out. Profiling shows it clearly, and it is documented rather than hidden.
Zero-copy buffers for v1.1
Moving the boundary to the Python buffer protocol so large tensors and context blocks are viewed rather than copied. The arena is already aligned for it; the work is in lifetime management across the boundary.
Single-node by design, for now
Cerberus orchestrates on one machine. Distributing the loop means solving state handoff and partial failure. That is real distributed-systems work, not something to bolt on to claim a feature.
02How the evaluation work connects
Cerberus is one half of the same problem. The other half is designing the adversarial problems and harnesses that decide whether generated code is actually correct - the work below runs alongside it, and each side informs the other.
-
01
Design the adversarial problem
Multi-step Python problems and edge-case scenarios built to expose failures in reasoning, context-window management and logic execution. Not trivia. Work a competent engineer would still have to stop and think about.
-
02
Sandbox the runtime
Test environments and execution runtimes containerised in Docker, so model-generated code runs isolated and reproducibly against strict unit-test suites that decide pass or fail without a human in the loop.
-
03
Evaluate and rank
Output in Python, C++ and C debugged and ranked on time/space complexity, memory leaks and production coding standards. Chain-of-thought traces get audited too, for logical fallacies and improper library usage.
-
04
Automate the regression
Local Python drivers inside those containers automate prompt evaluation, regression testing and hallucination detection across model checkpoints. A behaviour fixed in one release should not quietly regress in the next.
Coding agents, compared
Benchmarked head-to-head on complex systems tasks.
- Claude Code
- Gemini CLI
- Cursor
- GitHub Copilot
- ChatGPT / Codex
The question is never which one feels faster. It is which one still holds up when the task has concurrency, memory ownership or protocol state in it. That only shows up in correctness and scalability numbers.
Review at volume
What 270+ reviewed solutions looks like in practice.
Concurrency bugs, race conditions, memory-management defects and architectural tradeoffs across OS, networking and infrastructure code. Plus written documentation on the debugging workflows behind the findings.