Every week, the open-source community ships projects that make you stop and think — sometimes because they’re audacious, sometimes because they solve a problem so elegantly you wonder why nobody did it sooner. This week’s batch includes a 744-billion-parameter model running on a consumer desktop, Postgres rebuilt in Rust, Python compiled straight to machine code, and two tools that make developer life tangibly better. Let’s get into it.
1. JustVugg/colibri — Running a 744B Model on 25 GB of RAM
Colibri (Italian for “hummingbird”) is a single C file that runs GLM-5.2 — a 744-billion-parameter Mixture-of-Experts model — on a consumer machine with roughly 25 GB of RAM. No GPU, no Python runtime, no BLAS. Just C.
The trick is exploiting the MoE architecture. GLM-5.2 activates only about 40B parameters per token, and only ~11 GB of those change between tokens (the routed experts). Colibri keeps the dense part — attention, shared experts, embeddings — resident in RAM at int4 quantization (~9.9 GB), while the 21,504 routed experts live on disk (~370 GB total) and are streamed on demand with a per-layer LRU cache.
The engine implements several sophisticated optimizations: MLA (Multi-head Latent Attention) with compressed KV-cache that’s 57× smaller than the naive version, native MTP speculative decoding using GLM-5.2’s own multi-token-prediction head (achieving 2.2–2.8 tokens per forward pass), DSA sparse attention via the model’s lightning indexer, and async expert readahead that overlaps disk I/O with computation. The FP8-to-int4 converter downloads and processes one shard at a time, so the full 756 GB FP8 checkpoint never needs to exist on disk at once.
The author is upfront about the numbers: cold decode is slow (~0.05–0.1 tokens/second), bottlenecked by disk read speed. But warm caches, pinned hot experts, and MTP speculation bring useful-response latency down considerably. The point isn’t speed — it’s that a frontier-class model answers correctly on a machine that costs less than one H100 cooling fan.
2. malisper/pgrust — Postgres Rewritten in Rust
Pgrust is a from-scratch rewrite of PostgreSQL in Rust that currently passes 100% of the Postgres regression test suite — over 46,000 queries. It targets compatibility with Postgres 18.3 and is disk-compatible: it can boot directly from an existing Postgres data directory.
The project’s stated goal isn’t to replace Postgres but to make it easier to change from the inside. By keeping behavior Postgres-shaped and using the real Postgres tests as the oracle, pgrust aims to explore deeper architectural changes that the original C codebase makes difficult — multithreaded internals instead of process-per-connection, built-in connection pooling, no-vacuum storage designs, and runtime guardrails for AI-generated SQL.
The results from the upcoming (not-yet-published) version are striking: a thread-per-connection model, 50% faster than Postgres on transaction workloads, and roughly 300× faster on analytical workloads — about 2× slower than ClickHouse on clickbench, with the developers believing they can close that gap. The project was built heavily with AI-assisted programming, which the author documents in a series of blog posts linked from the repo.
Pgrust is not production-ready. Existing Postgres extensions and procedural languages (PL/Python, PL/Perl) aren’t compatible yet. But the regression-test milestone is a serious technical achievement, and you can try it via Docker or a browser-based WebAssembly demo.
3. can1357/pon — Python 3.14 Compiled to Metal
Pon is a JIT and ahead-of-time native compiler for Python 3.14, written in Rust. There is no interpreter and no bytecode — every module is parsed with the ruff parser, lowered to a shared IR, and compiled to machine code via Cranelift. Memory is managed by a Green Tea garbage collector instead of CPython’s reference counting.
The project enforces correctness through a differential testing harness: a module passes only if pon produces byte-identical output to CPython v3.14.0. Currently, 244 corpus modules pass under the JIT, with 206 also passing when compiled ahead-of-time into standalone native executables. The conformance suite is ratcheted — passing sets are committed as floor files, and CI fails on any regression below the floor.
The architecture is a multi-tier compilation pipeline. Tier-0 compiles everything boxed with no type feedback (the correctness baseline). Runtime helpers feed type profiles from the first execution, and hot functions recompile on a background thread with inline caches and on-stack replacement. The same IR feeds both the JIT backend (cranelift-jit) and the AoT backend (cranelift-object), sharing one runtime ABI.
The end goal is ambitious: “the bun/v8 of Python” — a runtime that passes the full CPython test suite, runs a multi-tier JIT well past CPython’s performance, and ships single-binary executables with batteries included. It’s early (the CPython test suite bring-up is the current grind), but the architecture is clean and the differential approach is the right way to build trust.
4. 514-labs/dnsglobe — DNS Propagation on a World Map in Your Terminal
Dnsglobe is a Rust TUI that queries 34 public DNS resolvers worldwide in parallel and visualizes the results on a world map — think whatsmyDNS, but in your terminal, with watch mode that re-polls until a record has propagated everywhere.
Beyond the core propagation checker, dnsglobe packs in features that network engineers will appreciate. Each resolver is queried directly (no intermediate cache, with EDNS0 and TCP fallback), so what you see is each server’s actual current view. EDNS Client Subnet support lets you query as if from a specific network — essential for debugging GeoDNS configurations. Anycast networks (Google, Cloudflare, Quad9, OpenDNS) are asked which POP is answering, and resolver dots move to the actual serving location on the map.
The visual design adapts to terminal width: wider terminals get a flat world map, narrower ones get a spinning 3D globe, and resizing morphs between them. You can add custom resolvers via a TOML config file, which makes it useful for watching propagation across your own nameservers. Available via Homebrew, cargo, AUR, and Nix.
5. rowboatlabs/rowboat — An Open-Source AI Coworker with Persistent Memory
Rowboat is a desktop AI assistant that indexes your work — email, meetings, Slack, conversations — into a living, Obsidian-style knowledge graph stored locally as plain Markdown. Instead of reconstructing context on demand through retrieval, it maintains long-lived knowledge where relationships are explicit and inspectable.
The built-in work surfaces go beyond chat: an email client that triages and drafts responses using accumulated context, a local meeting note-taker that transcribes and summarizes, an isolated browser for collaborative web tasks, and a code mode that spins up parallel sessions with Claude Code or Codex. Background agents can trigger on events (new email) or schedules, and connect to external tools via MCP.
Rowboat supports both local models (via Ollama or LM Studio) and hosted APIs, and all data stays on your machine — no proprietary formats or hosted lock-in. It’s a Y Combinator S24 company with native apps for Mac, Windows, and Linux.
Wrapping Up
This week’s repos span an unusually wide range. Colibri pushes the boundary of what’s possible on consumer hardware with frontier models. Pgrust and pon both tackle “rewrite a foundational system in Rust” — one for databases, one for Python — and both use rigorous differential testing to prove correctness. Dnsglobe is a focused, well-executed tool that makes a common ops task visual and pleasant. And Rowboat represents the growing wave of local-first AI assistants that treat memory as a first-class concern.
If any of these catch your interest, the links above go straight to each project’s repository. Star the ones you find useful — it helps maintainers gauge interest and helps others discover quality work.