The last release is from 2023 and the current code requires Python 3.12

Three years separate the newest release from the current source

The three most recent tags are 1.7.1 from September 2022, 1.7.2 from February 2023, and 1.8.0 from May 2023. The last push to the branch is dated 2026-09-30. So the repository is three years and four months past its last release, and it is not archived.

What makes that gap matter is what changed underneath it. The documentation says the project currently supports Python 3.12 and newer with PyTorch 2.11 and newer, and the packaging agrees on the floor by requiring 3.12 or later, with classifiers for 3.12, 3.13 and 3.14. A 2023 release cannot have declared those floors, because those Python versions did not exist then. Older torchinfo releases support Python 3.8 and PyTorch 1.4, the documentation adds, and fixes are no longer backported to them.

So installing by version and installing from the branch give you two different tools, and the one you get by default from a package index is the one written for the older environment.

The entry point takes fourteen arguments and absorbs any typo

The summary function is documented with its whole signature, which is unusual and useful.

def summary(
    model: nn.Module,
    input_size: INPUT_SIZE_TYPE | None = None,
    input_data: INPUT_DATA_TYPE | None = None,
    batch_dim: int | None = None,
    cache_forward_pass: bool | None = None,
    col_names: Iterable[str] | None = None,
    col_width: int = 25,
    depth: int = 3,
    device: torch.device | str | None = None,
    dtypes: list[torch.dtype] | None = None,
    mode: str = "same",
    row_settings: Iterable[str] | None = None,
    verbose: int | None = None,
    **kwargs: Any,
) -> ModelStatistics:

The shape is the interesting part. Only the model is required. You can describe the input as a shape or hand it real data, and five more parameters default to None with the behaviour inferred rather than demanded. Depth defaults to 3, which is why a deep network prints as a truncated tree, and column width defaults to 25.

The catch is the trailing catch-all. Any keyword you misspell is accepted and ignored, so a wrong option name produces a table that is missing the thing you asked for and no error at all. Read the parameter list once before you trust it.

In a notebook the call has to be the last expression or nothing prints

There is one behaviour in this library that surprises people, and it is documented in a single sentence: if you are in a Jupyter Notebook or Google Colab, the result of the summary call must be the returned value of the cell. If it is not, you have to wrap the call in a print function instead.

That is a property of notebooks rather than of this library, since a notebook displays the value of the last expression and nothing else. But the surprise lands on the library, because the same line of code prints in a script and prints nothing in a notebook. The documentation points at a notebook of examples in the tests directory for exactly this case.

The return type is a ModelStatistics object that carries every field in the summary, so the table is also available as data: you can turn it into a string yourself when you want to log it or embed it somewhere the notebook will not display.

The first sample table does not match the code printed above it

The README pairs each example with the table it produces, and the pairing is done by reference rather than by copy. After the first table there is an HTML comment naming a file, and the same pattern appears after the recurrent example and after the ResNet example, which means the tables are generated from output fixtures kept in the repository and pulled into the page.

That is the right way to keep a table honest, and it still lets a mismatch through when a fixture and its snippet drift apart. In the first example the code sets a batch size of 16 and passes an input shape built from it, while the table immediately below shows a leading dimension of 7 in every row. Nothing reconciles the two numbers, and the snippet also shows a second convolution row with an output shape and no parameter count, which reads as an excerpt rather than a complete run.

So the tables are evidence of real output, but not always of the code printed next to them. Treat a number in a table as illustrative until you have run it.

Column headers change between examples because they are configurable

Three examples appear in the documentation and no two of them print the same table. The first has a layer column, an input shape, an output shape, a parameter count and a multiply-add column. The recurrent example replaces the layer column with one that carries variable names, swaps input shape for kernel shape, and shows the weight row indented underneath its layer. The ResNet example drops both the multiply-add column and the input shape entirely.

None of that is hard-coded inconsistency, because the function takes a column name list and a row settings list, and a mode argument defaulting to same. The variance is the feature: a table can be trimmed to the columns you actually read. But it does mean the documentation has no single canonical layout, so when you compare two of these tables you are comparing two configurations rather than two models.

The multiply-add column is the one piece of arithmetic in the output that the project credits to outside work, naming two contributors who improved the calculation.

torchvision is a required dependency for a tool that mostly reads shapes

The declared runtime dependencies are torch, torchvision and numpy. Two of those are unavoidable for anything that touches a PyTorch model. The third is worth questioning: the package resolves shapes by running a forward pass, and nothing in the documented API needs a vision library, yet the ResNet example in the documentation imports torchvision to build its model.

So the vision library is a hard install requirement for users who pass nothing but a shape and a dense model. It is a small cost against the convenience of the example, and it is the sort of thing that disappears from a lockfile without anyone noticing.

The development dependencies tell a similar story from the other side. Alongside the test runner, the linter, the type checker and the coverage tool, the group pins the build tool below version 84, and it includes a transformer library, which is what lets the test suite exercise architectures beyond the vision examples.

Renamed twice, and both old spellings are still packaging keywords

The project has had two previous names and admits it in one line under the title: formerly torch-summary. The packaging description calls it a model summary based off the original torchsummary, and the documentation is blunter still, describing itself as a completely rewritten version of the original torchsummary and torchsummaryX projects, written by two named authors, and saying it addresses the issues and pull requests left on those projects by introducing a new API.

The keyword list is where the rename history is preserved in full. Alongside its own name it lists torchsummary and torch-summary, so anyone searching for either predecessor still lands here. It also lists the framework name, both capitalisations of its own name, and a spread of terms about visualising layer statistics.

That is a deliberate search decision rather than an oversight, and it is also a small maintenance one: the package has to keep two dead names alive in its metadata so that a decade of blog posts still resolve.

setup.py is three lines, the version comes from an attribute

The packaging is modern with one shim left in place. The project file declares its version dynamically and points the build at an attribute inside the package, so the version string lives in the source rather than in the metadata. Packages are listed explicitly, package data is enabled, and the package ships a typing marker file so that type checkers pick up its annotations.

Alongside all that, setup.py still exists and does nothing except call setup with no arguments. It is the sort of file that exists to keep older install paths working, and its presence alongside the modern configuration is the clearest sign of how the project has been migrated rather than rewritten.

The tooling around it is unusually strict for a package this size. The type checker runs in strict mode with unreachable code warnings, unimported any detection and an error code that forbids bare ignores. The linter selects every rule it has and then disables a documented list, including the docstring rules, the missing copyright notice check and the rule against exceptions built from string literals.

Editorial conclusion

torchinfo remains the most readable model summary for PyTorch and is worth installing if you want shapes, parameter counts and multiply-add figures in one table. Four things to check. Decide whether you can install from the branch rather than the tag, since the newest release targets a Python and PyTorch generation that has since moved twice. Read the parameter list before you rely on it, because the function accepts arbitrary keyword arguments and will not tell you that you misspelled one. In a notebook, make the call the last expression in the cell or wrap it in a print, or you get no output. And if you only need shapes, note that the packaging still requires torchvision as a runtime dependency.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. TylerYep/torchinfo on GitHub