How to Generate Architecture Documentation (C4) from Your Code with deepwiki-rs

deepwiki-rs generates architecture documentation from your code: it uses AI to convert a project’s files into C4 explanations and diagrams.

The project is presented as Litho, although the package and command retain the name deepwiki-rs. It’s a tool written in Rust, licensed under MIT, that addresses a common problem: understanding how the pieces of a repository fit together when its documentation is incomplete.

If you’ve just joined a project or are preparing a handover, the result can serve as a starting point for review, correction, and sharing. Official Repository

What documentation does deepwiki-rs generate?

Litho produces architecture documentation about the system, its modules, workflows, and interfaces, with diagrams expressed in Mermaid.

Its process traverses the project, analyzes the code with the help of language models, and organizes the results into documents. It can also incorporate existing material, such as architecture decisions and database schemas, to add context that the code files alone don’t explain. Project Documentation

That last point matters. Code can show that a service uses a queue. An architecture decision record can explain why the team chose asynchronous processing. A useful system description needs both.

What is the C4 model and what is it for?

The C4 model organizes architecture into successive levels of detail: system context, containers, components, and code.

The context view places the system among its users and external dependencies. The containers view identifies applications and data stores; here, “container” doesn’t necessarily mean Docker. The components and code views allow you to examine smaller parts of the design.

You don’t need all four levels in every project. The official C4 guide allows you to use the levels that provide value. C4 Diagrams Guide

In a first review of the generated documentation, start with the system boundaries and its main applications. If that’s wrong, the more detailed diagrams will only develop the error.

How to install deepwiki-rs?

The documented installation method uses Cargo:

cargo install deepwiki-rs

There is a discrepancy in the requirements worth detecting before you start. As of September 14, 2026, the README indicates Rust 1.70 or later, but the project’s current manifest uses Rust edition 2024, introduced with Rust 1.85. Dependencies might require an even newer compiler. Therefore, the minimum indicated in the README is not sufficient to compile the current code. Project Manifest, Rust editions guide

The commands in this guide were verified against the repository’s documentation and code; we have not completed an installation or generation run for this note.

What do you need to generate documentation with deepwiki-rs?

You need a repository to analyze and a language model provider set up to use it with Litho.

The project includes a sample configuration file designed to be copied as litho.toml. It contains the provider selection, the API base URL, authentication, and separate model choices for routine analysis and more demanding reasoning.

Select models that your provider currently has available, rather than copying the old identifiers from the example without changes.

Running the CLI on your computer doesn’t mean that inference stays there. The configuration supports remote providers and Ollama. The chosen provider determines where model requests are sent; using an external API may incur charges. Configuration Implementation

Start with a small repository that you’re authorized to process with that provider. This will let you better evaluate the first run and observe consumption before expanding the scope.

How to use deepwiki-rs to document a repository?

Once the provider is set up, tell Litho which project to analyze and choose an output directory:

deepwiki-rs --target-language en -p ./my-project -o ./docs

Replace ./my-project with the path of the repository you want to analyze. The command explicitly selects English and directs output to ./docs; these options are present in the CLI implementation. CLI Code

For those working in Spanish there is a limitation: as of September 14, 2026, Spanish does not appear in the documented list of output languages. This walkthrough uses the documented English option.

Choose a separate output directory for the test so you can review the generated material before incorporating it into the documentation you maintain.

How to review architecture documentation generated by AI?

Check whether the documents describe the system you actually use.

Choose a workflow you know well — authentication, placing an order, or running a background task — and follow it using the generated explanation. Compare the components, dependencies, and boundaries it mentions with the source code.

Then look for three types of errors:

  • Invented intent: a plausible explanation of a design decision that no one documented.
  • Missing context: infrastructure, external services, or operational behavior that don’t appear in the analyzed repository.
  • Misleading diagrams: relationships that look convincing at first glance but point in the wrong direction or cross an incorrect boundary.

These are review criteria, not defects measured in a Litho test. It’s what you’d check to decide if the result is useful enough to keep.

Claims of accuracy and time savings should be presented as project assertions until you’ve evaluated them with your own code.

How to update documentation when code changes?

Assign an explicit place for regeneration and review within your workflow.

The released version 1.6.0 includes controls to skip stages of the process and force regeneration. Its existence doesn’t demonstrate that a generated document continuously tracks all subsequent changes. Release Notes

Record which commit describes each run. When architecture changes, regenerate the corresponding material and review the differences alongside the code.

As of September 14, 2026, the project distinguishes the generation of Litho documents from Terrain, which it presents as a broader environment for maintaining knowledge that agents can consult. That distinction helps you decide which of the two projects to evaluate. Project Presentation

When is it worth trying deepwiki-rs?

It’s worth evaluating when you need a structured architecture draft for a repository you can verify.

Our Repomix guide covers how to prepare a repository’s context for an AI. Litho handles the next editorial work: organizing an interpretation of the code into documents.

Start with a project and workflow you know. If the generated explanation helps another developer find the right components and you can fix its errors without rewriting everything, you have a useful foundation for a documentation process.