Hacker News

https://www.science.org/doi/10.1126/science.aei1285

https://www.macrumors.com/2026/07/10/apple-sues-openai/

https://x.com/__eknight__/status/2075643450196971805, https://xcancel.com/__eknight__/status/2075643450196971805

Prompt: https://cdn.openai.com/pdf/04d1d1e4-bc75-476a-97cf-49055cd98...

https://www.nyc.gov/mayors-office/news/2026/07/mayor-mamdani...

Over the years I often thought that there should be a calculator for Algebra that works this way... something where you can drag terms around and cancel & distribute with gestures, but most importantly enter your own problems. It should also do more kinds of problems than DragonBox allowed. So I finally decided to build it.

https://dicroce.github.io/wyrm/home.html

Here's a video showing it: https://www.youtube.com/watch?v=_STbS4zvIlU. If you'd rather just play with it: there's a limited in-browser demo (real engine, a few example equations, no download) on the landing page — https://dicroce.github.io/wyrm/home.html.

The app can be found on iOS (https://apps.apple.com/us/app/wyrm-math/id6782342042) and as of this week on Google Play (https://play.google.com/store/apps/details?id=com.dicroce.wy...).

I also decided to open source the underlying math engine so others could build on it: https://github.com/dicroce/wyrm_math. My goal for the engine btw is to build it all the way up to Calculus.

Monetization is deliberately boring: the engine is free (MIT), and the polished gesture app is $4.99 once. No subscriptions, ads, accounts, or analytics.

I'd love feedback on the engine design — especially from anyone who's worked on CAS or proof-assistant-adjacent problems. And if you played DragonBox as a kid and wished it went further: this is for you!

But then I thought, "I wonder how it would work on a normal computer like mine," and above all, "I wonder if it would work without going into OOM on a computer like mine." So I started working with the help of agents to test this possibility.

I started converting the model to int4, understanding MTP usage, and if possible implementing DSA for long context. How it responds in int4 and whether the quality is maintained or not. Until I got to the point, on my computer with 32GB of RAM, I was able to communicate with GLM 5.2 with times that, of course, aren't high in cold start, but even then, we're talking about 0.1 tok/s, but that wasn't important to me. The important thing was the journey to reach this goal. I just wanted it to work at all costs, even slowly.

So I created Colibrì, which was born from a very simple idea, to be honest, but tested in every way, where a 744B Mixture-of-Experts model activates only ~40B parameters per token—and only ~11 GB of those change from token to token (the routed experts). So:

The dense part (attention, shared experts, embeddings—~17B params) stays resident in RAM at int4 (~9.9 GB); The 21,504 routed experts (75 MoE layers × 256 experts + the MTP head, ~19 MB each at int4) live on disk (~370 GB) and are streamed on demand, with a per-layer LRU cache, an optional pinned hot-store, and the OS page cache as a free L2.

The engine is a single C file (c/glm.c, ~1,300 lines) plus small headers. No BLAS, no Python at runtime, no GPU.No GPU or serious hardware because I don't have that hardware so I can't test it on hardware that is more powerful than my computer.Colibrì is a one-person project, written and tested entirely on a 12-core laptop with 25 GB of RAM — the numbers above are the ceiling of what I can measure at home.

Any feedback is welcome! (and if anyone wanted to participate in the project I would be delighted)

Repo: https://github.com/JustVugg/colibri