The question stopped being does it fit and became how much has to be here.

A C inference engine (Apache-2.0, no dependencies past a C11 compiler and make) that runs the full Kimi K3 — all 2.78 trillion parameters, repacked to 3-bit residual vector quantization — on a 64 GB MacBook Pro. It keeps a 27.28 GB resident trunk in memory and streams the rest from NVMe: only about 4% of K3's parameters fire per token, so the engine issues one pread per activated expert (one, not three) and spends whatever RAM is left on a bounded LFRU cache for the experts that keep coming back. macOS arm64 and Linux arm64/x86_64 pass the test suite; Windows is cross-compiled and admits it's unproven under load. SIMD path is picked from CPUID at runtime. From SQLite Cloud, three days old, 113 stars.

Two standing watches closed on this one artifact. On 07-27 we asked whether anything would make a 3T-class model runnable outside a datacenter and what that would cost; on 07-30 we asked whether TurboFieldfare's expert-paging trick would survive contact with a different model family and a different OS. Both answers are here and both are bracingly unglamorous: 0.49–0.54 tokens per second, and 982 GB of internal NVMe is mandatory — the same run over external USB measured 13 seconds per token, because the bus does 0.94 GB/s against the internal drive's 12.78. Expert I/O is 82.5% of decode time, so your storage is the model's speed. And the headline number is a floor, not a target: the measured useful-throughput window on the test machine was 46–52 GB of RAM, meaning a literal 32 GB box gets the demo rather than the throughput. The thread asked the only question worth asking — why not just pay OpenRouter for K3? — and nobody answered. The honest answer is that you shouldn't, unless the entire reason you're doing this is that the weights and the prompts must never leave the machine.

Reach for it when the requirement is custody rather than throughput: a frontier-scale model that provably never phones home, chewing through a queue overnight on hardware you own. Delete the assumption that trillion-parameter inference starts with a rented cluster. Tradeoffs: half a token per second is not a conversation, it's a batch job; a terabyte of internal SSD is a real purchase before you type the first prompt; chat.json ships pre-configured for K3 alone and any other model needs hand transcription; and expert checksums are off by default because verifying them costs 5% throughput.

A Rust runtime (Apache-2.0, 16 stars, created two weeks ago) doing the same trick generically. Any quantized GGUF stays file-backed through mmap, host residency is capped by an explicit --ram-budget, and the CUDA and Metal paths size resident weights and caches from detected free VRAM instead of guessing from device-name presets. Its own headline: a 222 GiB model served under a 32 GiB host budget at a median 42.44 s prefill and roughly 2.6 seconds per token. It handles Llama, Phi, Gemma, Qwen dense and MoE, Nemotron-H and GLM-DSA; targets Linux and macOS CPU, Android arm64, CUDA, Metal and experimental Vulkan; serves an OpenAI-compatible API. No conversion step, no sidecar cache files, no silent requantization.

The count is the story here, not the project. Three independent weight-streaming engines have landed in ninety-six hours — TurboFieldfare in Swift and Metal for one Gemma checkpoint (back on the front page today at 896 points with nothing new since we covered it), WASTE in C for one Kimi checkpoint, and this one in Rust for whatever GGUF you happen to have. The 07-30 note asked whether the SSD-as-expert-store technique would generalize past one model on one OS. It generalized twice in two days, which is faster than the idea took to acquire a name. This is by a wide margin the least mature of the three — thirty-four commits, pre-1.0, single-owner and single-generation by design — and it's here for the trajectory, not the polish.

Reach for it when you want to try a model larger than your machine without adopting a bespoke engine per checkpoint. Delete the "just download a smaller quant" reflex. Tradeoffs: sixteen stars and two weeks of history mean you are the QA; it is explicitly not multi-tenant, one generation at a time; the API is pre-1.0 and says so; and the performance envelope swings hard with your storage and your model, so 2.6 s/token is their number on their hardware. That makes seven consecutive editions carrying a vendor-measured headline figure nobody outside the vendor has reproduced. At this point the streak is the finding.

MIT, 310 stars, npx tinbase start, or a 58 MB single executable that needs no Node, no npm and no Docker. Inside it: real PostgreSQL 17 with row-level security, auth (email/password, OAuth, magic links, OTP), storage, realtime, edge functions, webhooks, cron, and a Studio-style dashboard at /_/. It works with @supabase/supabase-js unchanged and follows Supabase CLI migration conventions. Three database engines ship in the box — native Postgres 17, PGlite for WASM, and a pure-JavaScript pgmem — so the same code runs on your laptop or inside a browser tab. 168 integration tests. The comparison it leads with is the one that matters: 58 MB against Supabase's local Docker install at 2,291 MB, roughly 16–24× less memory in use.

Same move as the two picks above it, one layer up the stack — the artifact didn't get smaller, the part that has to be resident did. It also lands exactly where agent work hurts. A local Supabase stack is a dozen containers, and a dozen containers is what a fanless laptop running four agents cannot afford; yesterday's merge-queue pick existed for precisely that reason. Created three weeks ago, v0.11.1, 170 commits, and the alpha warning is on the first screen rather than buried in an FAQ: "not production-ready yet. Great for local development, prototypes, and embedded/browser use."

Reach for it when local development against Supabase means waiting on Docker Compose. Delete the container stack from your dev loop — not from production. Tradeoffs: alpha means alpha, and shipping this as your production backend is not what the author is claiming; compatibility is per-feature rather than guaranteed, so the edges of the API surface are where the gaps will be; and 9 points on Show HN means essentially nobody has stress-tested the compatibility claim yet.

