This week on one Mac mini: Polars 2.0 beats the cache trick 25×, uv 0.12.11 re-run, and what GPT-6 got right about our videos

A new weekly note. The rule is simple: an item makes the list only if we measured something on this machine, or if it changes what you should check before adopting a tool. Plain news does not qualify. Everything below was run this week on a Mac mini M4 Pro with Python 3.14.6, five runs each, medians.

1. Polars 2.0 release candidate versus the cache trick (measured)

Last week's video found that a script parsing one million date strings spent most of its time in strptime, and that caching the parser took it from 3.71 s to 1.20 s. Then Polars announced its 2.0 pre-release. Same data, same report, three versions of the script:

365 distinct dates (1,000,000 rows)      whole process   inside script
plain report.py                              3.36 s          3.10 s
cached parse_date (lru_cache)                1.29 s          1.03 s
Polars 2.0.0-rc.1                            0.13 s          0.04 s

1,000,000 distinct dates (no repeats)
plain report.py                              3.32 s          3.06 s
cached parse_date (lru_cache)                3.51 s          3.24 s
Polars 2.0.0-rc.1                            0.12 s          0.03 s

Output files are byte-identical to the original script's, all 48 rows. The cache trick gave about 3× and only when inputs repeat; with unique inputs it was 6% slower than doing nothing. Polars does not care whether inputs repeat: 25× faster than the cached version, and the whole process, interpreter startup included, finishes in 0.13 s.

What it costs: a dependency, and the code is not a two-line change. The report becomes a read_csv, a str.to_datetime, a group_by and a sort. If the script is yours and small, the cache is the cheaper fix. If it runs every hour on real data, the rewrite pays for itself the first day.

res = (pl.read_csv(src)
         .with_columns(pl.col("date").str.to_datetime("%Y-%m-%d %H:%M:%S"))
         .with_columns(y=pl.col("date").dt.year(), m=pl.col("date").dt.month(),
                       rev=pl.col("qty") * pl.col("price"))
         .group_by(["y", "m", "region"]).agg(pl.col("rev").sum())
         .sort(["y", "m", "region"]))

This is a release candidate. Re-check when 2.0 final ships.

2. uv 0.12.11 shipped, so the benchmark got re-run (measured)

The uv write-up on this blog benchmarked 0.11.6. Version 0.12.11 came out this week, so the same eight packages, caches off, five runs, medians, all three tools back to back:

              create venv   install    full flow
pip 26.1.2       1.202 s     2.338 s     3.540 s
uv 0.11.6        0.150 s     0.383 s     0.533 s
uv 0.12.11       0.136 s     0.375 s     0.511 s

Install 6.2× faster than pip, full flow 6.9×. The two uv versions are within 4% on this workload, so upgrading is about features, not speed. The earlier numbers stand as a floor.

3. GPT-6 Astra designed our video format. Here is what it got right, and what two review rounds still caught (measured on our own footage)

GPT-6 Astra was the biggest story on Hacker News this week. We had already been using it through the Codex CLI for something specific: designing and reviewing a long-form video format. That is a paper trail, so here it is.

What the design pass got right, in its own terms:

Our ten-tool compilations were "eight independent transactions": after each tool, the viewer has finished a small transaction and can leave. It proposed "one problem investigated" as the unit, four minutes, with an unresolved question carried across every transition. We rebuilt the video that way.
It read our render frames, not just the script. It found that the stat text was 26 px at 1920 px width, "approximately 4.9 pixels" on a 360 px phone, and that the demos were "7.6–13.5 seconds each, less time than an individual Short". Both were true and neither had been noticed.
It refused to over-read our analytics: 32 views on one video "cannot settle whether walkthroughs work". A model declining to draw a conclusion from small numbers is worth noting.

What the two review rounds caught after the rebuild:

The headline "36%" was self-time inside a profiled run, and the 8.440 s denominator was cropped out of the frame. It asked for the label "36% self-time, profiled run" and the denominator on screen. Correct, and we had missed it.
A claim that "most of what's left is reading the CSV" had a number in the facts file but no measurement procedure behind it. It flagged the claim as unsupported until a loading benchmark existed. We ran one.
Caption timing: it computed that one highlight landed 2.88 s after the spoken number, using word-level alignment rather than the subtitle file. It was right.

What humans changed anyway: the intro sound design it did not object to was rejected by the person who actually listened; on-screen number callouts were cut because they read as narration; scene gaps were trimmed from 2.3 s to 1.1 s after a viewer complaint. Design review is not the same as watching.

4. Which tools do coding agents install? 16,893 sessions say the same thing (verify before adopting)

Armature ran Claude Code, Codex and Cursor across 75 repositories and 1,163 prompt variations, with the agents implementing the choice, not just recommending it. Their finding: different personas, different codebases, same picks per category. One caveat they state themselves: they sell growth services to dev-tool vendors, and the study is part of that work.

We cannot re-run 17k sessions. What we can say is what to check when your agent picks a service for you:

Ask for the alternatives it rejected and why. If it cannot name any, it did not compare.
Check the free tier's failure mode, not its price. The example in the study was a database that pauses when idle.
Pin the version it installs. An agent that picks the same tool every time will also pick whatever version is current today.

5. Spotify cut Claude Code token use by 90% with two cheap "modes" (verify before adopting)

The engineering post describes two declarative agents on Gemini 2.5 Flash, a bulk file reader and a boilerplate code writer, plus Claude Code hooks that block any Read over 350 lines and redirect it to the cheap reader. The 90% is their number on their workload.

This one is on our list to test, because our own Discord bot runs on Claude Code and stops when its allocation runs out. Before building it, three checks:

Measure your own split first. Their premise is that most tokens are I/O, not reasoning. If your sessions are mostly reasoning, the router saves little.
Rules in CLAUDE.md are advisory; hooks are enforced. Their first version, instructions only, "sort of worked". The hook version is the one that saved tokens.
The worker must output raw code. Without "output only the code", the cheap model wraps everything in prose the expensive model then pays to read.

If we run it, next week's note will have before-and-after numbers from this machine.

How the numbers were measured

Polars: polars_report.py against the original report.py and report_cached.py from the investigation video, same sales.csv (365 distinct dates) and sales_unique_all.csv (1,000,000 distinct), five whole-process runs each from a Python harness, medians, outputs compared byte for byte. uv: eight packages, --no-cache / --no-cache-dir, fresh environment every run, five runs, medians, pip 26.1.2, uv 0.11.6 and 0.12.11 installed side by side. Mac mini M4 Pro, macOS 26.6.1, Python 3.14.6.

Search This Blog

Homelab Notes