TrenTorch: the same framework curriculum in a browser grader and a CLI

A browser grader and a terminal curriculum in the same repository

TrenTorch presents itself as a way to learn PyTorch by building your own, and what sits in the repository is two separate products sharing the idea. One is TrenTorch_Web, a SvelteKit application where 350 plus coding questions are graded instantly in the browser, with Python executing through Pyodide and sign-in through GitHub, Google or email. Nothing has to be installed to use it, and a Problem of the Day surfaces one new web question each day.

The other is TrenTorch_CLI, a Python package installed as the command tren, where 20 modules build a working framework from tensors through autograd, optimizers and training to a capstone. Where the work lives is also different: the web side records progress against your account, while the CLI keeps it locally under user_data/, so a learner can work without a server and without an account.

The split explains a detail that otherwise looks odd. The browser build has no import torch anywhere in its curriculum, and every operation traces back to raw NumPy, so the questions ask you to reimplement what production frameworks do rather than call them.

The CLI is a reimplementation, the browser side is original

The provenance is stated plainly at the top of the readme, and it matters for anyone choosing between the two halves. The CLI curriculum is an implementation of TinyTorch from Harvard CS249R, rebuilt and extended in the project's own style. The browser version is described as its own work, built independently.

That distinction has practical consequences. The 20 CLI modules follow a fixed progression with numbered files from 01_tensor to 20_capstone, which suits a learner who wants a syllabus and a terminal. The 350 plus web questions are spread across 12 topic areas and are graded by tests plus a reference solution, which suits a learner who wants breadth and immediate correction. Each web question carries a problem statement, a theory section, a starter file, tests and a reference solution, so a question is a complete unit rather than a line in a list.

Where both halves agree is the constraint they impose: every operation resolves to raw NumPy, and the architecture mirrors what production frameworks use. You end up knowing what loss.backward() does because you wrote it.

tren setup puts the command on your PATH for good

The terminal path is short, and the last two commands are the ones people skim. Creating the environment and installing the package are ordinary steps:

git clone https://github.com/TrenTorch/TrenTorch.git
cd TrenTorch/TrenTorch_CLI
python3 -m venv .venv && source .venv/bin/activate
pip install -r requirements.txt && pip install -e .
tren setup
tren module start 01

tren setup is the one to read. It adds tren to your PATH, so terminals opened afterwards call tren with no activation step and no source .venv/bin/activate. The virtualenv exists to build and edit the package, not to survive the session.

A PowerShell variant sits in a collapsed section for Windows: python -m venv .venv on its own line, .venv\Scripts\Activate.ps1 on the next, then the same two pip calls, tren setup and tren module start 01. Past the quickstart there are four more commands documented in TrenTorch_CLI/docs/command-reference.md: tren tui, tren serve, tren milestone and tren benchmark.

One source directory becomes notebooks, then the package you import

Under TrenTorch_CLI/data the layout explains how the course is built rather than only how it is consumed. src/ holds the curriculum source and is the directory to edit, from 01_tensor to 20_capstone. modules/ holds generated notebooks, and those are student facing with stubs only. datasets/ carries small training datasets. milestones/ holds the historical recreations. trentorch/ is the generated package you import from.

The workflow is a one way pipeline written out in the readme: TrenTorch_CLI/data/src/*.py becomes TrenTorch_CLI/data/modules/*.ipynb, which you solve, and your solutions end up in TrenTorch_CLI/data/trentorch/*.py. So the notebook is the exercise and the package is the result, and both are produced from the same source files.

One directory in that list is deliberately closed off. solutions/ holds the reference implementations, marked as maintainer and CI only. That split is why the npm test:pyodide script can run every question's reference solution as a check: the answers the grader compares against are not the ones shipped to the student.

350 plus questions across 12 areas, against 20 numbered modules

The web side counts breadth. Its 12 topic areas run from math and statistics (linear algebra, calculus, probability, information theory, data preprocessing, exploratory analysis, statistical inference) through classical ML, deep learning core, training, sequence modeling, transformers and LLMs, inference, vision, systems performance, distributed systems, RL and alignment, and production ML. Systems performance alone lists profiling, quantization, mixed-precision training, compression, acceleration and kernels; RL and alignment ends with benchmarking and a capstone.

The CLI counts sequence instead. Twenty modules split into four parts: Foundations 01 to 08 building tensors, activations, layers, losses, a dataloader, autograd, optimizers and training; Vision at 09 with Conv2d and CNNs for image classification; Language 10 to 13 with tokenization, embeddings, attention and transformers; and Optimization 14 to 20 with profiling, quantization, compression, acceleration, memoization, benchmarking and the capstone.

The overlap is deliberate and the divergence is the point. A learner can move from a web question on attention to module 12 in the same repository, or stay in one half, and neither half duplicates the other's ordering.

Six historical milestones sit behind your progress

Progress through the CLI unlocks recreations of landmark results, run on the framework the learner is building rather than on an imported one. The table gives six: 1958 Perceptron, reproduced as binary classification with gradient descent; 1969 XOR Crisis, multi-layer networks solving non-linear problems; 1986 Backpropagation, multi-layer network training; 1998 CNN Revolution, image classification with convolutions; 2017 Transformer Era, language generation with self-attention; and 2018 onwards MLPerf for production grade optimization.

This is the part of the curriculum with no counterpart on the web side, and it changes what the terminal build is for. The modules are not a reimplementation exercise with a historical veneer; the earliest milestone is a working gradient descent before any framework exists to call, and the milestones directory under data/ holds these recreations alongside the datasets.

The sequencing matters as much as the content. A learner reaches backpropagation in 1986 order and self-attention in 2017 order, so the framework grows in step with the history it is reproducing.

test:pyodide is the script that runs the real answers

Running the web app locally takes three commands and one file you have to fill in yourself:

cd TrenTorch_Web
npm install
npm run dev

Sign-in there uses Supabase, and .env.example has to be copied to .env with your own project keys before local sign-in works. There is no fallback account and no documented anonymous mode for the local build.

Five npm scripts cover the checks. npm run check type checks. npm run lint runs Prettier and ESLint. npm run test runs unit tests under Vitest. npm run test:pyodide runs every question's reference solution and tests it in a real Pyodide, which is the only one of the five that proves the browser grader itself works rather than the JavaScript around it. npm run build produces a production build that is fully prerendered.

Merging needs an issue, an assignment and a second reader

The contribution rules are specific enough to be worth reading before writing any code. Issues and pull requests are welcome, but the contributing guide at TrenTorch_CLI/docs/CONTRIBUTING.md asks you to open an issue first and to be assigned before you start on it. Merging requires green CI and one review from someone other than the author.

The visible text then stops mid-sentence, at the mention of a first-contribution bot, which means the FAQ section linked from the top of the page is not part of what can be read here. Neither is anything after it.

Two other facts sit outside the readme. The repository is on the dev branch by default and the last push is dated 1 October 2026, while the only release is v1.0.0 from 4 September 2026, so the release trail lags the branch. And no licence is asserted for the repository, which is a decision worth making yourself before copying any of this code into a course or a company project.

Editorial conclusion

TrenTorch suits two different users, and the choice between them is the useful decision. A learner who wants to be corrected inside two seconds without touching a virtual environment should start on the site; a learner who wants a framework on disk that they can import should start at the CLI and follow the src to modules to trentorch path. Either way the gaps are the same: no licence is asserted for the repository, the single release v1.0.0 predates the current work on the dev branch, and the FAQ the page links to is not readable. Check the licence before using it in a course or a company repository.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. Releases
5. TrenTorch/TrenTorch on GitHub