134,454 Tokens to Answer
Three Questions
We gave Claude Opus grep and read_file tools, pointed it at a real codebase, and asked three questions. Then we asked Optiq the same things.
The Setup
We took a real TypeScript project — a Discord bot with 50 source files, 17,896 lines of code, and a bunch of interconnected systems: XP leveling, a virtual economy, a shop with flash sales, a robbery mechanic, daily quests, achievements. Not a toy project, but not a monorepo either. A normal codebase.
We spun up Claude Opus with three tools: grep (regex search across all .ts files), read_file (read any file by path), and list_files (see what's in the project). This is roughly what every coding agent ships with — Claude Code, Cursor, Cline, OpenHands, they all give the model some version of search-and-read.
Then we asked three questions and let the agent do its thing. No hints, no file paths, just natural language questions about how the code works.
Task 1: “How does XP leveling work?”
We asked the agent to trace the full flow from a user sending a message to a level-up, including the exact XP formulas.
The agent made 15 tool calls. It started with list_files to orient itself, then grepped for “level” and “xp” — which returned matches in almost every file. It read levelSystem.ts (366 lines), then grepped for addXp callers, read messageCreate.ts, read shopSystem.ts (584 lines, most of it irrelevant to XP), read voiceXpService.ts, grepped for streak-related functions, read dailyStreaks.ts, and finally read database.ts to understand the schema.
Six files read. Most of them in full. 21,557 tokens. 102 seconds of wall time.
Optiq returned the exact XP formulas, the message handler, the voice XP service, and the level-up cascade — all as pruned functions, ranked by relevance. One call. Around 2,000 tokens.
Task 2: “What happens when someone buys from the shop?”
This one got expensive.
The agent made 20 tool calls and read 10 files. It grepped for “shop” and “purchase”, read index.ts and package.json to understand the project structure, then read shopSystem.ts (584 lines), database.ts (483 lines), itemExpirationService.ts, flashSales.ts, statements.ts (303 lines), levelSystem.ts again, and then — here's the kicker — it read interactionCreate.ts.
interactionCreate.ts is 5,565 lines. The agent read the entire thing to find one button handler. That single file read burned roughly 57,000 tokens by itself.
Total: 77,985 tokens. 162 seconds. For one question about a purchase flow.
Optiq returned purchaseItem() with the full pricing logic, the shop command, the bundle system, and the flash sale handler. About 2,500 tokens.
Task 3: “How does the robbery system work?”
The codebase is a Turkish Discord bot. The robbery command is called “soygun.” The agent didn't know that.
It grepped for “robbery” — no matches. Tried “rob” — nothing useful. Tried “steal” — nothing. Tried “alarm” — got some hits. Eventually grepped for “soygun” after reading index.ts and finding the command registration. Then it read soygun.ts, tried to read rob.ts and robbery.ts (both don't exist), read shopSystem.ts again for the security items, and read interactionCreate.ts again.
18 tool calls. 34,912 tokens. 79 seconds. Several of those calls returned “File not found” or “No matches.”
Optiq understood “robbery system” maps to soygun.ts because it indexes by behavior, not just keywords. One call, the relevant functions, about 2,000 tokens.
The Numbers
| Task | Agent tokens | Agent calls | Optiq tokens | Optiq calls |
|---|---|---|---|---|
| XP leveling | 21,557 | 15 | ~2,000 | 1 |
| Shop purchase | 77,985 | 20 | ~2,500 | 1 |
| Robbery system | 34,912 | 18 | ~2,000 | 1 |
| Total | 134,454 | 53 | ~6,500 | 3 |
95%
fewer tokens
94%
fewer tool calls
$2.45
agent cost vs ~$0.10
Why This Happens
The agent isn't doing anything wrong. It's doing exactly what it's supposed to: search, read, search again, read more, build understanding incrementally. The problem is that this loop is expensive by design.
Every grep returns dozens of matches across files the agent doesn't need. Every file read pulls in hundreds of lines that aren't relevant to the question. The agent can't know which 40 lines matter until it reads all 584. And each iteration re-sends the entire conversation history — including all previous tool results — back to the model.
The shop purchase task is the clearest example. The agent read interactionCreate.ts — all 5,565 lines of it — because a grep told it there was a shop-related handler in there somewhere. It needed maybe 30 lines from that file.
This is the tax you pay for not having a code graph. The agent has to reconstruct the relationships between functions and files from scratch, every single time, by reading raw source code and hoping it finds the right trail.
The Vocabulary Problem
The robbery task exposed something that doesn't show up in English-only codebases. The agent searched for “robbery,” “rob,” and “steal” — all reasonable guesses — and got nothing. The command is called “soygun” because the bot is Turkish.
Grep is literal. It finds what you type. If you don't know the exact term the developer used, you're stuck in a loop of failed searches until you stumble onto the right keyword.
Optiq indexes by behavior and structure, not just text. It understood that “robbery system” maps to the soygun module because it parsed the AST, saw the security item checks, the penalty calculations, the cooldown logic — and connected them semantically. No keyword guessing required.
What This Means at Scale
This was a 50-file project. The agent burned 134K tokens and nearly six minutes on three questions. In a real workflow, an agent might handle dozens of questions per session — reading files, making changes, reading again to verify.
Scale that to a monorepo with thousands of files and the numbers get absurd. The grep results get noisier, the files get longer, the agent reads more irrelevant code, and the conversation history balloons with every iteration. We've seen agent sessions on large codebases burn through 500K+ tokens before producing a single edit.
Optiq's cost stays roughly flat. Whether the repo has 50 files or 5,000, a search returns the same pruned, ranked context. The graph already knows which functions connect to what. There's no exploration loop.
Reproduce It Yourself
The benchmark script is open. Point it at any codebase, give it your API key, and watch the agent work. Then compare the token counts to a single Optiq query.
npm install -g @optiqcode/cli optiq login optiq index . optiq search "how does the payment flow work"
The beta is free. No credit card, no waitlist.