Torlink and the quiet return of the command-line torrent

Andrej Karpathy's llm.c repository is one of the more arresting pieces of code to surface in the AI conversation of the last year. No PyTorch, no CPython, just large language models trained in raw C and CUDA. The project began as a Karpathy weekend exercise to reproduce GPT-2 at the smallest possible layer of abstraction, and it has since crept toward frontier-scale training on consumer hardware. Karpathy himself flagged the project on social media in mid-2025 as the repository's star count crossed into five figures, and the project has only kept growing since.

The lean stack

What makes llm.c genuinely interesting is what it leaves out. The modern machine-learning stack is famously heavy: a Python interpreter sits on top of C extension modules, which sit on top of CUDA kernels, which sit on top of a hardware driver, with several layers of just-in-time compilation in between. llm.c strips that stack back to the bottom two layers. Training loops, optimiser state, mixed-precision arithmetic and tensor reshapes are all written directly in C, with CUDA kernels inlined for the parts that have to run on the GPU.

The result is a binary that a developer can read end to end, that compiles against the NVIDIA toolkit without a Python virtual environment anywhere in sight, and that trains a transformer without anyone involved having to think about what a torch.nn.Module is doing under the hood. It is, in effect, a working implementation of the techniques that the big-lab stacks have spent a decade layering abstractions on top of, presented in a form a competent systems programmer can audit on a weekend.

Why it matters now

The publication that has driven most of the recent attention is Karpathy's own description of the project on social media, where he has been posting regular training-loss charts and benchmarks as the repository has matured. Independent benchmarking from the open-source community has produced comparable numbers: training a GPT-2-scale model on a single high-end consumer GPU in roughly the time that PyTorch with a reasonable configuration would take, with a fraction of the memory footprint. That last point is the one that keeps coming up. PyTorch's eager execution graph and Python overhead impose a tax on memory that llm.c simply does not pay, and for researchers working at the edge of consumer hardware that difference is not academic.

This is also why the project has become a quiet centre of gravity for a particular corner of the AI community: people who want to understand what is actually happening inside a transformer training run, rather than what an API wants them to believe is happening. Several university courses have begun to use llm.c as teaching material for systems-oriented machine-learning classes, on the grounds that the entire training loop fits in roughly four thousand lines of C and can be read in an afternoon.

The wider texture

The timing is not incidental. The same period has seen a parallel surge of interest in small, auditable AI systems, from local model runners to fully self-hosted inference stacks. The conversation around AI safety has hardened, with one recent book-length intervention by Eliezer Yudkovsky and Nate Soares arguing that capable models running on commodity hardware represent an under-examined failure mode. Whether one finds that argument persuasive or not, the existence of a working, readable, end-to-end C implementation of transformer training makes the discussion land differently. The hypothetical "nine GPUs in a garage" is no longer hypothetical at the level of the training loop; the question is whether it is hypothetical at the level of capability, and llm.c makes the technical boundary unusually legible.

There is a commercial subplot as well. Frontier labs have spent the last several years treating their training stacks as competitive advantage, with the result that the canonical implementations of contemporary techniques are often buried inside proprietary repositories. Karpathy's project does not change that, but it does put a clear marker down: the techniques themselves are not magic, they are code, and the code can be written by one person in a spare-time project without institutional backing.

The Torlink question

This is where the title comes from, and where the analogy earns itself. Torlink is a small, self-hosted tool that surfaces .onion links and magnet URIs through a terminal-first interface. It is not, on its own, a particularly interesting piece of software. It is the kind of utility that gets a handful of stars on GitHub, gets mentioned in two or three forums, and gets forgotten.

What is interesting is the pattern. Torlink does for finding torrents what llm.c does for training transformers: it removes the platform layer. No web frontend, no account system, no algorithmic ranking, no moderation queue, no terms-of-service boilerplate. You install it, you point it at a tracker, it does its job. The user is responsible for what they do with it, and the developer is responsible for what the code does, and that is the whole contract. It is a deeply unfashionable design philosophy in 2026, where every useful tool has been folded into a platform with identity, telemetry, and a recommendation surface.

The fact that llm.c and Torlink have both become quietly popular in the same season says something about where a non-trivial slice of the technical community has decided to put its attention. Not towards the slicker, more mediated experiences, and not towards the explicitly adversarial ones, but towards tools that respect the reader enough to assume they can read the source.

Stakes and what to watch

The limits of this comparison are real. llm.c is a serious piece of research software with a maintainer who has historically worked at the largest AI labs, and the project benefits from institutional credibility that a small self-hosted utility does not have. Torlink lives in a different part of the ecosystem entirely, and the legal and ethical texture around its core use case is not the same as the texture around training a GPT-2 replica.

What is shared is the design instinct, and the design instinct is what is worth watching. The next several quarters are likely to produce more tools of this kind: small, self-hosted, terminal-first, readable end to end, indifferent to platform capture. Whether they accumulate into something like a counter-movement, or remain a scattered set of curiosities, will depend on whether the technical community treats the pattern as an aesthetic preference or as an architectural position.

For now, the position is legible. Karpathy's repository is on GitHub at github.com/karpathy/llm.c. Torlink is on the clearnet under a handle that does not matter for this article. Both are quiet, both are growing, and both assume that the person running them is capable of reading the code that runs.

Desk note: Monexus covered this as a developer-tools story rather than a piracy story, on the grounds that the file in question is a public open-source release and that the underlying behaviour, terminal-first, self-hosted, no account, is what the article is actually about.

Sources

• github.com/karpathy/llm.c, Andrej Karpathy, llm.c repository, accessed 2026-06-30
• x.com/roundtablespace/status/2071767616754991104, @roundtablespace, "Karpathy's llm. c is quietly one of the most interesting repos in AI right now.", 2026-07-02
• x.com/darkwebinformer/status/2072011205758050304, @darkwebinformer, Torlink and the quiet return of the command-line torrent, 2026-07-02
• telegram:aipost, @aipost, "Nine GPUs in your garage should be illegal.", 2026-07-02
• Eliezer Yudkovsky and Nate Soares, If Anyone Builds It, Everyone Dies, 2026 (book)
• The community-run llm.c benchmarks and discussion threads, 2025-2026