Your AI Notes Are Rotting: What a r/LocalLLaMA Thread Gets Right
A 53-comment r/LocalLLaMA thread maps which AI knowledge rots in weeks and which survives years. Benchmark scores decay first; your own decision inputs last.
On October 30, a developer posted on r/LocalLLaMA: "AI changes so fast, any saved knowledge gets outdated." The post collected 47 upvotes and 53 comments, and nobody in the thread had a clean answer. But the comment section did something more useful than answer. It mapped out which kinds of AI knowledge rot within weeks and which kinds stay useful for years, and the pattern is consistent enough to act on.
Full disclosure before we start: we build agent memory tooling (Uteke), so we have a dog in this fight. We'll mark the part where we talk about our own product. The findings section stands on its own, and if it doesn't, the rest doesn't matter.
What the thread actually says
The original poster's complaint is specific, not generic doomerism:
"I keep notes/bookmarks and almost none of them seem relevant now. eg when Qwen 4 is out, all the current 3.8 models/variants get forgotten, just like 3.6."
"when it comes to agentic coding and best practices... there is no consensus and you'll get a million answers."
The top comment (40 points) is sarcastic: "old models stop working five seconds after each new release." That sarcasm is the interesting part. Half the thread pushes back on the doom, because models don't actually stop working when a new one ships. But nobody defends the bookmarks. The disagreement is about how fast models age, not about whether saved notes age faster than they should.
The rot taxonomy hiding in the comments
Read the comments side by side and a classification falls out on its own.
Fastest to rot: benchmark scores and model names. One commenter:
"i stopped bookmarking benchmark scores and started saving prompts that worked well. those age a lot slower than model names"
Another described the feeling of running into old bookmarks:
"I still have bookmarks about WizardLM and Llama 3. Looking in that general area of my bookmarks make me feel almost uncomfortable, like damn we used to live like that?"
These are snapshot conclusions, of the form "model X scores Y today," and they decay the moment the next release lands. The knowledge isn't wrong so much as it stops answering a question anyone is asking.
Slowest to rot: reasons, not results. Another commenter agreed about the bookmarks and pointed at the one category of notes that stayed alive:
"the only notes that still help are the ones where i wrote down why something worked for me"
Reasons survive because they transfer. Why a prompting pattern worked, why one setup beat another on your hardware: those survive the arrival of model Z, because they describe mechanisms and trade-offs instead of leaderboard positions.
Survives best: your own tests, with inputs attached. The most substantive comment in the thread is worth quoting at length:
"the notes aren't the problem. you're re-deciding the same thing every release because you never kept the inputs. i keep a folder of eight tasks i actually run. a real refactor, a 40k-token context pass, a tool-call chain, one that has to compile. every new model gets the same eight, same prompts, outputs side by side. twenty minutes and the decision is made."
This reframes the whole problem. Knowledge always decays; that part is normal. The actual failure is storing the conclusion ("use model X for refactors") without the inputs (the tasks, prompts, and outputs the conclusion came from). Store the inputs and a new model release becomes a twenty-minute re-run instead of a research project. Store only the conclusion and every release invalidates it wholesale.
The infrastructure gap is real too. A subreddit moderator in the thread tried to maintain a community wiki and hit the wall:
"every time i start writing things up, everything churns and what i've written becomes obsolete before it has a chance to be published."
The same commenter later landed on the shape of a fix: "maybe the solution is to maintain a RAG database of up-to-date LLM tech details, and query models backed by that database?" The thread accidentally designed its own solution.
The re-deciding tax
Put the pieces together and the real cost isn't stale notes. It's re-deciding. When your reasoning inputs aren't stored:
- Every new model release re-opens decisions you already made.
- Your old conclusions can't be partially updated, only distrusted wholesale.
- The safe move becomes paralysis or hype-chasing, because you have no baseline to diff against.
One commenter described exactly this surrender: after each new model they had to rework their setup, something broke, and they gave up for now, staying on one or two favorite models.
Three different commenters arrived at the same shape without coordinating: a queryable store of your own reasoning where time is a first-class dimension. One wanted a personal RAG database. One proposed an Obsidian vault fed by a testing playground. One just keeps a folder of eight tasks with outputs filed side by side. Different tools, same shape.
Where Uteke Cloud fits (our part)
We built Uteke because we kept hitting this exact wall in our own team: agents re-deciding things across sessions, half-remembered context, no way to ask "what did we conclude and why back then?" If the findings above resonate, here is how the pieces map. Take it as one option, not a sermon. A plain folder of test results, run with discipline, is a perfectly good system.
What the thread's requirements look like in Uteke:
- Recall by meaning, not filename. The wiki problem is lookup: "ship the release" won't grep-match "deploy v2.1." Uteke fuses semantic vector search with full-text search, so your notes answer questions instead of exact phrases. On the public LongMemEval-S benchmark (500 questions, retrieval only, raw outputs committed to the repo) it scores 98.2% recall@5 at roughly 45 ms per query, with zero LLM tokens in the retrieval path.
- Time as a dimension, not a deletion. Knowledge rot breaks wikis because old facts must be edited or forgotten to stay useful. Uteke supports point-in-time recall (
uteke recall "deploy" --at 2026-08-01), supersede and contradicts edges in its relationship graph, and decay scoring for stale memories. When Qwen 4 ships, you don't delete your Qwen 3.8 notes. You supersede them, and the history stays queryable. - Inputs and conclusions live together. Decisions, test results, and the reasoning behind them sit in one store, tagged, attributed to whoever or whichever agent wrote them, and searchable by meaning.
- Every agent reads the same memory. This is the part that is genuinely hard to DIY. The eight-task routine helps one person; your coding agent, your chat assistant, and a teammate's session all still start from zero. Uteke Cloud, the hosted version at uteke.app, puts one memory behind one URL: add https://uteke.app/mcp to Claude, ChatGPT, Cursor, or anything that speaks MCP, sign in, done. No server to run.
- No lock-in, because the whole point of the thread is that things change. The free plan in open beta includes 500 memories and 150 recalls a day, no card. Full export as NDJSON any time. The engine itself is Apache-2.0 open source, the same engine, runnable offline on your own machine if you'd rather keep everything local. Recall is search, not generation: no model reads your memories unless you switch optional features on, and secrets are masked before storage.
That's the honest version. The discipline is still yours; someone has to write down why things worked. The tool's job is to make those notes findable by every agent you use, and to make obsolescence visible instead of silent.
What survives the next release
- Stop bookmarking conclusions. Benchmark scores and model names are the fastest-rotating artifacts in the thread. Save the reasons and the trade-offs instead.
- Store your decision inputs. A small, fixed set of real tasks, re-run against every new model with outputs filed side by side, beats a thousand bookmarks. Twenty minutes per release, as that commenter put it.
- Make knowledge queryable and timestamped. Decay itself is normal. Decay that stays invisible until it misleads you is the real problem. Anything worth saving should be searchable by meaning and honest about when it was true.
The thread is still open: r/LocalLLaMA, "AI changes so fast, any saved knowledge gets outdated". If you want the tooling version of the advice: uteke.app for the cloud version, or github.com/codecoradev/uteke for the open-source engine.