Litho (deepwiki-rs): C4 Architecture Docs Generated From a Rust Codebase Scan
Turn code into clarity. Generate accurate technical docs and AI-ready context in minutes—perfectly structured for human teams and intelligent agents.
At a glance
- What is it?
- Litho is a Rust CLI that scans a repository, feeds the structure to an LLM, and writes C4-model architecture documentation. It is aimed at teams who want architecture docs regenerated on commit rather than maintained by hand, and its docs already point users toward a successor project called Terrain.
- Who is it for?
- Adopt Litho if you want C4 context, container and component documents produced from an existing repository and you are willing to supply and pay for an LLM API key. Do not adopt it if you need documentation that stays correct without review, or if your codebase is in a language outside the supported set.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The documentation drift problem Litho targets
Architecture documents decay because writing them is a separate task from changing code. A team updates a service boundary, ships it, and the container diagram still shows the old one. Litho's pitch is that the diagram should be produced from the code rather than maintained beside it. The README frames the before-and-after directly: manual documentation is described as outdated, inconsistent and usually just a few markdown files, while the generated output is presented as always up to date with code changes and structured around the C4 model.
The intended audience is stated plainly: development teams of all sizes, open source projects, enterprise software developers, and, in the README's own words, anyone who hates maintaining outdated docs. The tool is a Rust binary distributed through crates.io, and the repository topics list claude, deepseek, mistral, openai and openrouter, which tells you the design assumes an external model provider rather than a bundled one.
One thing to keep in mind before reading further: the README carries a notice that Litho has evolved into a separate project called Terrain, and that Litho stays the fast, focused C4 doc generator. That sentence does more work than any feature list. It means the maintainer has already drawn a boundary around this tool, and anyone evaluating it should read the notice as part of the product, not as marketing noise.
How the pipeline turns source files into C4 layers
The mechanism described in the README is a scan-then-generate pipeline. Litho analyzes source code, extracts comments, structures and relationships, and then produces documentation organized into C4 levels: context diagrams, container diagrams, component diagrams and code-level documentation. The extraction step is the part that matters, because the quality of the generated diagrams depends on what the scanner can recover from the repository: package boundaries, module dependencies, and whatever the code comments say about intent.
There is a second input path that is easy to miss. The advanced features list an external knowledge integration mode, where external documentation in formats including PDF, Markdown and SQL can be mounted as knowledge sources for the analysis. That changes the shape of the pipeline: the model is not reasoning over code alone, it is reasoning over code plus whatever reference material you attach. For a project with a database schema in SQL or a design document in PDF, that is the difference between a diagram inferred from naming conventions and one grounded in a stated design.
The output is customizable through a template system, so the generated documents are not fixed to one layout. The README does not spell out the template format or where templates live, and I could not confirm those details from the supplied material. Treat template customization as a capability the project claims rather than a documented workflow until you check the docs directory.
Providers, languages and the configuration surface
The provider list is visible in two places: the repository topics name claude, deepseek, mistral, openai and openrouter, and the README's feature list claims multi-language support covering Rust, Python, Java, Go, C#, JavaScript and others. The word others is doing a lot of work there. If your repository is mostly one of the named languages, the scanner has a stated path through it. If it is not, the honest position is that the README does not tell you what happens, and the only way to find out is to run it on your code.
The README excerpt supplied here does not include the installation or invocation commands, and I am not going to invent them. What can be confirmed is the distribution channel: the crates.io badge links to the deepwiki-rs crate, so a Rust toolchain and a cargo install of deepwiki-rs is the expected acquisition route, with the exact subcommands and flags documented in the project's docs/en and docs/zh directories, which the README links to directly. Configuration for the model provider is the part you should read first, because the tool has no bundled model and every generation run depends on an API key and an endpoint you supply.
Because the provider set includes OpenRouter, the practical configuration question is not which vendor you prefer but which model you can afford to run over a full repository scan. A large codebase means many extracted fragments in the prompt, and the cost scales with repository size in a way that a small demo repository will not reveal.
Where the generated documentation will let you down
The central limitation is that generated architecture documents are plausible, not verified. Litho extracts structure and relationships, and the model writes prose around them, but nothing in the described pipeline checks the output against a human who knows the system. A container diagram that omits a queue because the queue is configured outside the repository, or a component boundary drawn along directory lines rather than actual ownership, will read exactly as confidently as a correct one. The README's claim that documentation stays in sync with code changes is true at the level of regeneration and false at the level of correctness.
The second limitation is scope. The tool is positioned as a C4 doc generator, and the README's own notice says the broader ambitions (knowledge base syncing with code, wider language and framework support, agent consumption over ACP) belong to Terrain. So if what you actually want is a living knowledge base that coding agents read, this repository is the wrong entry point, and the README says so.
Third, the external knowledge integration is only as good as the material you mount. A stale PDF becomes a stale diagram with better formatting. And the multi-language claim, as noted, has an unenumerated tail. For a polyglot repository with a significant amount of code in an unnamed language, the generated context and container layers may be built on partial extraction, and the document will not warn you.
Litho against Structurizr and hand-written C4
The obvious alternative is Structurizr, the DSL-based approach to C4. The difference in approach is where the source of truth lives. With Structurizr you write the model as code, in a DSL, and the diagrams are rendered from that model; the model is authoritative and the diagrams follow. Litho inverts this: the code is authoritative, and the model is inferred from it. That inversion is the whole value proposition and also the whole risk. A Structurizr workspace cannot silently invent a component, because a human wrote every element. A Litho run can.
The second alternative is simply writing the C4 documents by hand in Markdown and reviewing them in pull requests. That is slower and it drifts, which is the problem Litho exists to address. But it has one property Litho cannot claim: every statement in it was asserted by someone who understood the system.
The practical split is by document type. Context and container diagrams, which describe the system at a level the code already encodes, are where Litho's inference is most likely to be right and where regeneration is most valuable. Component and code-level documents, which depend on intent and conventions, are where a human-authored model or a reviewed draft still wins. Treating Litho as a first-draft generator for the upper C4 layers rather than an authority for the lower ones matches what the described pipeline can actually support.
Licence, releases and what maintenance looks like
The repository is MIT licensed. That is permissive: you can use, modify and redistribute it, including in commercial settings, provided the licence terms are met. This is not legal advice, and if you are embedding the tool in a product or a regulated pipeline you should have someone review the MIT text and, separately, the terms of whichever model provider you point it at. The provider terms are the ones that usually matter, because the code is the small part of the dependency graph here.
The release history supplied shows 1.5.0 in April 2026, 1.3.0 in March 2026 and 1.2.8 in February 2026, with the last push to the default branch in August 2026. That cadence suggests active work rather than a frozen project, but it also means the CLI surface can move between minor versions. Pin the version you install rather than tracking latest, and read the release notes for 1.5.0 before upgrading an existing pipeline.
The maintenance cost that is easy to underestimate is not the binary, it is the review. Every generated document needs a human pass before it is trusted, and that pass recurs on every regeneration. If you wire Litho into CI and publish the output without review, you have automated the production of documents that may be wrong. The upgrade cost is the smaller line item: a cargo install, a provider configuration, and whatever template adjustments your custom templates need when the output format changes.
Who should run Litho, and what to check first
Run it if you have a repository in one of the named languages, you already have an LLM provider account, and you want C4 context and container documentation that regenerates instead of rotting. The external knowledge integration is the feature worth testing early, because mounting a SQL schema or a design PDF is where the output stops being a restatement of directory names.
Do not run it if you need the lower C4 layers to be authoritative without review, if your codebase is largely outside the supported languages, or if what you actually want is the agent-facing knowledge base that the README says lives in Terrain. In that last case the maintainer has already told you where to go.
The verification order is short. First, confirm your repository's language mix against the README's list and decide whether the unenumerated remainder is acceptable. Second, read the docs directory for the actual install and invocation commands and the provider configuration keys, since the README excerpt does not carry them. Third, run it once on a repository you know well and diff the generated container diagram against your mental model. If that diff is mostly cosmetic, the tool is doing its job. If it misses an entire external dependency, the scanner is not seeing something it needs to see, and no amount of prompt tuning will fix a gap at the extraction layer.
Editorial conclusion
Adopt Litho if you want C4 context, container and component documents produced from an existing repository and you are willing to supply and pay for an LLM API key. Do not adopt it if you need documentation that stays correct without review, or if your codebase is in a language outside the supported set. Before committing, verify which languages your repository actually uses, which provider and model you will point it at, and whether the README's own pointer to Terrain changes your maintenance plan.
Community notes