01
Build the artifact
Each offering begins with a real tool, curriculum, experiment, or documented field test.
A public proposal · August 2026
What if Omacom sponsored the human side of computing?
We are building Build In Public University as a public program for creating more capable, optimistic relationships between people and technology. Instead of sending ten cold emails, we are building ten concrete offerings in public.
This is a proposal, not an announcement of sponsorship or endorsement. The Omacom Foundation has not agreed to this request.
Why build this in public?
The request should earn its way into existence.
A sponsorship deck can describe alignment. Working artifacts can demonstrate it. We will build the offerings first, publish what changes, and invite the ten Omacom contributors to inspect the work rather than asking them to trust a polished claim.
02
Publish the receipt
We will show what ran, what was measured, what failed, and what remains only a design target.
03
Invite the person
Each contributor gets a specific invitation tied to their public work—not a generic sponsorship paragraph.
04
Make the institutional ask
Only after the work is legible will we ask whether Omacom wants to become BIPU’s presenting sponsor.
Mission deadline: November 29, 2026 at midnight Eastern.
—days
—hours
—minutes
—seconds
Ten people · ten proofs of alignment
Each offering starts from something they have already built.
These are not ten unrelated pitches. Together they form a curriculum for a complete human relationship with technology: machine, agent, memory, creation, infrastructure, hardware, social system, trust, interface, and daily life.
DHH · OmarchyPiA reproducible ARM node demonstrating an opinionated, local-first computer as a useful instrument for building and solving problems.
Peter Steinberger · Agent literacyA curriculum for delegating work to personal agents without surrendering judgment, identity, or agency.
Drew Houston · Personal continuityA lab for preserving a person’s work, context, and digital life across machines and services.
Tobi Lütke · Open builder schoolA practical path for non-specialists to build small, useful software and contribute to open systems.
Patrick Collison · Capability infrastructureA fellowship for public, reproducible projects that treat education and documentation as infrastructure.
Michael Dell · Linux reference buildA hardware-and-software path that closes the gap between owning a capable machine and feeling capable with it.
Jack Dorsey · Protocol and agencyA public lab showing how identity and communication change when people understand the protocols beneath their tools.
Matthew Prince · Trustworthy infrastructureA practical curriculum for privacy, security, resilience, and local-first computing without fear theatre.
Brendan Iribe · Human interfacesAn experiment series asking what new interfaces should make easier before asking what they can technically do.
Jason Fried · Calm softwareA public school for building useful technology without turning every tool into an employer, audience, or anxious supervisor.
The proposed path
Build first. Ask clearly.
The eventual request is simple: would the Omacom Foundation consider becoming the presenting sponsor of an initial 12-month BIPU pilot? But the request comes after the evidence. Sponsorship is a proposed future state, not a current relationship.
01 · SHIPBuild OmarchyPi
Run it on a fresh device, verify the boundaries, and document the second-node path.
02 · MAPPublish the offerings
Turn each patron-specific idea into a small, inspectable artifact brief with a falsifier.
03 · INVITEBuild in public
Publish progress, misses, questions, and invitations through the BIPU surface.
04 · ASKRequest sponsorship
Present the program, budget, editorial independence, and measurement plan.
The existing work, moved to the background
Receipts before rhetoric.
The dream build remains here as a concrete long-term target. The mission proposal is now in front; these are the artifacts and background materials underneath it.
A public build brief · Omarchy ML monster
Put the model on the desk.
A dream local-AI workstation running Omarchy Linux: enough VRAM for serious open-weight models, enough CPU and memory for research, and enough receipts to know when the expensive rectangle is actually helping.
The dream configuration
Capacity first. Repairability second. Hype nowhere.
The machine is designed around local model capacity, multi-GPU experimentation, fine-tuning, and concurrent agents. Omarchy supplies the human-facing layer; the hardware supplies the actual power.
Workstation core
One local AI lab.
The flagship version uses a WRX90 platform with enough PCIe lanes, memory channels, cooling, and power headroom to make multi-GPU work possible without pretending that model parallelism is free.
Threadripper PRO 9995WX96 cores · 192 threads512 GB ECC RDIMM4 × 96 GB GPUs2 TB system NVMe8 TB active NVMe
384 GBaggregate physical VRAM
1,200 WGPU board power, Max-Q configuration
128usable PCIe 5.0 lanes, CPU platform maximum
70B–120Bsingle-GPU model territory, quantization-dependent
The software stack
Arch underneath. Receipts on top.
Omarchy is not a magic performance potion. It is a clean, opinionated interface to a machine whose critical boundaries remain visible.
01
Omarchy + CUDA
Encrypted Btrfs and Limine for the workstation base. NVIDIA open kernel modules and pinned CUDA/PyTorch environments for fewer update-induced surprises.
02
llama.cpp
GGUF inference, quantization experiments, GPU offload, CPU fallback, and the simplest path from a model file to a local OpenAI-compatible endpoint.
03
vLLM + training
Continuous batching and tensor parallelism for serving; Transformers, PEFT, and TRL for fine-tuning. Containers keep experiments reproducible.
01 · BOOTOwn the machine
Encrypted local storage. No private model files sent away by default.
02 · LOADFit the model
Measure weights, context, KV cache, quantization, and actual memory use.
03 · RUNServe the work
Use local models for research, coding, agents, vision, and bounded experiments.
04 · LOGPublish the miss
Record throughput, latency, energy, quality, and the cases where the monster was slower than the cloud.
What it could run
Model capacity is not model quality.
These are engineering targets, not promises. Quantization, context length, architecture, interconnect topology, and framework support decide whether a model merely fits or is pleasant to use.
A
Comfortable
7B–32B models with large context windows, multiple resident services, vision tools, embeddings, and local agent loops.
B
Serious
70B-class models on one 96 GB GPU. 100B–120B-class models are plausible with suitable low-bit formats and a disciplined context budget.
C
Experimental
200B–400B-class models through multi-GPU sharding. Capacity may work before latency does. The market has enough benchmark theatre already.
The first build should be smaller.Start with one 96 GB GPU and validate Omarchy, CUDA, llama.cpp, vLLM, thermals, and update recovery. Add the other cards only when a measured workload—not the desire to possess a small data center—requires them.
The funding boundary
Support the experiment, not a fantasy invoice.
Contributions support the research and construction of the local AI workstation described here. The target configuration is a design, not a purchased asset. Hardware, power, taxes, availability, and prices can change. We will publish what was actually bought, what it cost, and what it can actually do.
Stripe checkout is an existing BIPU support link. It is not a hardware pre-order, equity offering, token sale, or promise of financial return. Stripe collects payment details; we do not put credentials or payment logic in this static page.
The next receipt
Build the single-GPU version first.
Then measure whether the second GPU earns its slot. The thesis means nothing without the artifact. Ship the pipeline. Measure the outcome. Publish the miss.