We Cut 94% of AI Coding Tokens With a Local Code Index - Rajkumar Sakthivel, Tesco

Hey, I'm Raj. I want to tell a story: me and my friend Faz, we're building projects together. We're using AI coding tools every day—Claude Code, Cursor, Copilot, Codex, normal stuff. One month our AI bill was fine, next month huge.

We did nothing different. Same project, same tools, just more of it. We panicked. We looked at what was happening, and we found something surprising: most of the money was not the AI thinking. Most of it was

sending too much context files the AI don't need. Context is important. Code that was not relevant, sent anyway every time. So me and my friend Faz, we started building something to fix it. In this talk

is about what we built and what we learned.

Every AI coding tools does the same thing: it sends your code to the model as a context, and the tools thinks more context is better. We measured typical query on our project. It was sending 45,000 tokens of context, but the part that actually mattered is about 5,000 only.

Other 45,000 tokens are not useful, but we paid for them. Every. Single. Query. It's, um, that's like ordering a pizza and paying for extra 9 pizzas you don't eat. Every time.

We tried 3 things before we found what works. First, we changed our prompt: "Be short. Only show relevant code." Sounds good. But it does not work. The model already got 45,000 tokens before it reads the prompt. Cost already happened.

Second, we changed model settings—like max token, temperature. Same problem. This changes the output, not the input. Money is in the input. Third, output compression. This one actually works. We told the model to write short answers. It cut the output 75%, but output only about 10% of the cost.

So 75% of a small number. Still small number. Not enough. We need to fix the input. This is the most important slide. 90% of your AI cost is input: files, search results, context you send in. Only 10% is output: the code the AI writes back.

So if you cut the output by 75%, you can save about 8% total. But if you cut input by 94%, you can save about 61% total. Same math, but different result. Fix the input. That's where your money goes.

We built a local search layer. It sits between your codebase and the AI. Instead of sending whole files, the AI searches and indexes. It gets back only a small piece of code—actually it needs. Here's how it works, 5 steps.

Step 1: we read the code and break it into small pieces: functions, classes, methods. Not random chunks. Proper pieces that make sense. Step 2: we run 2 searches at the same time. One search finds the code by meaning.

One search finds the code by exact words. Then combine the results. This is where the big saving comes from. Step 3: we can shrink the results even more. Keep only the function name and the description. Cut 50-line functions down to 5 lines.

Step 4: we track the connection: which function called which. So if you find one piece of code, you can find everything connected to it. Step 5: every result gets a score. If the score is too low, we don't send it.

No bad context. Everything runs on your machine. Nothing goes to the cloud. This is the beauty. Why do we run 2 searches instead of 1? Because each one has a weakness. Meaning-based search is good at finding related ideas, but it misses exact names.

You search for an authenticate user function, and it might show you different auth functions instead, because they're similar meaning. The word-based search is good at exact names, but it misses related ideas. You search for login flow, and it misses everything that says "sign in."

By themselves, both searches miss about 1 in 4 results. Together, they miss about 1 in 10. They fix each other's weakness spots. Here is the hard part, Faz and I spend most of the time on. The search finds results, but they're actually relevant?

Sometimes search results return 10 results, and none of them areright. If the AI used the bad results, it gives confident wrong answers. The worse than no answer. We tried asking AI to judge its own results: "Too slow. Add 2-3 seconds every time."

We tried to fix the score limit. Too simple. Short questions, score low, even when the match is perfect. It worked. Some simple formula: 50% meaning score, 30% keyword score, 20% how the recent code is. And the limit adjusts based on the current result.

It runs 0.4 milliseconds. No extra AI calls needed. The lesson we learned: simple formula beats the complex model. Most of the time.

We need numbers, not just stories. So here are ours. We tested on an open-source real project, FastAPI. 53 files, 20 real questions a developer would ask. Without using our tool, 83k tokens per question. With our tools, 4.9k tokens per question.

That is 94% less. With extra compression on top, 523 tokens per question. And the accuracy still, um, finds theright code 90% of the code. These numbers are real. Test is public. You can run it yourself. The command is on screen.

I want to be honest about the limits. The 94% is again the worst case: reading full files every time. In real life, the tools like Claude Code are already smarter than that. Real savings are lower than 94%. We used full filebase because it is the only one we can measure the same way every time.

Big mixed codebase are hard. We tested on a large product with 396 files. The recall dropped almost zero. If files each do one thing, it works well. If files do many things, it struggles. We used a small, fast model for search.

It's quick. Reindexing takes under a second. But the bigger model would find more. We chose speed over perfection. Simple choices work better than complex one. Small database instead of big infrastructure. Two searches instead of one fancy one. Local instead of cloud.

Simple one.

Here is something Faz pointed out early on. We used many tools: Claude Code for hard problems, Cursor for quick edits, Copilot for small completions. Each tool starts fresh every time. They do not share anything. You explain the same codebase to 3 different AIs.

We built one shared index so all your tools connect to it. Same search, same results for all of them. And we added memory. When one tool learns something about your project, that knowledge stays. Next session, different tool, same project, the context is already there.

We explained the codebase once. Every tool remembered.

This is the saving report on real project. 247 queries, 12.4 million tokens saved, nearly 186 not spent. Most of the savings, 84%, came from search layer. The rest of them compression. This is not an estimate. The tool tracks every query.

It compares what would have been sent against what was sent. Then it multiplies by the model price. Run it on your project for a week. See your own number. Me and Faz built this because we had a huge bill and no good answer.

The answer was not "better model." The answer was "sending less." We argue about which model is best, Opus or Sonnet. But the model's maybe 30% of the cost, but other 70% is what you feed it. Fix the input.

The model choice matters less than you think. One command to try it. CCE. It's free, open source, QR code on screen. Try it. See the number. Tell us what you saved. Thanks. Happy coding.