<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:content="http://purl.org/rss/1.0/modules/content/"><channel><title>Exp_037 on Local First AI</title><link>https://localfirstai.eu/tags/exp_037/</link><description>Recent content in Exp_037 on Local First AI</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Fri, 09 Oct 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://localfirstai.eu/tags/exp_037/index.xml" rel="self" type="application/rss+xml"/><item><title>We Stopped the Kolibri Benchmark Before Scoring One Answer</title><link>https://localfirstai.eu/posts/2026-10-09-we-stopped-the-kolibri-benchmark/</link><pubDate>Fri, 09 Oct 2026 00:00:00 +0000</pubDate><guid>https://localfirstai.eu/posts/2026-10-09-we-stopped-the-kolibri-benchmark/</guid><description>On Monday our own gate refused to certify our MLX port of Aleph Alpha&amp;#39;s Kolibri. We rebuilt the gate around forced expert routing and froze it before any run. The port passed in run 2 of three permitted, after a fix to a tokenizer-check cache in our kit keyed by object address, and again in run 3, after a workaround in our runner for a buffer leak in mlx-lm 0.32.0 that Kolibri&amp;#39;s layers expose; neither fix touched the port. Then our frozen plan rule, fed with Kolibri&amp;#39;s real answer lengths, put even the smallest scored run at 56 hours against a 31-hour laptop budget, and we stopped. There are no Kolibri quality scores here; there are four speed, memory, tokenizer and 4-bit numbers beside their pre-registered thresholds, with no verdicts.</description></item></channel></rss>