Litho (deepwiki-rs): C4 architecture docs generated from source by an LLM

The gap Litho fills: architecture documents that nobody writes

Most repositories have a README and little else. Architecture knowledge lives in the heads of the people who wrote the code, and when they leave, the context diagram leaves with them. Litho targets exactly that gap. According to the README, it "automatically analyzes your source code and generates comprehensive, professional architecture documentation in the C4 model format." The C4 model is the key constraint here: output is not free-form prose, it is context diagrams, container diagrams, component diagrams and code-level documentation, a fixed hierarchy that maps onto how the tool structures its analysis. The intended audience is stated plainly: development teams, open source projects, enterprise developers, architects and technical leads. That is a wide net, but the practical user is someone who already understands C4 and wants the mechanical part of producing it automated. If you do not already think in C4 terms, the generated documents will look arbitrary rather than useful.

How the pipeline works: scan, extract, then hand off to an LLM

The repository layout tells you more than the marketing copy. Cargo.toml lists walkdir for file traversal, regex for pattern matching, md-5 for hashing, pdf-extract for PDF parsing, markdown for Markdown handling, and rig-core as the LLM abstraction layer, alongside reqwest and tokio for async HTTP. That dependency set describes a three-stage pipeline. First, the tool enumerates source files and filters them, which is what walkdir and glob are for. Second, it extracts structure, comments and relationships, using regex and language-aware parsing; hashing with md-5 suggests change detection or deduplication of analyzed units. Third, it builds prompts and sends them through rig-core to a model provider, then assembles the returned text into C4 sections. The presence of pdf-extract and markdown, combined with the README's mention of "External Knowledge Integration" for PDF, Markdown and SQL sources, means the analysis context is not limited to source code. This is a batch pipeline, not a server: there is no database dependency in Cargo.toml, no web framework, and no queue. Everything is driven by a single invocation against a directory.

Installing Litho from crates.io and running a first generation

The README links the crates.io badge for the deepwiki-rs crate, so Cargo is the documented distribution channel. The package name in Cargo.toml is deepwiki-rs, so install it by that name:

cargo install deepwiki-rs

After installation the executable is available on your PATH. The repository ships a sample configuration file at the top level, litho-example.toml, which is the reference for your own config. Copy it next to the repository you want to document, edit it, and point the tool at it. The README excerpt does not print the exact invocation, so the configuration file and the crate's own help output are what you have to work from. Because generation calls an external LLM through rig-core, expect the run to make network requests and to need provider credentials configured in the TOML file; the README names Claude, DeepSeek, Mistral, OpenAI and OpenRouter in the repository topics, so those are the integrations to look for in the config schema. A first run on a mid-sized repository will take minutes rather than seconds, since each C4 layer is a separate model interaction.

Where Litho breaks down: cost, staleness and the wrong repository shape

The README claims documentation that is "always up-to-date with code changes." That phrasing deserves scrutiny. Nothing in the dependency list or the repository layout shows a watcher, a git hook installer, or a daemon. Updating documentation means re-running the generator, and re-running means paying for the tokens again. On a large monorepo the analysis step is cheap (walkdir and regex) but the generation step is not, because every C4 level is a separate prompt over extracted context. Teams that expect continuous synchronization will need to wire the binary into CI themselves; the README mentions CI/CD integration as a capability but the repository does not document a ready-made workflow file. The second failure mode is repository shape. Litho extracts comments, structures and relationships. A codebase with sparse comments, heavy metaprogramming, or generated code will produce thin or misleading input, and the model will fill gaps with plausible-sounding architecture that does not exist. That is the worst outcome for a documentation tool, because fabricated diagrams are harder to detect than missing ones. Finally, the README now carries a banner stating that "Litho has evolved into Terrain" and that Litho "stays the fast, focused C4 doc generator." Anyone evaluating this for a long-lived documentation program should read that as a scope boundary, not a feature note.

Litho against DeepWiki and against writing docs by hand

The obvious comparison is DeepWiki itself, which the project name references and which generates wiki-style pages for a repository as a hosted service. The difference is control and locality. DeepWiki is a service you point at a repository; Litho is a binary you run yourself, with a TOML configuration, your own API keys, and output you keep. That matters if your code cannot leave your network, if you need the same document regenerated deterministically in CI, or if you want to mount internal PDFs and SQL schemas as extra context, which the README lists as external knowledge integration. The trade-off is that you own the operational work: provider keys, rate limits, prompt quality and output review. The other alternative is a conventional docs-as-code setup with Mermaid or PlantUML diagrams checked in by hand. That approach is slower and drifts, but every diagram is deliberate and reviewable in a pull request. Litho's output is generated, so review means reading prose a model wrote about your architecture. For a stable, small service, hand-written diagrams plus a README may genuinely be less work than configuring and re-running a generator.

Maintenance, licensing and what upgrading costs you

The repository is not archived and the last push was on 2026-08-14, so the project has seen activity within the last several months. Release notes in the repository show 1.5.0 on 2026-04-05, 1.3.0 on 2026-03-10 and 1.2.8 on 2026-02-01. Cargo.toml declares 1.6.0, which is ahead of the newest release note listed, so version numbering between the manifest and the release page is not perfectly aligned; pin the exact version you install and read the changelog for that version rather than assuming the release page is current. Upgrade cost is dominated by two moving parts. The first is rig-core, the LLM abstraction crate, at 0.35 in this manifest; provider APIs change, and a major bump there can alter how models and credentials are configured. The second is the prompt and template layer, since output structure is a product decision that can shift between minor versions. Licence is MIT, which permits commercial and private use, modification and redistribution provided the copyright notice and permission notice are included; that is a permissive, low-friction choice for internal tooling. This is a description of the licence text, not legal advice, and if you redistribute the binary inside a product you should have your own counsel confirm the notice requirements.

Editorial conclusion

Adopt Litho if you want a single-purpose Rust binary that produces C4-shaped architecture documents from a repository and you are comfortable sending code context to an LLM provider. Do not adopt it if you need a documentation system that stays synchronized over time or that agents query directly: the README says the project has evolved into Terrain, and Litho is now described as the fast, focused C4 doc generator. Before committing, verify which LLM providers your configuration supports, check whether the external knowledge sources you need (PDF, Markdown, SQL) are covered, and run the generator against one representative repository to inspect the output structure rather than trusting the feature list.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. sopaco/deepwiki-rs on GitHub