A 42.9 MB checkout exposes the route from tensor to kernel
We measured 1,640 files and about 520,436 lines of source in the 42.9 MB checkout. That repository puts the tensor API, automatic differentiation, intermediate representation, scheduler, code generator, JIT, and device runtimes together in Python. A matrix operation does not disappear behind a separate compiler service. You can turn up the debug output, see the generated code, and trace the decisions that produced it. For engineers learning ML systems, that visibility is the product.
The scope goes well past a teaching autograd. The README lists 8 accelerator paths: OpenCL, CPU, Metal, CUDA, AMD, Nvidia, Qualcomm, and WebGPU. It also includes neural-network layers, optimizers, data helpers, graph execution, and a compiler that fuses and lowers kernels. The appeal is control over that full route without adopting several repositories at once.
What happened when we ran it
We cloned and ran commit 3c59521 in our sandbox. Installation took 111 seconds, pulled 138 packages, and left 7,922 MB on disk. The build succeeded in 11 seconds. This was a fresh Debian container with Python 3.12, 3 CPUs, 8 GB of RAM, no secrets, and no elevated privileges. Pip-audit reported 19 known vulnerabilities in the installed environment.
The test step failed after 145 seconds. Pytest reported 2 passed and 200 failed out of 202 tests. The failures shown at the end all came from test/amd/hw/test_sop.py. Their error text says the emulator failed while compiling AMD instructions because it could not find the clang executable. That is the limit of what the supplied log establishes. It does not show a wrong arithmetic result or prove that all 200 failures had separate causes.
This result says something useful about setup. The source installation and build worked, yet the chosen hardware-test slice expected a system compiler that was absent from the clean image. The README's installation section gives the editable pip command, while its testing section points contributors to the CI workflow for fuller examples. A new contributor should read that workflow and reproduce the relevant job's system packages before treating pytest test/ as a self-contained check.
The empty core dependency list does not mean a small test machine
At commit 3c59521, the project metadata declared Python 3.11 or newer and no mandatory runtime dependencies for the core package. That is attractive if you only want basic tensor work. It also sits beside several optional test groups that bring in NumPy, PyTorch, pytest, ONNX tools, Transformers, audio libraries, and other packages. Our installed environment reached 7,922 MB, so the minimal core and the contributor setup are very different purchases.
Hardware expands the matrix again. Each of the 8 listed backends has its own driver, compiler, operating-system, or device assumptions. tinygrad can choose a default device, but that does not certify every path on your machine. The absent clang binary in our run is a concrete example. Pin the commit, choose the backend first, then copy the matching CI job instead of installing every optional group and hoping the full suite describes your target.
v0.14.0 still permits user-facing API removal
The project says plainly that it has not reached 1.0. Release v0.14.0 demonstrates what that means: Tensor.training and Tensor.train() were removed in favor of a TRAINING context variable. The same release changed scalar typing, made default numeric types context variables, and enabled parallel kernel compilation by default. Those are meaningful changes for code that follows the moving main branch.
That pace is reasonable for compiler and hardware research. It is less comfortable for an application team that wants a stable framework boundary. Pinning a revision is necessary, and upgrade work should include model-level regression tests on the actual device. Familiar PyTorch-style loops reduce the learning cost, but familiar syntax is not a compatibility promise.
v0.14.0 contribution rules favor small measured changes
The v0.14.0 README sets an unusually narrow bar for pull requests. Bug fixes need regression tests. Performance claims need measurements. Large or complex diffs may be rejected, and the maintainers ask contributors to split prerequisite refactors from the feature they enable. Documentation-only and whitespace changes are generally closed unless the contributor is already known to the project.
That policy protects a codebase whose stated aim is low complexity, but it changes who will enjoy contributing. Someone arriving with a 300-line abstraction or a broad cleanup is working against the review model. A focused hardware fix with a reproducer fits better. The guide also warns that code outside the core tinygrad/ folder is not tested as well, a useful boundary when deciding how much confidence to place in an example or extra utility.
An October 7 push shows active work, not settled behavior
GitHub showed 33,710 stars, 124 open issues, and 39 open pull requests on October 7, 2026. The repository was pushed that same day. One issue updated on October 7 concerned a USB GPU after a lost 12-volt supply, while another opened on October 6 documented an AMD KFD problem. Together with 9 CI workflow files, that is strong evidence of current hardware work and active maintenance.
Release v0.14.0 arrived on August 24 after more than 1,000 commits since v0.13.0. Activity does not erase the setup result from our September 30 sandbox or turn a pre-1.0 API into a fixed target. tinygrad is a good choice when the compiler, scheduler, or device layer is what you want to understand and alter. If those layers are merely a way to ship a model, the 200 failed tests are a good reason to begin with a more settled framework.