autonomous-computer: five open hardware GPU machines, and where the scaling actually bites

This is a hardware repository, so judge it as hardware

Set expectations before reading the build sheets. There is no code in this project. The top level is a license, a readme, a contributing guide and a setup note, alongside five directories named for their GPU count and card type. Inside each build are the things a hardware project publishes and a software project never has to think about: mechanical drawings, a bill of materials, firmware settings, wiring notes, and photographs of the assembly at each stage. The readme states the scope plainly, that it is open-source hardware providing every part, every bracket, every BIOS setting and every assembly photo, so you can build the whole machine yourself end to end. That is the whole value proposition and it is a real one, because for a small run of AI machines the mechanical design and the firmware configuration are the parts a commercial integrator treats as proprietary. It is also why the usual software evaluation criteria barely apply. There is nothing to install, nothing to compile, and no release cadence; the last commit was in August 2026 and the repository publishes no releases, because a design change is a different kind of event from a version bump. What you are really evaluating is whether the engineering decisions in the bills of materials are sound.

The progression is not linear, and the power figure tells you where it breaks

The five builds are laid out as a ladder, and reading them in order shows that the constraint is not the GPUs, it is the electricity. The entry build is a desk box: two consumer cards, sixty-four gigabytes of video memory, a single-socket workstation processor, and a stated draw of just over fifteen hundred watts on a sixteen-hundred-watt supply. It weighs thirty-three pounds and is a cube you could put under a desk. The four-card consumer build is where the character changes. It doubles the memory bandwidth and the card count, but the real number is the jump to twenty-seven hundred watts, a four-thousand-watt supply, and a chassis that grows from a foot cube to a two-foot one weighing sixty-six pounds. The four-card datacentre build is heavier again, needing two thousand-watt supplies, a native high-current connector, and a dedicated twenty-four-hundred-volt circuit, which is the point at which this stops being an object in an office. So the scaling is not two to four to eight in any useful sense. It is a desktop machine, then a floor-standing box, then a machine with a hard-wired supply, and the transition happens between the second and third step. That is exactly the kind of thing a bill of materials cannot hide and a photograph cannot show, and it is the first thing to check if you are planning around furniture, a circuit, or a rack.

Consumer cards or datacentre cards, and it cascades

The builds come in two GPU families and the choice is consequential, because the same chassis is offered with either. The consumer line gives you more of what most people measure: the four-card build reports eight hundred and thirty-eight teraflops of single-precision work against three hundred and eighty-four on the two-card datacentre build, and it is cheaper per unit of that throughput. The datacentre line gives you what the consumer line lacks, which is capacity and error correction. The two-card datacentre build carries ninety-six gigabytes per card for a hundred and ninety-two gigabytes total, and the four-card build reaches three hundred and eighty-four, all of it in error-correcting memory. That difference is the whole argument for the family. Video memory is the hard ceiling on local inference, and a model that does not fit has to be quantized down or split across cards, both of which cost you quality or latency. So if you want to run the largest open models as they are published, the extra memory is the point, not the flops. The build descriptions even make this explicit, contrasting running large models as released against quantizing them down to fit. The practical summary: consumer cards for throughput per pound and hobbyist-scale models, datacentre cards for fitting a frontier-scale open model in memory with error correction, at roughly three times the power for the two-card comparison.

Video memory is the budget, and the numbers are given honestly

Every build leads with its memory figure before anything else, which is the correct priority for inference and tells you the project's priorities. The ladder runs sixty-four gigabytes, a hundred and ninety-two, a hundred and twenty-eight, three hundred and eighty-four, and two hundred and fifty-six across the five builds, with bandwidth climbing in proportion and compute reported in single-precision teraflops. The readme makes the argument the numbers support, that open weights served through a hosted endpoint already cut the cost dramatically, and on your own machine there is no per-token bill. The honest caveat is that the ladder is not strictly ordered, because the four-card consumer build has less memory than the two-card datacentre build. That is not an error, it is the point of offering both families, and it means the build you choose is a trade between capacity and throughput rather than a straight upgrade path. The other number worth knowing is the storage and memory on the host side, which scales alongside: the four-card datacentre build carries a hundred and ninety-two gigabytes of error-correcting system memory and two terabytes of storage, and it uses a hundred and twelve processor lanes across seven slots, which is a constraint imposed by the platform rather than by the cards. If you are integrating into an existing server, that lane count and that lane budget are the numbers that decide whether the build is possible.

Open hardware plus an open orchestrator is a two-part argument

The readme pairs the hardware with a software story, and the pairing is the project's thesis rather than a technical requirement. The argument runs that open software lets you run and shape the model locally, and open hardware lets you build and repair the machine it runs on, and holding both, the code, the mechanical files, the bill of materials and the firmware settings, means you are not dependent on anyone's roadmap. The software side is deliberately not a dependency. The readme names the project's own open orchestrator for local AI as the easiest path, and then immediately lists three alternatives by name, a serving engine, a single-binary runtime and a C++ inference library, and says any of them works. That is the right posture for hardware: you are not locked into the vendor's inference stack, you are told what it is so you can replace it. The stronger version of the argument is the sovereignty one, that model weights on your own disk cannot be revoked and that prompts you send to a hosted service carry your product and your process to someone else. That is a business argument, not a technical one, and the designs do not depend on it being true. What they do depend on is that open models are good enough and the cards are affordable, which is a claim about the present that a specific build specification cannot verify for you.

Who this is for, and the honest limit of a design repository

Judge this project against what a design repository can be and not against what a product can be. It is excellent at the first. Every build gives you a motherboard model, a card count and type, system memory, storage, the PCIe generation and lane count, the networking, the power draw and supply, the physical dimensions and the weight, and then links to assembly photographs of the actual build. That is more engineering detail than most small-run AI hardware documentation offers, and the fact that it is published rather than held back is the contribution. The limits follow from the form. You will not find, in this repository, a bill of materials you can order from a single supplier, a validated vendor list for every part, thermal validation for your ambient temperature, or a support path when a bracket does not fit. Those things live in the vendor's head, and for a project that also sells a finished machine, some of that is deliberate. The readme says as much, offering a buy link if you would rather skip sourcing and assembly, and it is honest about the DIY path being the full one. So the real audience is someone who wants a second source, or a machine they can open, or a starting point for their own build, and is prepared to finish the engineering. If you want a working server this week, this is the wrong repository and the vendor's machine is the right answer.

Editorial conclusion

Adopt these designs if you want to run open models on hardware you own and can repair, and you are comfortable with a physical build, because what the repository actually gives you is the mechanical and firmware documentation a commercial integrator would otherwise keep to themselves. Do not adopt it as a turnkey product, because there is no image, no install script and no software here, only files you machine and assemble yourself, and the project sells a finished machine separately. Two things to check before you commit. Decide which GPU family you need, because the consumer cards are faster per pound and the datacentre cards carry error-correcting memory and twice the capacity, and that choice cascades into the memory, the lanes and the power budget of every build. And read the power and cooling figures for the build you are actually considering, because the jump from two cards to four is not a doubling, it is the point at which the box needs a dedicated circuit and stops being furniture.

Frequently asked questions

Official sources

1. autonomous-ai/autonomous-computer on GitHub
2. Issues
3. License: MIT
4. Project website
5. README