The post on September 19 ended with this: the map of my own environment had drifted in four places over three months, and the next thing I’d work on was a way to catch drift sooner. I built the catching part that same day, the 19th. I’ll get to it in the second half. First, the rules my upkeep runs on when it fixes drift, and what they found. I borrowed those rules in July, from one of three AI memory projects I looked at.
On Saturday mornings a scheduled task digs through Reddit, Hacker News and GitHub for “OSS ideas one person could build” and appends them to a note. It is the machine’s way of answering the question from the previous post: what to build next. Each seed comes as a card with fixed fields: the pain, the evidence, what already exists, the smallest version, the risk. The first Saturday produced one seed, a tool to look at how Claude Code spends thinking tokens.
Someone pointed me at a product called Basic Memory. Its tagline is “Real memory for your AI. A knowledge base you own.” It keeps the Markdown your AI reads and writes on your local machine, builds full-text, semantic, and graph indexes on top, and serves it all over MCP so any client can query it. The product site says 3K+ GitHub stars and 57K downloads a month. The local version is free and open source, and cloud sync starts at $15 a month.
After building a tool that audits the listening ports of local AI services, I started thinking about what to build next, and looked at what is trending. Skimming GitHub trending and the recent news, it comes down to three things: agent frameworks themselves, bundles of Claude Code skills and hooks, and security for MCP and agents. The first two already have plenty of lookalikes, so an individual’s version sinks without a trace. In the third, there were static scanners for agent code, tools that actively probe an MCP server, and enterprise SaaS. Something that shows “how the MCP servers registered on my machine are exposed right now” was not something I could find.
The previous post ended by saying that not many people have run lsof even once to see what is listening on which address. What that check actually turned up was not the vulnerability I was looking for, but an old Ollama that had kept running after an update. And the person who wrote that post had not run the check against anything other than Ollama. If you keep LM Studio or llama.cpp running, doing the same check means looking up each product’s port, running lsof, and sending a forged header with curl, once per product. I had done it once and called it a day.
In late August, an article came through about a vulnerability targeting exactly that Ollama. Open one malicious web page, and an attacker can permanently plant instructions inside the model running on your machine. The note where I keep a map of my environment has a single line about it: “homebrew.mxcl.ollama, always running.” Always running means it’s listening on some port for something. I had written that line down and never once looked at what it was.
I’ve been making nukazuke for a bit over a year now. Cucumber, carrot, daikon, turnip. They taste exactly as good as you’d expect. So far, nothing surprising.
What I didn’t see coming is that after a year, the best thing to come out of the pot wasn’t a vegetable at all. It was the dried goods I’d been throwing in to keep the bed from going watery.
Salt pulls water out of the vegetables. Obviously that water ends up in the bed. The more you pickle, the looser the bran gets, the more the flavor goes flat, and if you leave it long enough the whole thing spoils. Day-to-day maintenance of a nukazuke pot is almost entirely a fight against water.
Two pieces of news pointed in opposite directions this July.
One was the official announcement of Kimi K3: 2.8 trillion total parameters, the largest open model out there, beating Claude Fable 5 and GPT-5.6 Sol on some coding benchmarks (while Moonshot themselves frankly admit it still trails both overall). Make the model bigger, buy more performance. The straightforward direction.
The other went the opposite way. Schema, a reasoning harness, reports solving 98.98% of the ARC-AGI-3 public set with a combination of Claude Opus 4.8 and Fable 5. It doesn’t touch the model weights at all. What it changes is the scaffolding around the model: how observations become a world model, how predictions get tested, and where to start fixing things when they miss. On the same public set, GPT-5.6 Sol alone scores 13.33%; put Schema around it and it reaches 95.35%. Same model, over 7x the score, from outside design alone. And these are the same models I use every day.
A while back, I wrote a post called “Permissions have a range.” Tell an AI “you can push” once, and it will carry that permission into other repos and other tasks on its own. So a permission is bounded along three axes — repository, task, and kind of operation. I logged the failure in an external memory file called mistakes.md, dropped the operations I really cared about into git-layer hooks, built the whole two-layer defense, and closed with “I’ll probably pay this tuition a few more times yet.”
On July 7th (local time), Anthropic announced a five-day extension to the free window for Claude Fable 5. The new deadline is 3:59 PM JST on the 13th. In an earlier post, I wrote about having Fable 5 rebuild my external-brain workflow rules — not an article, not code — before its free window closed. Figuring I might as well use the extension, I picked up where that left off: a much more thorough redesign of my whole Claude Code environment. Once it was done, I had Ultracode (a feature that runs multiple agents in parallel) ask “does this actually work?” — and it turned out a safeguard I’d been running for two weeks and one I’d only just added that day, built at wildly different times, had the exact same kind of hole in them. That interrogation wasn’t free, either.