The opposite answer to the same problem: don't run one at all. A CLI wrapper that leases a clean, full copy of Supabase's services — Postgres, Auth, Storage, Realtime — in about 400 ms, applies your SQL migration files, injects SUPABASE_URL, SUPABASE_ANON_KEY, DATABASE_URL and the rest into the wrapped command's environment, then releases the instance when that command exits. Default TTL is 30 minutes and nothing survives release. Instances provision near where the agent is working rather than in a fixed region, which is where the 400 ms comes from. Free during beta, with an npm package for programmatic use.

The use case is precise and it is the fleet again: four coding agents in four worktrees, each running migrations against the same local database and each breaking the other three. agentOS (07-30) gave every agent a sandbox; this gives every agent a database, which was the piece nobody had shipped. The founder's answer on resource cost, in-thread: the instances are lighter than their production equivalents, trading durability and HA promises for agent speed. The thread's better catch was the name — swyx asked about the Supabase affiliation, Supabase's own co-founder turned up to say they don't sue but do sometimes ask politely, and the founder conceded a rename is likely once more databases get added. Worth knowing before you hard-code it into a Makefile.

Reach for it when parallel agents are corrupting each other's development database. Delete the per-worktree Docker Supabase and the migration-collision ritual. Tradeoffs: hosted and closed, so your schema, your migrations and any seed data transit a third party — a beta-stage one; free-during-beta means the price is unknown, which is the wrong fact to be missing about something in your inner loop; every instance is wiped on release by design, so treat anything you care about as already gone; and the name is likely to change under you.

The kicker, because the four picks above just made your machine harder to reason about: weights that live in a file, a backend that's one binary instead of twelve containers, a database that exists for 400 ms and then doesn't. witr answers the question that follows. Point it at a process, a PID, a port, a container or a file and it traces the chain that explains it — what started it, when, from where — where ps, top and lsof only report what exists. Apache-2.0, Go, one static binary for Linux, macOS, Windows and FreeBSD, installable from Homebrew, apt, winget, scoop, npm, conda or go install. Interactive TUI with tabs for processes, ports, containers and file locks; --short for one-line chains and --json with meaningful exit codes for scripts. Read-only, so it's safe to point at production. 18.4k stars.

It crossed our pool twice in May as a trending Go repo and we never covered it; it launched on Product Hunt today at #7 with 102 votes, which is how a tool with eighteen thousand stars arrives looking like a new product. The reason it's a pick rather than a footer line is the port question specifically. Anyone running lanes of agents has a dev server per lane, a container runtime underneath, and now an ephemeral database client on top — and the characteristic failure isn't a crash, it's two things quietly bound to the same port with one of them silently losing. Provenance is the missing column in every tool that already tells you a port is busy.

Reach for it the next time something is listening on 3000 and nobody knows what. Delete the lsof -i | grep muscle memory and the pkill guesswork. Tradeoffs: it explains provenance, not behavior — it tells you what started a process, never why that process is wrong; container coverage depends on the runtime it can see (Docker, Podman, Kubernetes, LXC/LXD); and it's a diagnostic, so it earns its keep entirely on the day you need it and sits idle the rest of the year.

Also worth knowing. trailofbits/skills (6,362 stars, CC-BY-SA-4.0, /plugin marketplace add trailofbits/skills) is 40-plus security skills for Claude Code and Codex — C and Rust review, differential and variant analysis, mutation and property-based testing, constant-time analysis, YARA authoring, smart-contract auditing — with a trophy case that includes a timing side-channel in ML-DSA signing. That resolves the 07-17 and 07-28 vendor-skills watch in a shape we didn't predict: not a vendor shipping skills for its own product, but a security consultancy shipping its audit methodology as installable artifacts. AgentHound (Apache-2.0, 133 stars, DEF CON 34 Red Team Village) maps the other direction — reconnaissance and attack paths across MCP servers, A2A, LiteLLM gateways, unauthenticated Ollama, Qdrant, MLflow, Jupyter and twelve agent client formats, with 19 prebuilt attack-path queries and 35 detection rules mapped to OWASP and MITRE ATLAS. Note the posture: it performs active exploitation, so it belongs in an authorized engagement and nowhere else. ZeroShot partly grades the 07-30 fleet-metering watch — free macOS CLI plus a hosted team tier that monitors coding-agent sessions, extracts repeated patterns into skills ranked by tokens saved, and blocks PRs where a required skill didn't run. That's team attribution with per-PR receipts; the watch asked for per-agent-within-a-swarm attribution, which still doesn't exist. Their 3.7× and 90% figures are pilot-team numbers. Stacked pull requests reached public preview on all GitHub repositories: each PR targets the layer below it, lower layers rebase automatically when upper ones merge, gh extension install github/gh-stack, merge-queue support rolling out over coming weeks — yesterday's pick was a local merge queue built because agents produce ninety commits a day, and this is the platform arriving at that problem from above. axonhub (Apache-2.0/LGPL-3.0, 4.8k stars, Go) is the routing thread's self-hosted option after Echo (07-24), Cactus and Tokenless (07-30): call Claude with the OpenAI SDK or GPT with the Anthropic SDK, plus per-request cost breakdown, quotas and sub-100 ms failover. And CTGT distilled DeepSeek V4 Flash into GPT-OSS-120B on finance reasoning and measured whether the teacher's politics came along: across 152 matched prompt pairs the teacher scored +45.45 higher on China-sensitive prompts than on controls, while the student showed no statistically significant difference from its untouched base. 20B weights on Hugging Face, LineageEval's 304 prompts and eval code on GitHub. Research rather than a product, but it's the empirical half of an argument that has been running on assertion.