HappyTorch: a self-hosted PyTorch exercise set with an auto-grader and two front ends

The gap HappyTorch targets: reading about layers, not writing them

The README states the problem in the first person. You have read the papers but do not know where to start implementing from scratch; you are asked to write softmax or MultiHeadAttention in an interview and your mind goes blank. That is a narrow audience, and the project serves it narrowly. The problem set is 36 items, spanning activation functions through Transformer components to RLHF, and each item is a function or class you have to produce: relu(x), my_softmax(x, dim), SimpleLinear, my_layer_norm(x, g, b), rms_norm(x, weight), scaled_dot_product_attention(Q, K, V), MultiHeadAttention, causal_attention(Q, K, V). The unit of work is a signature, not a notebook you read. That distinguishes it from a tutorial repository, where the answer is already in the cell and the only task is to run it. The README also claims no GPU is required, and the install instructions pull the CPU-only torch wheel, so the exercises are sized for a laptop.

How grading works: task files, a name mapping, and a 60 second timeout

The repository layout puts the graded material under torch_judge/tasks/, with one Python file per problem. The web UI executes submitted code in a namespace that the changelog says includes nn, F, numpy and math, which tells you the grader runs your function directly rather than parsing it. A 2026-03-10 entry records a 60 second request timeout being added, and the same entry notes class-based tasks such as LoRA and SwiGLU now work correctly, which implies the earlier grader only handled plain functions. The 2026-03-16 entry is the most informative about architecture: a contributor reported a notebook matching bug where attention and multihead_attention were confused, and the fix replaced suffix-based matching with an explicit name mapping. That is a design decision worth understanding before you trust a score. When a task and its notebook are paired by a hand-maintained map rather than by string matching, adding a problem means editing the map as well as the task file. It is more reliable and more manual. The README describes the feedback as showing what you got right and where to improve, and separately offers hints that are nudges rather than spoilers, plus reference solutions you view after your own attempt.

Running it: conda, prepare_notebooks.py, and two start scripts

The documented path is a conda environment named torchcode on Python 3.11, then pip install torch from the CPU wheel index, jupyterlab and numpy, then pip install -e . from the repository root. The editable install is what registers the judge package. After that, python prepare_notebooks.py generates the notebook set, which is the step people skip and then wonder why Jupyter mode is empty. From there the two interfaces diverge. Web mode needs fastapi, uvicorn and python-multipart, then python start_web.py, serving on http://localhost:8000. Jupyter mode is python start_jupyter.py on http://localhost:8888. The Docker path is shorter: make run for the web UI, make jupyter for notebooks, or docker compose up -d for the pre-built image, with MODE=jupyter docker compose up -d to switch. The README states progress data lives in data/progress.json and is persisted through a Docker volume, so a container rebuild does not wipe your solved list. There is also a hosted instance at happytorch.wavetao.top, announced 2026-04-03, if you want to try the problem set before committing to a local install.

Where the project is thin, and where it is the wrong tool

There are no release tags. The repository has been pushed recently and the README carries dated news entries, but the distribution model is clone-and-run from main, which means your problem set and your grader can change under you between sessions. For a solo learner that is tolerable. For anything with a cohort, a deadline or a grade, it is not: you would need to pin a commit and diff torch_judge/tasks/ between updates. The second constraint is scope. 36 problems is a curated set, not a curriculum, and the README does not describe prerequisite ordering or estimated time per problem, so the difficulty labels (Easy, Medium, Hard) are the only sequencing signal you get. Third, this is a self-assessment tool. The grader checks your function against tests the project author wrote. It cannot tell you whether your implementation is idiomatic, whether it matches the numerics of the reference under different dtypes, or whether it would pass a real interview follow-up. If you already write these layers fluently, HappyTorch will not teach you anything you cannot get from reading torch.nn source. And if what you actually need is training-loop debugging on real data, an exercise grader is the wrong instrument entirely.

The nearest alternative is the framework's own documentation and source

The obvious comparison is not another practice site. It is PyTorch's own tutorials and the torch.nn module source, and the difference is in what each gives you. A PyTorch tutorial hands you a complete, working implementation and explains it; you finish with a trained model and a rough mental model of the code you just ran. HappyTorch hands you a signature and a test suite and withholds the body. The failure mode is different too. In a tutorial, a wrong mental model survives because the code runs anyway. Here, a wrong mental model produces a failing test on the next submission. What the framework documentation has that HappyTorch does not is authority: the reference implementation in torch.nn is the definition of correct, whereas HappyTorch's tests are one author's specification of correct, revised as recently as March 2026. What HappyTorch has that the documentation does not is a forcing function. You cannot read your way through it.

Maintenance cost and what the MIT licence actually covers

The runtime footprint is small: a Python environment, a CPU torch wheel, FastAPI and uvicorn for web mode, JupyterLab for notebook mode. The README states no GPU is required, so there is no CUDA version to keep aligned with your driver. The moving parts you own are the Python version (3.11 is pinned by the documented conda command), the torch version, and the repository commit. Because there are no releases, upgrades mean pulling main and re-running prepare_notebooks.py, and the changelog shows the grader itself changing as recently as the 2026-03-16 matching fix, so a pull can alter scoring behaviour rather than only adding problems. Progress lives in a single JSON file, which makes backup trivial and migration between machines a file copy. The licence is MIT. That permits use, modification and redistribution, including in commercial settings, provided the copyright notice and permission notice are retained. It says nothing about the correctness of the reference solutions or the suitability of the grader for assessment, and it is not a warranty. If you intend to use the problem set inside a paid course or an internal hiring loop, the licence is not the constraint you should be checking; the grader's test coverage is.

A plugin exists, and what that implies about extension

The 2026-03-06 entry notes the release of happytorch-plugin, a separate repository. The README does not document its API, so the extension surface is not something you can evaluate from this material alone. What the changelog does show is a steady stream of external problem contributions (MLP XOR from one contributor, ML and RLHF problems from another, a rope.py fix from a third) and a Docker contribution from a fourth. That pattern suggests the intended way to grow the set is to add task files under torch_judge/tasks/ and, per the March 16 fix, register them in the explicit name mapping. If you plan to add your own problems, that mapping is the first file to read, because it is the seam where a new problem either connects to its notebook and grader or silently does not.

Editorial conclusion

Adopt HappyTorch if you want a small, MIT-licensed, CPU-only exercise set you can host yourself and read end to end, and if writing a LayerNorm or a multi-head attention block from memory is the skill you are actually missing. Do not adopt it as a curriculum for a team or a course: 36 problems with no release tags and no published grading contract means you would have to pin a commit and re-verify the grader yourself. Before running anything, open torch_judge/tasks/rope.py and one of the attention task files, read the test bodies, and confirm you agree with how they score partial credit.

Official sources

1. Issues
2. License: MIT
3. README
4. Rivflyyy/HappyTorch on GitHub