cersei: two startup numbers, 77,000x ratios that measure a model call, and nine crates drawn out of twenty

The same startup and binary size are quoted twice with different values

The comparison table at the top puts Abstract CLI startup at roughly 34ms with a binary and resident size of 5.8MB and 4.9MB. Four sections later, the benchmark table gives startup (warm) as 32ms, binary size as 6.0 MB and memory (RSS) as 4.9 MB. So resident size agrees and the other two do not: 34ms against 32ms, and 5.8MB against 6.0MB. The benchmark table says its numbers come from `run_tool_bench.sh --full` and points to `crates/abstract-cli/benchmarks/REPORT.md` for the full run. Nothing on the page names the hardware, the operating system, or the build profile behind either table, and those are exactly the variables that move startup and size figures. Whichever number you cite, cite the report rather than the summary table.

The 77,000x and 689,000x ratios compare a lookup against a model call

The memory rows are the headline. Memory recall is given as 98 microseconds against 7,545 milliseconds, a factor of 77,000, and memory write as 30 microseconds against 20,687 milliseconds, a factor of 689,000. The footnote explains what sits on the other side of that comparison: memory recall in the competing CLI calls a model every turn to rank the top five files by relevance, measured at 7.5 seconds, while the graph does indexed lookups with no model call and no API cost. The arithmetic is right, and the comparison is thin, because it measures the cost of a model round trip rather than any difference in ranking quality. Two rows are closer to like for like, since startup, binary size, resident memory and sequential throughput compare two programs doing the same job. If you are choosing on the numbers, weight those four and read the memory ratios as a statement about token spend.

The architecture diagram draws nine of twenty workspace crates

The layout section names the facade crate and eight others: `cersei-types`, `cersei-provider`, `cersei-tools`, `cersei-tools-derive`, `cersei-agent`, `cersei-memory`, `cersei-hooks` and `cersei-mcp`. The workspace manifest lists twenty members. The ones missing from the diagram are `cersei-lsp`, `cersei-embeddings`, `cersei-compression`, `cersei-skills`, `cersei-vms`, `cersei-agentlang`, `cersei-agentrl`, `cersei-workflows`, `cersei-tbench`, `abstract-cli` and `bench/long-mem`. That list includes skills, which the opening paragraph promises and the comparison table claims support for in both the Claude and the skills directory formats, so the feature is real and its crate is simply not drawn. The manifest also carries `exclude = ["examples/benchmark"]`, and an `examples/benchmark` directory sits in the tree, so the benchmark that produces the comparison numbers is deliberately outside the workspace build. The facade crate is the one you are meant to depend on, and the install snippet confirms that, since it pulls `cersei` rather than any of the parts. The manifest also excludes that benchmark directory while still listing `bench/long-mem` as a member, so the workspace contains two separate benchmark shapes: one compiled with the project and one kept out of it.

The derive note names a dependency that does not exist

The sentence introducing the custom tool macro says it generates code with `#[async_trait::async_trait]` and `cercei-tools`, and tells you to add both to your project. The workspace contains `crates/cersei-tools`; `cercei-tools` transposes the letters and does not resolve. The toml snippet directly beneath gets it right, listing `async-trait = "0.1"`, `cersei` and `cersei-tools = { path = "path/to/cersei/crates/cersei-tools" }`. The sentence also says add both while the snippet lists three entries, and offers an alternative in the form of a `use` alias. Copy from the snippet. The worked example itself is compact: a `#[derive(Tool)]` on a unit struct carrying `#[tool(name = "search", description = "Search docs", permission = "read_only")]`, then a `ToolExecute` impl whose `Input` type derives Deserialize and JsonSchema, returning `ToolResult::success`.

The install snippet pins no version, and there are no releases to pin

Adding the SDK is a git dependency with nothing on it:

[dependencies]
cersei = { git = "https://github.com/pacifio/cersei" }
tokio = { version = "1", features = ["full"] }
anyhow = "1"

No version, no revision, no tag, so a build tracks whatever the branch head happens to be on the day it resolves. The workspace manifest records version 0.2.6, edition 2021, and licence MIT, and a CHANGELOG.md is in the tree, but the repository publishes no GitHub releases at all. Graph memory is optional and behind a feature flag, enabled as `features = ["graph"]` on the memory crate. The CLI's only documented install is by path from a checkout you already have, `cargo install --path crates/abstract-cli`, so the same pinning question applies there. Record the commit you built against.

A DNS resolver flag exists because static musl builds fail silently

The most telling comment in the manifest is attached to the HTTP dependency. Reqwest is pinned at 0.12 with the `json`, `stream`, `rustls-tls`, `rustls-tls-webpki-roots` and `hickory-dns` features and `default-features` off, and the note says the pure-Rust resolver is required for fully static musl binaries because the default getaddrinfo path fails with no NSS present, which silently breaks every outbound API call. For an agent whose entire job is making API calls, a silent break on the first request is the worst shape a failure can take, and the fix is a resolver that does not need the host resolver at all. Elsewhere the runtime choices are tokio 1.44 with full features, tokio-util 0.7, anyhow 1, thiserror 2, serde 1 with derive, and toml 0.8. The manifest listing stops partway through the logging section.

Three URLs for the docs, and MIT over a reverse-engineered design

The footer links documentation at `https://cersei.pacifio.dev/docs`. The repository homepage field records `https://cersei.tryatlas.cc/docs/`. The manifest sets `homepage` to the GitHub URL. Three answers to where the docs live, and only one of them is inside the project. The provenance line is worth reading plainly too, since the page says Cersei is built from the architecture of Claude Code as a reverse-engineered Rust port. The MIT licence covers this code; it says nothing about the design it was derived from, which matters if you intend to publish a fork. The comparison table frames the same relationship commercially, putting Claude Code and OpenCode by name in the same grid as this SDK and the Abstract CLI, and the manifest lists a single author. Two loose ends sit on the same page. The feature list names auto-dream with no definition anywhere around it, and the closing section on sub-agent orchestration gets a single line, about spawning parallel workers and passing messages between them, before it stops.

Editorial conclusion

cersei is worth reading for the parts the author was precise about, which are the dependency choices: a pure-Rust DNS resolver added specifically so a static musl build does not fail silently on every outbound request, an optional graph feature behind a cargo flag, and a provider trait that takes a base URL so Ollama, Azure and vLLM fit the same shape. Be more careful with the comparison section, where the same startup and binary figures appear twice with different values and the largest ratios compare an index lookup against a language model call. Install the SDK from a pinned git revision rather than a branch head, count the tools yourself before you plan around thirty-four, and treat the architecture diagram as nine of twenty crates rather than the whole layout.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. pacifio/cersei on GitHub
4. Project website
5. README