nanoGPT is now a readable artifact, not Karpathy's current stack
The first useful sentence in nanoGPT's README is its November 2025 update: the repository is old, deprecated, and retained for posterity, while new users probably want nanochat. That changes how the code should be judged. nanoGPT remains a compact implementation of GPT training and sampling, but it is no longer the author's recommended foundation for a new project. Treat it as a study aid or a pinned experimental baseline.
The appeal is still obvious in 26 files and roughly 1,235 lines of source. The README describes train.py as an approximately 300-line training loop and model.py as an approximately 300-line GPT definition. Those two files cover training from scratch, fine-tuning, checkpoint loading, distributed execution, and sampling without hiding the model inside a large abstraction layer. A developer can read the path from tokens to loss and then alter it directly.
The smallest example teaches the loop by shrinking the model
The quick start prepares a 1 MB Shakespeare text file, trains a character model, and samples from the saved checkpoint. Its supplied GPU configuration uses 6 Transformer layers, 6 heads, 384 feature channels, and a context of 256 characters. The CPU command cuts those settings to 4 layers, 4 heads, 128 embedding dimensions, a 64-character context, and a batch size of 12. The point is access to the machinery, not competitive language output.
Moving beyond that tutorial means bringing the missing pieces yourself. OpenWebText preparation uses Hugging Face Datasets, GPT-2 checkpoint loading uses Transformers, and tokenization uses tiktoken. Weights, generated dataset binaries, experiment logs, and checkpoints sit outside our measured 37 MB environment. The repository does not provide a chat interface, request server, safety layer, model registry, or deployment chart. It gives you readable training code and assumes you can build the rest of the experiment around it.
What happened when we ran it
Our sandbox installed 35 Python packages in 32 seconds, occupying 37 MB on disk. Building commit 3adf61e then succeeded in 21 seconds. The checkout itself was 0.6 MB, with 26 files and about 1,235 source lines. Pip-audit reported 0 known vulnerabilities in the installed dependency set. These results cover repository setup, not a model-training run or downloaded weights.
There was no test script or target, so we skipped the test step. Our scan also found no tests directory, no Dockerfile, and 0 CI workflow files. That absence matters more than a passing import check would: changes to sampling, data preparation, checkpoint compatibility, or distributed behavior do not have a repository-owned suite that a new user can run from this checkout. Anyone modifying the code should add a small local regression set for the exact path being changed.
The successful 21-second build says the pinned commit was syntactically and structurally usable in our Python 3.12 Debian image. It does not confirm CUDA execution, Apple MPS, multi-node training, dataset preparation, GPT-2 weight downloads, numerical reproduction, or generated-text quality. None of those workloads ran in the supplied lab block, so they should be evaluated separately on the intended hardware.
The documented GPT-2 recipe requires serious hardware
For its larger reproduction, the README specifies a 124M-parameter GPT-2 model on one node with 8 A100 GPUs, each carrying 40 GB of memory. It describes a roughly 4-day OpenWebText run through PyTorch Distributed Data Parallel. Those are the project's figures, not results from our sandbox. They show why nanoGPT's tiny checkout should not be confused with a cheap full training job.
Single-GPU and multi-node paths are exposed as direct command-line settings. The multi-node example expects the operator to provide ranks, addresses, ports, and an interconnect that can keep up. The README warns that a setup without InfiniBand may crawl and suggests changing an NCCL setting. This is useful honesty, but there is no scheduler, cluster provisioning layer, recovery service, or experiment database. The person running it owns all of those operational decisions.
PyTorch compilation and memory limits remain hands-on
The default path uses PyTorch compilation. The troubleshooting section says that torch.compile may not be available on every platform, naming Windows, and recommends --compile=False when it fails. CPU users must also choose --device=cpu; Apple Silicon users can select --device=mps. Fine-tuning runs can exhaust memory, in which case the README suggests reducing model size or context length.
That directness is part of nanoGPT's educational value. Configuration is applied through Python files and command-line overrides rather than a framework with compatibility checks. It also means error handling depends heavily on PyTorch and the local machine. With no automated tests in our 2026 checkout, a dependency upgrade can change compilation, checkpoint loading, or sampling behavior without an obvious project-level alarm. Pin the environment when reproducing old results.
Community interest continues after maintainer development stopped
GitHub showed 62,509 stars and 352 combined issues and pull requests. The repository's last push was November 12, 2025, and GitHub returned no latest release. Open pull requests were still receiving updates in August 2026, including proposals around greedy decoding at temperature 0 and inference-time evaluation mode. That is community activity around the code, not evidence that the deprecated main branch has resumed active development.
nanoGPT remains worth reading because its limited surface makes GPT training inspectable. The 32-second install lowers the cost of opening the code and trying the small example. For maintained training work, follow the README to nanochat or choose a toolkit with current tests and recipes. For teaching, debugging an older experiment, or learning what a GPT loop actually does, the deprecated repository still has a clear job.