One of the weirdest problems I keep running into when using AI in my daily workflow is what I call AI amnesia.
Or in Indonesian: AI pikun.
At first, it sounds harmless. The AI forgets things. We remind it. Life goes on.
But the more I use AI agents for coding, the more I realize this “forgetfulness” is not just annoying. It quietly costs money.
And for people like me, a tiny-paycheck developer living on a very non-Silicon-Valley salary, that matters.
The Context Window Is Not Infinite
When we work with AI coding agents, we usually keep feeding them context.
Project structure. Business logic. Existing bugs. Previous decisions. Files we already checked. “Don’t touch this part.” “This endpoint is legacy.” “That function is used by another service.”
And so on.
At some point, the context gets too long.
When that happens, many AI tools or terminal-based agents will start doing some kind of compaction or summarization. The idea is reasonable: compress the previous conversation so there is still room inside the context window.
In theory, this is good.
In practice, every compaction is also a tiny memory loss event.
The AI may still remember the “main idea,” but some details slowly disappear. A file name. A constraint. A decision we made thirty minutes ago. A warning that looked small but was actually important.
Do this once, maybe fine.
Do this many times, especially with a smaller context window or a poorly configured model, and the agent starts becoming that one coworker who says, “Wait, can you remind me again what this project does?”
Except this coworker bills you per token.
Starting a New Session Is Not Free Either
The obvious solution is: “Just start a new session.”
But this also has a cost.
When we start a fresh session, the AI no longer has the working memory from the previous one. So it has to learn the project again.
Usually this means the agent starts doing the same ritual:
lsgrepfindrg- open file
- read file
- read another file
- search again
- summarize architecture
- guess where the logic lives
- repeat
From the outside, it looks like the AI is “understanding the codebase.”
But from the billing side, it is still token usage.
And if you do this again tomorrow, or in another branch, or in another session, the cost repeats.
This becomes more obvious when working on multiple features at once. Imagine you want to update three different features in three different branches. Each branch may need its own session. Each session may scan the same project again. Each one pays the “hello, please introduce me to this codebase” tax.
That is the part that hurts.
Not because the AI is useless. The AI is very useful.
But because we keep paying for the same context discovery again and again.
The Real Problem: AI Agents Do Not Have Stable Project Memory
I think the core issue is not only “context window size.”
The deeper issue is that many AI workflows still treat context as something temporary.
The agent learns your project inside one session. Then the session gets compacted. Then it forgets some things. Then you start a new session. Then it learns again. Then you pay again.
It is like hiring a very smart intern who becomes productive after reading your codebase, but every morning their memory resets.
So I started looking for open-source tools that might help reduce this “AI dementia” problem.
Not eliminate it completely. That sounds too magical.
But at least reduce the repeated grep/read/relearn cycle.
So far, I found two interesting repos that seem to handle two different but related problems.
1. Lexa: Helping AI Understand Large Codebases
The first one is Lexa by @indrazm.
From what I understand, Lexa is more about codebase intelligence. It turns a codebase into a portable, queryable graph that can be used for search, context, dependency tracing, and safer edits. The README describes the workflow as: index once, then query from the CLI, editor, or MCP client.
This is interesting because the normal AI-agent workflow is often very wasteful.
Without an index, the agent has to keep discovering the codebase manually:
- “Where is this function?”
- “Who calls this?”
- “What files are related?”
- “What changed recently?”
- “What should I read before editing this?”
Usually the answer is more grep, more file reading, more token usage.
A tool like Lexa feels useful because it gives the AI a more stable project map. Instead of asking the model to blindly wander around the repo every time, we can give it structured ways to retrieve relevant context.
It is more like:
“Bro, stop scanning the entire project again. We already indexed this thing.”
That alone could save a lot of repeated context cost.
2. Uteke: Giving AI Long-Term Memory
The second one is Uteke by @ajianaz.
This one seems to focus more on persistent memory. Its README describes it as an offline-first semantic memory engine that lets AI store, recall, and search memories locally. It also mentions hybrid search using vector similarity plus SQLite FTS5, and MCP support for tools like Claude Code, Cursor, and Hermes.
This solves a different problem.
Lexa helps the AI understand the codebase.
Uteke helps the AI remember things across sessions.
For example:
- “Use this naming convention.”
- “This client prefers simple REST APIs.”
- “We already decided not to use Prisma here.”
- “This deployment uses staging branch first.”
- “This repo has a weird auth flow, be careful.”
These things are not always inside the codebase. Some of them live in conversations, decisions, preferences, or team habits.
And when the AI forgets those, we waste tokens explaining them again.
So Uteke feels like a possible layer for long-term working memory: not just “read the code,” but “remember the decisions around the code.”
Two Different Problems, Both Expensive
This is the important distinction for me:
Lexa is closer to “super grep with structure.” It helps the agent find and understand code faster.
Uteke is closer to “long-term memory.” It helps the agent remember facts, decisions, and context across sessions.
Both are trying to reduce the same painful pattern:
AI forgets → AI searches again → AI reads again → AI asks again → we pay again.
For people with big budgets, maybe this is just a small inconvenience.
For budget-conscious developers, indie hackers, freelancers, and tiny-paycheck employees like me, this is a real cost.
Especially when using paid models every day.
This Is Not Anti-Compaction
To be fair, compaction is not evil.
It exists because context windows are limited. Without compaction, long-running sessions would become impossible or extremely expensive.
The problem is expecting compaction alone to behave like perfect memory.
It does not.
A summary is still a summary. It compresses. It drops things. It makes judgment calls about what matters. Sometimes those judgment calls are wrong.
So instead of relying only on chat history, maybe the better workflow is:
- Index the codebase.
- Store important decisions.
- Retrieve only what matters.
- Avoid re-reading the same files again and again.
- Stop treating every new session like day one at the company.
The Takeaway
I am not saying Lexa or Uteke is the final answer. I have not fully tested both in a real long-running production workflow yet.
But the direction feels right.
AI coding is not only about having a smarter model. It is also about building better context infrastructure around the model.
Because if the model keeps forgetting, and we keep paying to remind it, then the problem is not just intelligence.
It is memory economics.
And honestly, for us tiny-paycheck developers, that might be the difference between “AI makes me faster” and “AI silently eats my monthly budget.”
The repos: Lexa by @indrazm | Uteke by @ajianaz
Want to talk about AI workflows, automation, or how to stop burning tokens for nothing? Let’s talk.