DEV Community: Vidyax

Why Does Your AI Coding Agent Start Forgetting What It Was Doing?

Vidyax — Tue, 22 Sep 2026 23:19:03 +0000

Why Does Your AI Coding Agent Start Forgetting What It Was Doing?

I've been working with AI coding agents for quite a while, and there's one behavior that keeps bothering me.

At first, everything looks fine.

The agent understands the task, reads the error, finds the relevant file, makes a change, runs the test, and moves forward.

Then, after several iterations, something strange can happen.

The agent starts going back to things that have already been fixed.

It reads old errors again.

It investigates files that are no longer relevant.

Sometimes, it even starts working on something that was already completed instead of focusing on the part that is still broken.

And the first thing we usually think is:

"The model is getting stupid."

But I'm not convinced that's always the real problem.

The context gets messy

When an AI coding agent works on a real software project, it doesn't only see the code.

It also sees a lot of other information:

framework logs

stack traces

dependency output

tool responses

terminal output

previous errors

repeated information

files from previous investigations

debugging attempts that are already finished

And this happens over and over again.

A long debugging session can look something like this:

Task
↓
Error
↓
Tool call
↓
Framework logs
↓
Stack trace
↓
Relevant code
↓
Patch
↓
Test
↓
New error
↓
More logs
↓
More tool output
↓
Another patch
↓
Another test
↓
...

The agent keeps accumulating information.

Eventually, the problem may not be that the context window is too small.

It may simply be that the context has become too noisy.

A bigger context window doesn't automatically solve this

This is something I've been thinking about for a while.

Even if an LLM has a very large context window, an agent can still fill that context with information that is no longer useful.

So the question isn't only:

"How much information can the model handle?"

It is also:

"How much of that information is actually useful right now?"

Imagine an agent is debugging a large application.

Early in the process, it discovers a problem in the authentication middleware.

It fixes the issue.

The tests pass.

The agent moves on.

Ten iterations later, that entire investigation is still sitting somewhere in the conversation alongside old logs, tool outputs, stack traces, and previous debugging attempts.

The agent can still see it.

But the useful state is much simpler:

Authentication middleware
→ DONE

Database transaction
→ STILL BROKEN

That distinction matters.

If everything remains in the context without a clear representation of what has already been resolved, the agent has to continuously work through information that may no longer be relevant to the current problem.

And that's where things get interesting.

This is why I started building Tokenectomy

Tokenectomy started from a simple idea:

What if we process the information before giving it to the agent?

Instead of blindly passing everything produced by the environment back into the model, we can try to:

remove unnecessary noise

keep the relevant information

extract useful context

preserve important state

redact sensitive information

reduce irrelevant output

The idea looks roughly like this:

Raw Environment
│
▼
┌─────────────────────────┐
│ logs / stack traces │
│ tool output / code │
│ terminal output │
└────────────┬────────────┘
│
▼
Tokenectomy
│
▼
Relevant Context + State
│
▼
AI Agent
│
▼
Action / Patch
│
▼
Test / Run
│
└──────────► Feedback

The goal isn't to make the underlying model magically smarter.

The goal is to make the information surrounding the model more useful.

Tokenectomy isn't just about saving tokens

This is an important distinction.

At first glance, something that removes unnecessary context sounds like a token optimization tool.

But I'm more interested in what happens after the cleanup.

If an agent receives less irrelevant information, does it make fewer unnecessary tool calls?

Does it repeat fewer investigations?

Does it stay focused on the remaining problem for longer?

Does its performance degrade less as the debugging session becomes longer?

Those are much more interesting questions to me than simply:

"How many tokens did we save?"

Tokenectomy is evolving into an infrastructure/tooling layer for AI agents, with things like MCP tools, context processing, code analysis, patching, and an AI Gateway.

But the technology itself isn't really the interesting part.

The interesting part is the hypothesis behind it:

Can better context management make an AI agent more reliable during long-running tasks?

I'm not saying context noise is always the problem

This is important.

I'm not claiming that every AI agent failure is caused by messy context.

Agents can fail for many different reasons.

The model can misunderstand the task.

A tool can return bad information.

The generated patch can be incorrect.

The test environment can be broken.

The agent can simply make a bad reasoning decision.

Context noise is only one possible factor.

But I've repeatedly seen situations where an agent starts revisiting old work during long debugging sessions.

So instead of saying:

"AI agents forget because their context gets messy."

I'd rather ask:

"What happens if we deliberately remove irrelevant context during a long debugging trajectory?"

That's something we can actually test.

Let's measure it

If this idea is real, it should show up in the data.

For example:

How many tokens are sent to the model?

How many iterations are required?

How often does the agent repeat completed work?

How often does it call irrelevant tools?

How often does it revisit previously resolved errors?

Does the final patch pass the tests?

How does performance change as the debugging session gets longer?

Does context cleaning reduce that degradation?

The goal isn't to make a nice-looking demo.

The goal is to find out whether this actually changes the behavior of an agent.

That's where Kronumos comes in

I'm also building Kronumos, a specialized software-repair agent, to experiment with this idea in a more focused environment.

Kronumos isn't meant to be another general-purpose coding assistant.

The idea is much narrower:

Bug
↓
Understand the failure
↓
Get relevant context
↓
Analyze the code
↓
Generate a patch
↓
Run tests
↓
Inspect the result
↓
Fix again if necessary

This gives me a controlled environment where I can experiment with different combinations of:

model + context + tools + execution feedback.

And that's the part I'm really interested in.

I'm not trying to claim that a small model is inherently smarter than a much larger model.

That's not the question.

The question is:

How much can system design, specialized training, better context, and a proper feedback loop affect the performance of an AI agent?

Because sometimes the model might not be the only problem.

