Skip to main content

max / everycycle

Strip historical narrative from documentation Remove what a doc used to say, when it changed, the incidents that justified a rule, finished migration narration, and counts and versions that rot. State the rules in the present tense instead. Keep every instruction, prohibition and threshold, and keep the measurements that make a rule actionable. Public-facing docs keep their explanatory voice.
Co-Authored-By
Claude Opus 5 (1M context) <noreply@anthropic.com>
Claude-Session
https://claude.ai/code/session_01MptwXZ8k65v19rFmdGAyki
Author: Max Johnson <me@maxj.phd> · 2026-08-31 01:51 UTC
Signed with PGP, not checked
Commit: 424fe96a329e499e1c193f818d708a52a68c459a
Parent: 7cbb9c8
5 files changed, +20 insertions, -36 deletions
M README.md +3 -3
@@ -22,9 +22,9 @@
22 22
23 23 ## Crates in this repo
24 24
25 - Eight workspace members under `crates/`. None is published to crates.io: the unit of
26 - publication is this repo, not the individual crates, so they version together and none
27 - of them is a stable dependency surface for outside code.
25 + Workspace members under `crates/`. None is published to crates.io: the unit of
26 + publication is this repo, so the crates version together and none of them is a stable
27 + dependency surface for outside code.
28 28
29 29 | Crate | Role |
30 30 |---|---|
M docs/appraisal.md +4 -4
@@ -1,4 +1,4 @@
1 - # EveryCycle — Appraisal
1 + # EveryCycle Appraisal
2 2
3 3 How EveryCycle measures a GPU as a tool for doing computation, and why the same measurement feeds both the scheduler and the eventual TailoredMachines buyback formula.
4 4
@@ -169,9 +169,9 @@
169 169
170 170 ## Initial targets
171 171
172 - **First target — astra + RTX 5070 Ti.** The probe suite is developed against **astra** (Linux aarch64 native build host on the tailnet at 100.106.221.39; note the system hostname collides with another `pop-os` and the disambiguator is the tailnet name). The card currently plugged in is an **NVIDIA GeForce RTX 5070 Ti** (GB203 Blackwell, 16 GB GDDR7, PCI ID `10de:2c05` at BDF `0000:01:00.0`, driver 580.126.18 at time of writing).
172 + **First target: astra + RTX 5070 Ti.** The probe suite is developed against **astra**, the aarch64 Linux build host on the tailnet. Address it by tailnet name. The card plugged into it is an **NVIDIA GeForce RTX 5070 Ti** (GB203 Blackwell, 16 GB GDDR7, PCI ID `10de:2c05` at BDF `0000:01:00.0`).
173 173
174 - **Second target — gaming-PC host + RTX 5070.** Once Phase B works on astra, the next host is the operator's gaming PC running an **NVIDIA GeForce RTX 5070** (GB205 Blackwell, 12 GB GDDR7). Same vendor and generation as the first card, so the probe code path is the same, but it is a different SKU on a different host on a different ISA (x86_64 vs aarch64) — exactly the comparison that proves the SKU-agnostic rule holds in practice: both cards run through the same enumeration and probe code, the report differs only in measured values.
174 + **Second target: gaming-PC host + RTX 5070.** Once Phase B works on astra, the next host is the operator's gaming PC running an **NVIDIA GeForce RTX 5070** (GB205 Blackwell, 12 GB GDDR7). Same vendor and generation as the first card, so the probe code path is the same, but it is a different SKU on a different host on a different ISA (x86_64 vs aarch64). Both cards run through the same enumeration and probe code, and the report differs only in measured values, which is the check that the SKU-agnostic rule holds in practice.
175 175
176 176 Choosing astra first is deliberate: it forces the Vulkan and BLAS paths to work on aarch64 Linux from day one, which is the harder of the two architectures EveryCycle targets, and shakes out any x86-only assumptions in dependencies before they calcify. The 5070 Ti is also a good first target on the merits:
177 177
@@ -179,7 +179,7 @@
179 179 - Nvidia's Blackwell drivers expose `VK_KHR_cooperative_matrix` (and the newer `VK_NV_cooperative_matrix2`), so the primary cross-vendor path can be developed and verified here before the AMD and Intel ports land.
180 180 - 16 GB VRAM is real-but-modest, matching the EveryCycle target audience (cheap-and-slightly-old hardware) better than an H100 would. Memory-bound workloads behave the way they will in production.
181 181
182 - The host also carries an ASPEED Graphics chip at `0003:02:00.0` — that is the server motherboard's BMC display, not a compute device. The device-enumeration step will need a filter that picks discrete-compute GPUs only (PCI class plus vendor plus presence of a discrete VRAM pool is the cheap heuristic).
182 + The host also carries an ASPEED Graphics chip at `0003:02:00.0`, the server motherboard's BMC display rather than a compute device. The device-enumeration step will need a filter that picks discrete-compute GPUs only (PCI class plus vendor plus presence of a discrete VRAM pool is the cheap heuristic).
183 183
184 184 ## References
185 185
M docs/architecture.md +6 -6
@@ -1,6 +1,6 @@
1 - # EveryCycle — Architecture
1 + # EveryCycle Architecture
2 2
3 - First architectural sketch of EveryCycle. This is a sketch, not a spec — it exists to make trade-offs visible and to give the Phase 0 demo a target.
3 + An architectural sketch rather than a spec. It exists to make trade-offs visible and to give the Phase 0 demo a target.
4 4
5 5 ## The bet
6 6
@@ -12,7 +12,7 @@
12 12
13 13 1. **GPU pricing is set by training demand.** A used 3090 ($500–700) and an H100 ($25k) have a ~40× price gap and a ~3–6× inference-throughput gap on realistic memory-bound workloads. The remaining ~7–10× spread is captured by whoever writes the software to make the cheap path reliable.
14 14 2. **Existing inference engines assume homogeneity.** vLLM and TGI work best on identical modern GPUs. llama.cpp handles cheap and mixed hardware brilliantly at the single-user level but is not a serving runtime. The serving-grade-but-heterogeneous-aware engine doesn't exist in production form.
15 - 3. **Inference quality on quantized models has caught up.** Q4_K_M and IQ-quants on competent models are now indistinguishable from FP16 for most production tasks. The "you need full precision" reflex is two years stale.
15 + 3. **Inference quality on quantized models has caught up.** Q4_K_M and IQ-quants on competent models are now indistinguishable from FP16 for most production tasks. The "you need full precision" reflex is out of date.
16 16
17 17 EveryCycle puts those three observations together.
18 18
@@ -172,12 +172,12 @@
172 172
173 173 **Phase 2 — Multi-box orchestrator (16 weeks).** Orchestrator with capability map and routing. Speculative decoding with draft on separate device or box. Model registry: warm/cold state per box, rolling model loads. First customer-deployed cluster.
174 174
175 - **Phase 3 — Hardening and openness (ongoing).** Publish BMC agent and runtime as open repos (the project is unlisted on SourceHut until Phase 0; see README). Reference benchmarks against vLLM and TGI on equivalent hardware, published honestly. Documentation thorough enough that a hardware resident can read it in their first month.
175 + **Phase 3 — Hardening and openness (ongoing).** Publish BMC agent and runtime as open repos. Reference benchmarks against vLLM and TGI on equivalent hardware, published honestly. Documentation thorough enough that a hardware resident can read it in their first month.
176 176
177 177 ## What this sketch leaves open
178 178
179 179 - Exact factoring across the named crates: which logic lives in `runtime` vs `hal` vs `scheduler`. Phase 0 decision.
180 - - Whether the BMC agent shares any code with the host runtime. Probably not — different security and reliability constraints — but `everycycle-hal` may expose a thin shared schema crate.
180 + - Whether the BMC agent shares any code with the host runtime. Probably not, given the different security and reliability constraints, though `everycycle-hal` may expose a thin shared schema crate.
181 181 - HA story for the orchestrator. Phase 2 problem.
182 182 - Multi-tenant isolation guarantees. Start single-tenant per box; add per-tenant isolation when a customer asks.
183 183
@@ -186,4 +186,4 @@
186 186 - "Let's also write the kernels in Rust." No. Bind to `cudarc` and friends. The scheduler is where time should go.
187 187 - "Let's support training as a stretch goal." No. Different software discipline, different customer, different cadence.
188 188 - "Let's start with the orchestrator." No. Phase 0 must be a single binary that runs on one box and looks great in a demo. The orchestrator is Phase 2.
189 - - "Let's target H100s for the demo." No — the whole point is that the demo runs on hardware that cost $2000, and that's *more impressive*, not less, to the kind of investor we want.
189 + - "Let's target H100s for the demo." No. The demo runs on hardware that cost $2000, which is the point.
M docs/roadmap.md +6 -21
@@ -1,4 +1,4 @@
1 - # EveryCycle — Roadmap
1 + # EveryCycle Roadmap
2 2
3 3 This is the live thread roadmap. Work advances on parallel threads, not numbered phases. The project's "current state" is the snapshot of where every thread stands together.
4 4
@@ -39,8 +39,7 @@
39 39 ## Platform and distribution
40 40
41 41 - **Linux only by design.** macOS-native is not on the roadmap. Apple Silicon support, if it comes, comes via Asahi Linux.
42 - - **A Fedora downstream is the reference target, loosely.** Changed 2026-08-21. This line read "Pinned to Ubuntu LTS (24.04)" and was written before Alloy existed; the reference host is a Fedora-derived image now. Loosely is the operative word: the codebase is generic Linux, the reference host is where it is built and probed first, and nothing here is a hard pin. Other distros stay best-effort.
43 - - **What the change costs, stated.** The Ubuntu line justified itself as matching the MNW production server, so that one test matrix covered infra and inference. MNW production is Ubuntu 24.04, so that no longer holds and the two matrices are separate. Accepted deliberately: EveryCycle's target is the box with the GPUs in it, not the box serving the website, and those were only ever the same distro by coincidence.
42 + - **A Fedora downstream is the reference target, loosely.** Loosely is the operative word: the codebase is generic Linux, the reference host is where it is built and probed first, and nothing here is a hard pin. Other distros stay best-effort. EveryCycle's target is the box with the GPUs in it, not the box serving the website, so the reference host does not track MNW production's distro and the two test matrices are separate.
44 43 - **Glibc build, RPM packaging.** The daemon is a standard glibc binary. Executor isolation (in-process dlopen vs out-of-process sidecar) is decided per executor by vendor SDK stability and crash blast-radius, not by libc compatibility.
45 44 - **Immutability is the one thing that is genuinely different, and it is a kernel-module question.** An image-based host (bootc, rpm-ostree) has no DKMS at update time, so a vendor kernel module cannot be built on the machine the way `nvidia-dkms` does on Ubuntu. It has to be baked into the image or layered as an akmod. Everything else about an immutable host is friendlier than it sounds: `/opt` and `/usr/local` are `/var`-backed and writable, so CUDA and ROCm install where their installers expect, `/etc` and `/var` persist, and systemd, udev and `/dev` are unchanged. Treat the module delivery path as real work and the rest as packaging format.
46 45
@@ -101,23 +100,9 @@
101 100
102 101 The hardware line is how the operation pays for EveryCycle's development. Machine BOMs, sourcing routes and pricing live in the TailoredMachines wiki rather than in this repo.
103 102
104 - **Note (2026-07-10):** The hardware line was rebranded to **TailoredMachines** and narrowed to a small-batch atelier cutting workstations for **1–6 programmers doing bursty pair-programming and audit/fuzz workloads**. The product architecture is a single Platform SKU (v1: "The House Cut") plus three explicit GPU paths (Alterations / Off-the-Rack / The Collection). See the TailoredMachines plan and brand docs for the current framing. The tier list below (H1–H4, previously "MakeMachines") is historical — H3 (hobbyist edge) and H4 (rack appliance) fall outside TailoredMachines' scope entirely, and H1/H2 are collapsed into the House Cut framing.
103 + The line is a small-batch atelier cutting workstations for **1–6 programmers doing bursty pair-programming and audit/fuzz workloads**. The product architecture is a single Platform SKU (v1: "The House Cut") plus three explicit GPU paths (Alterations / Off-the-Rack / The Collection). See the TailoredMachines plan and brand docs.
105 104
106 - Thread H's active work now happens against TailoredMachines' plan, not this table. Kept here for continuity with the pre-narrowing roadmap; will be rewritten wholesale when the House Cut ships its first external unit.
107 -
108 - <details>
109 - <summary>Historical H1–H4 tier list (pre-narrowing, pre-rebrand)</summary>
110 -
111 - | Milestone | Design | Target | Notes |
112 - |---|---|---|---|
113 - | **H1** | MakeMachine v1 | First unit: Sando host + EveryCycle dev. Subsequent units: MNW (internal-transfer) and small-batch external sales. | Threadripper Pro WRX90 + flexible GPU bays. The dogfood design and the first revenue unit. |
114 - | **H2** | Mid-tier workstation | Solo operators, small labs (~$5K) | Single-CPU EPYC or TR non-Pro, 1-2 GPU bays, tower form factor. |
115 - | **H3** | Entry-level edge | Hobbyists, classrooms, residencies (~$2K) | Mini-ITX or SFF, single GPU, quiet, low-power. |
116 - | **H4** | Rack appliance | Datacenter and colo deployments (~$15K+) | 2U or 4U, 4-8 GPU bays, redundant PSU, dual NIC, OpenBMC. |
117 -
118 - Each milestone was to produce: published BOM, chassis CAD, thermal model, BMC firmware bundle, EveryCycle config tuned for the platform, assembly guide. Names in this table (e.g. "MakeMachine v1") are the pre-rebrand names and are preserved for continuity; the current name is TailoredMachines.
119 -
120 - </details>
105 + Thread H's active work happens against TailoredMachines' plan, not against this repo.
121 106
122 107 ### Thread I — Client API and adoption
123 108
@@ -170,7 +155,7 @@
170 155 - **Multi-client is the default, not a feature.** The daemon assumes concurrent clients from A1, even when only one is connected. The internal data model, scheduler, and audit surface are designed around N clients sharing M devices under policy; the N=1 case is just the limit. This is the structural difference between a system service and a runtime library.
171 156 - **Compatibility shims are clients, not daemon code.** Each protocol shim (OpenAI, llama.cpp, Ollama, vLLM, ComfyUI) is a separate process that speaks the native EveryCycle client API. The shims do not get privileged access to internals. This forces the native API to be expressive enough that the shims are thin — and keeps the daemon free of protocol-specific code paths.
172 157 - **Implementation languages.** Main binary is Rust, built natively for the reference Fedora downstream (glibc, RPM-packaged). Module boundary is a **stable C ABI** from a reasonable point — early enough that the second executor doesn't lock the trait shape into Rust-internals. Module *implementations* may be in any language that emits a C-ABI shared library (Rust, Zig, C). The BMC agent is a separate binary and is the leading candidate for being written in Zig rather than Rust; that decision deferred until the agent is real.
173 - - **Crate naming.** The daemon-internal native client API lives in `crates/api/` (renamed from `crates/serving/` on 2026-06-21). Thread J shims (OpenAI, llama.cpp, Ollama, vLLM, ComfyUI) will land as their own crates (`crates/shim-openai`, etc.) when they ship — they are not modules of `crates/api`. The HTTP "serving" framing is gone from the daemon by design.
158 + - **Crate naming.** The daemon-internal native client API lives in `crates/api/`. Thread J shims (OpenAI, llama.cpp, Ollama, vLLM, ComfyUI) will land as their own crates (`crates/shim-openai`, etc.) when they ship — they are not modules of `crates/api`. The HTTP "serving" framing is gone from the daemon by design.
174 159
175 160 ## Model stance
176 161
@@ -188,7 +173,7 @@
188 173
189 174 ## Open questions (will be resolved iteratively)
190 175
191 - - Executor isolation: in-process dlopen + watchdog threads + structured panic handling, or out-of-process with local-socket IPC. Per executor, driven by vendor SDK stability and crash blast-radius. In-process is the default for executors that behave; out-of-process when an executor empirically destabilizes the host process. Standardizing on one glibc reference host removes libc compatibility as a forcing factor, since CUDA and ROCm SDKs target glibc natively, so sidecar separation is a stability choice rather than a packaging workaround. That argument was made for Ubuntu and survives the move unchanged: it turns on glibc, not on which distro ships it.
176 + - Executor isolation: in-process dlopen + watchdog threads + structured panic handling, or out-of-process with local-socket IPC. Per executor, driven by vendor SDK stability and crash blast-radius. In-process is the default for executors that behave; out-of-process when an executor empirically destabilizes the host process. Standardizing on one glibc reference host removes libc compatibility as a forcing factor, since CUDA and ROCm SDKs target glibc natively, so sidecar separation is a stability choice rather than a packaging workaround. That turns on glibc, not on which distro ships it.
192 177 - CPU executor placement: statically linked into the base binary (always-present fallback) vs another module
193 178 - A1 dispatch planner: greedy heuristic only, or invest in a real optimizer up front
194 179 - BMC agent's actual A1-equivalent role: just enumerate Redfish, or already running on flashed OpenBMC
M crates/appraise/src/sign.rs +1 -2
@@ -93,8 +93,7 @@
93 93 ///
94 94 /// # Panics
95 95 ///
96 - /// Panics if the OS entropy source is unavailable, matching the
97 - /// behaviour of the `OsRng` this previously went through.
96 + /// Panics if the OS entropy source is unavailable.
98 97 #[must_use]
99 98 pub fn generate(identity: impl Into<String>) -> Self {
100 99 let mut seed = [0u8; 32];