How I Reduced Tokens, Time, and Tool Calls in Pi Agent with Local Memory

A practical experiment with Pi Agent, Markdown memory, and an open source extension called pi-memctx

Anyone who uses coding agents every day knows this pattern very well: you open the agent, ask something relatively simple about a repository, and the agent starts from zero.

It lists files. It reads workflows. It opens manifests. It searches through documentation. It inspects scripts. It rebuilds the architecture in its own context window. And only then it answers.

The final answer may be good. But the path to get there is often expensive.

It costs tokens. It costs time. It costs tool calls. And, most importantly, it repeats work the agent has already done before.

That was the main reason I built pi-memctx, an open source extension for Pi Agent.

The idea is simple:

I do not want to pay my coding agent to rediscover what the project already knows.

The problem: coding agents still start cold

Even very capable coding agents usually lack durable project memory.

When I ask something like “tell me how this Argo CD repository works”, the agent usually needs to investigate the repository from scratch.

It needs to figure out how the repo is structured, where the manifests are, how applications are organized, which environments exist, which patterns are repeated, which technical decisions were already made, and which files are actually relevant.

This works. But it is not always efficient.

In many cases, the agent is not solving a new problem. It is just rebuilding context that should already exist somewhere. If the agent has already analyzed this project before, why should it need to do the same exploration again?

The idea: local-first memory before reasoning

pi-memctx works as a local memory layer for Pi Agent. Instead of starting every session from a blank context, the agent can retrieve useful project knowledge before reasoning.

The flow looks like this:

The goal is not to replace the main LLM. The goal is to give the agent better context before it starts thinking.

That context can include project overview, architectural decisions, runbooks, deployment flows, repository conventions, operational notes, observations from previous sessions, common commands, and known caveats.

Everything is stored locally in Markdown. That means the memory is readable by humans, searchable by agents, easy to version with Git, easy to review, easy to edit, and not locked inside a hosted memory provider.

This is important to me because agent memory should not be a black box. If my agent remembers something, I want to be able to open the file and see exactly what was saved.

The benchmark

To validate whether this approach actually helped, I ran a simple benchmark. I compared two profiles: baseline and gateway.

The prompt used in the benchmark was:

tell me how this argo-cd repo works

I ran each profile twice. The goal was not to prove a universal truth for every agent, every project, or every repository. The goal was much simpler: I wanted to measure whether a local memory gateway could reduce latency, provider tokens, visible tokens, and tool calls.

Average result by profile

Average of 2 runs for each profile using the same prompt:

The difference was significant. With the gateway profile, the agent answered with far less raw exploration and almost no tool calls.

Difference between gateway and baseline

Negative values indicate a reduction in the gateway profile compared to the baseline.

In practical terms, latency went from 108.3s to 32.1s, average provider tokens went from 33,006 to 3,564, visible tokens went from 2,331 to 700, and tool calls went from 28.0 to 0.5 per run.

That is the part I found most interesting. The agent was not just cheaper to run. It was less noisy. It spent less time navigating the repository and more time answering from useful context.

The most interesting part: fewer tool calls

The token reduction was expected. The latency reduction was also expected. But the tool call reduction was the part that really caught my attention.

In the baseline runs, the agent used 23 and 33 tools. In the gateway runs, it used 1 and 0 tools.

That changes the experience. A coding agent that constantly searches, opens files, and scans the repo feels like it is still trying to understand where it is. A coding agent that starts with relevant memory feels much closer to a teammate who already knows the project.

That is the difference I wanted to explore with pi-memctx.

Why this works

Many prompts we send to coding agents do not require a full repository investigation every time. For example: How does this repo work? How do I deploy this service? Where is the production configuration? What is the CI/CD flow? What architectural decisions does this project follow?

Most of these answers do not change every hour. They should live somewhere durable.

That is what pi-memctx provides: a local memory pack made of Markdown files. Instead of forcing the agent to rediscover the same structure repeatedly, I can let it reuse project memory that already exists. This memory can be updated over time as the project evolves.

Local-first matters

I wanted this to be local-first for a reason. I did not want to depend on an external database. I did not want a hosted memory vendor. I did not want another service to operate. I did not want agent memory to become invisible infrastructure.

Markdown is simple. It is not fancy, but it works. It can be opened in any editor, committed to Git, reviewed in pull requests, deleted if it becomes outdated, and inspected by humans.

For agent memory, that matters a lot. The more autonomous coding agents become, the more important it is to keep their context understandable and auditable.

This does not replace tools

One important point: I am not trying to remove tools from coding agents. Tools are still essential. The agent still needs to inspect files, run commands, validate assumptions, read logs, execute tests, and interact with the real environment when needed.

The goal is not to never use tools. The goal is to use tools when they are actually needed. If the memory already contains enough project context to answer a question, the agent should not need to perform a full repository discovery process again. If the memory is incomplete or outdated, then the agent can still investigate normally. That balance is what makes this useful in real workflows.

How to install it

You can install the extension with:

pi install npm:pi-memctx

Or directly from GitHub:

pi install git:github.com/weauratech/pi-memctx

Then enable it inside your workspace:

pi -e pi-memctx

And generate the first memory pack:

/memctx-pack-generate

You can also run the doctor command to validate the setup:

npx pi-memctx doctor

The repository is available at github.com/weauratech/pi-memctx.

What this means for teams using coding agents

I believe the future of coding agents is not only about better models. Better models help a lot. But there is another layer that matters just as much: better context.

A strong model with poor context still wastes time finding its way around. A good model with structured project memory can start much closer to the answer.

For engineering teams, this can help with faster repository onboarding, less repeated exploration, lower token usage, lower latency, fewer unnecessary tool calls, more consistent answers, reusable runbooks, accessible technical decisions, and less dependency on tribal knowledge.

The more I use coding agents, the more I believe that memory is not just a convenience. It is infrastructure.

Conclusion

This benchmark confirmed something I had already been feeling in daily usage: coding agents do not only need better prompts. They need better memory.

With pi-memctx, I was able to reduce approximately 70.3% latency, 89.2% provider tokens, 70.0% visible tokens, and 27.5 tool calls per run. All of that with a simple approach: local memory, Markdown files, and context retrieval before the agent starts reasoning.

pi-memctx is open source, and I built it as part of my work at WeAura Tech around AI-first engineering workflows. If you use Pi Agent, coding agents, or you are exploring ways to reduce cost and improve context in AI-assisted development, feel free to try it out.

Repository: https://github.com/weauratech/pi-memctx

Feedback, ideas, and contributions are very welcome.