Sometimes, maybe, we're just giving it too much garbage.

And that's the problem I'm trying to solve with Tokenectomy.

I'd love to hear from other developers

Have you ever had an AI coding agent suddenly start working on something it had already finished?

Or had an agent repeatedly investigate an error that you thought was already resolved?

I'm curious whether other people are seeing the same behavior in long-running coding sessions.

GitHub: [https://github.com/Tokenectomy-Labs/Tokenectomy]

How I Cut 45,000 Next.js Error Tokens to 118 in <0.2ms Using a Rust MCP Server

Vidyax — Tue, 15 Sep 2026 03:19:09 +0000

If you use Cursor, Claude Desktop, or Cline daily,
you have probably watched your rate limits evaporate
because of a single runtime crash.

A Next.js build fails or a Python script panics, and

your terminal vomits 500 lines of stack traces. The
LLM eagerly ingests all 45,000 tokens of internal
node_modules machinery, webpack bundles, and event
loop frames.

You just paid $0.15 for an AI model to read code it

can't edit, your prompt cache is wiped, and your agent
is now hallucinating because its context window is
full of garbage.

Worse, your terminal stderr probably just leaked

DATABASE_URL=postgres://admin:password@... straight
to an external API.

I got tired of paying for framework noise, so I

built an open-source Rust Model Context Protocol (MCP)
server called Tokenectomy Razor to fix it locally
before logs ever touch the LLM.

## What is eating your context window?

A typical Next.js error trace looks like this:


text
    TypeError: Cannot read properties of undefined
  (reading 'digest')
        at Object.<anon> (/node_modules/next/bundle5.
  js:142:31)
        at __webpack_require__
  (/node_modules/next/bundle5.js:198:12)
        at Object.execute (/node_modules/next/dev-
  server.js:412:19)
        at processTicksAndRejections (task_queues:95:5)
        Database connection failed:
  postgresql://admin:super_secret_password@db.prod.
  internal:5432/primary
        API key leaked: sk-ant-api03-
  abcdef1234567890abcdef1234567890
        [... 480 internal dependency frames flooding
  context ...]

  Notice three things:

  1. 98% of those frames are inside node_modules. Your
  AI agent is not going to edit webpack's internal
  bundle logic. It only cares about the one line in
  src/components/Header.tsx:42 where you missed a
  parenthesis.
  2. The database password and API key are sitting
  unmasked in plain text.
  3. The raw token count for this single error dump was
  45,820 tokens.

  ## What happens after Tokenectomy runs

  When the AI agent invokes get_error_context via MCP,
  Tokenectomy intercepts the log, strips framework
  internals, redacts all secrets locally using a
  deterministic DFA regex, and grabs bounded source code
  lines around the actual crash:

    [:TOKENECTOMY:M2M_CONTROL_PLANE:v1.3.0]
    [STATE=FRAMEWORK_NOISE_PURGED]
    [STRATEGY_APPLIED=AGGRESSIVE]
    [ORIGINAL_BYTES=45820 | CLEAN_BYTES=118 |
  REDUCTION=99%]
    [PRIMARY_CRASH_COORDINATES=src/components/Header.
  tsx:42]

  [COGNITIVE_DIRECTIVE=INSPECT_CALLER_AT_src/components/
  Header.tsx:42]
    [:END_CONTROL_PLANE]

    src/components/Header.tsx:42:15 - SyntaxError
      42 |   const user = useSession( ;
         |                           ^ Expected ')'
    🛡️ [CONNECTION_STRING_REDACTED]
    🛡️ [REDACTED]
  ANTHROPIC_API_KEY=[REDACTED_SECRET_KEY]

  Final token count: 118 tokens.
  Reduction: 99.7%.
  Zero credentials leaked to the cloud.

  ## Why Rust and why local-first?

  I did not want another slow node script or cloud proxy
  adding 300ms of network latency to an agent loop.

  1. Sub-millisecond latency: The core log surgery and
  secret redaction pipeline runs in <0.2 milliseconds on
  an Intel i5 CPU.
  2. Zero cloud leaks: It runs 100% locally over stdio.
  Your error logs, environment variables, and
  proprietary code never touch an external server.
  3. AST verification & rollback: The apply_code_patch
  tool parses modified code with Tree-sitter before
  saving to disk. If the agent generates invalid syntax,
  it immediately rolls back with zero dirty git diff.
  4. Lightweight footprint: Baseline process memory is
  3.45 MB VmRSS.

  Glama.ai audited the server definition under their
  Tool Definition Quality Score (TDQS) and awarded it
  Grade A (4.7 / 5.0) across all tools.

  ## How to set it up (Takes 30 seconds)

  You don't need to install Rust or compile anything. We
  distribute pre-built native binaries via npm for
  Linux, macOS (Apple Silicon & Intel), and Windows.

  Add this to your claude_desktop_config.json or Cursor
  MCP settings:

    {
      "mcpServers": {
        "tokenectomy": {
          "command": "npx",
          "args": ["-y", "tokenectomy-razor", "--mcp"]
        }
      }
    }

  Or if you prefer native cargo:

    cargo install tokenectomy

  Then configure:

    {
      "mcpServers": {
        "tokenectomy": {
          "command": "razor",
          "args": ["--mcp"]
        }
      }
    }

  ## Open Source & Repositories

  Everything is open source under the MIT license:

  1. GitHub: https://github.com/Tokenectomy-
  Labs/Tokenectomy
  2. Glama: https://glama.ai/mcp/servers/Tokenectomy-
  Labs/Tokenectomy
  3. npm: https://www.npmjs.com/package/tokenectomy-
  razor
  4. crates.io: https://crates.io/crates/tokenectomy

  Give it a run next time your agent is about to eat a
  40,000-token crash log. Your token bill will thank
  you.