How to save tokens when working with AI: rtk, CodeGraph, and precise context

An AI agent spends tokens on more than the final answer. A work session also includes files it reads, search results, repeated context, command logs, and intermediate iterations. If every task starts by sending the whole repository, even a small change becomes expensive quickly.

A better strategy is to provide exactly the context needed for the current step. Tools such as rtk, CodeGraph, and similar indexing utilities help you navigate a project without flooding the model with irrelevant text.

The main principle: less text, more signal

Saving tokens does not mean mechanically shortening every answer. Remove noise from the context:

• files unrelated to the task;
• duplicate search results;
• long logs containing only successful lines;
• stale versions of files that have already changed;
• entire directories when only a few symbols matter.

Do not remove information required for a correct decision. Context that is too small leads to mistakes, and fixing those mistakes can cost more than the original investigation.

Use rtk for compact command output

rtk is a wrapper around CLI commands that reduces terminal noise. Instead of thousands of unimportant lines, the model receives the useful result: command status, errors, changed files, or the outcome of a check.

For example:

rtk git status --short
rtk git diff --check
rtk npm run build

This is especially useful for Git, tests, and builds. The model usually does not need every dependency-install line or every successful compiler message. It needs to know:

1. whether the command succeeded;
2. which errors require attention;
3. which files changed;
4. whether any warning affects the task.

When the full output is needed, request it separately for one command or one relevant log section.

Use CodeGraph instead of reading the whole repository

CodeGraph indexes symbols and relationships between them. Instead of searching dozens of files and reconstructing the architecture manually, ask it:

• where a function is defined;
• who calls it;
• how a request travels from the UI to the API;
• which files depend on the symbol you want to change;
• where related types and handlers live.

A useful query looks like this:

How does createPayment flow from BuyModal to the webhook? Show related symbols and files.

Or before editing:

Show the source of SUPPORTED_MODELS and every place that uses this list.

This gives the model a local code fragment together with the call path and blast radius. You do not need to send a grep result, then the whole file, then manually reconstructed relationships.

When CodeGraph is most useful

• changing a function called from multiple places;
• locating an API request handler;
• working with a React component and its parents;
• adding a model, endpoint, or route;
• refactoring types and interfaces;
• investigating a bug through a call chain.

For configuration, Markdown, and files outside the index, use targeted reads with regular tools.

Separate research from editing

Tokens are wasted when one large request combines architecture discovery, design, implementation, and testing. Split the work into short stages:

1. identify the affected symbols;
2. inspect the call path and constraints;
3. create a small implementation plan;
4. make the smallest useful change;
5. run only the checks related to that change.

After an edit, do not send the entire source again. Send the diff, the check result, and the specific error if one appeared.

Read only the required line range

A full file often contains much more context than the task needs. When the symbol or area is known, read:

• the file header for imports and types;
• the body of the target function;
• the relevant call site for the contract;
• tests related to the change.

For a Markdown article, the title, structure, and nearby sections are usually enough. There is no need to load the entire blog or every locale on every request.

Do not resend information you already have

Repeating the same context is one of the most expensive patterns. Try to:

• refer to the file and symbol already identified;
• avoid copying the same log into multiple messages;
• keep decisions in a short ADR or project note;
• after editing, send only the current diff;
• separate facts from hypotheses.

Project memory is especially useful for architectural decisions. The model should not have to rediscover why a project has two route declarations, where the model list lives, or how payments work.

Choose a model for the task

Token savings depend on the model as well as the amount of text:

• a fast model works well for classification, simple searches, and mechanical changes;
• Sonnet is a good default for most development and analysis;
• Opus is better for difficult architecture, debugging, and large changes where an error is expensive.

Do not use the most capable model for formatting or renaming. But do not assign a complex refactor to a model that cannot hold the required context either: repeated corrections may use more tokens overall.

A practical workflow

For a typical task in an existing project:

1. CodeGraph: find the symbol and call path.
2. rtk: get compact git status and related checks.
3. Read only the required parts of the files.
4. Change the smallest useful set of lines.
5. rtk git diff --check.
6. Run a focused test or build.
7. If it fails, send only the error and the relevant diff.

A good agent request includes the research budget:

Fix email validation in createPayment.
First show the call path and related types.
Do not read the whole repository. After editing, run only related checks.

What usually does not help

“Read the whole project”

This creates noise and does not guarantee that the important relationship will be found. Start with a symbol, endpoint, or error message instead.

Full grep and log output

Large results are hard to analyze and expensive to pass around. Restrict searches by file pattern and keyword, and compress successful command output with rtk.

Rereading after every small edit

For a local change, a diff and the related command are usually enough. A full project review rarely adds value.

One huge universal prompt

Instructions unrelated to the task compete with code for context. Keep general rules in project configuration and put the concrete goal and acceptance criteria in the request.

Bottom line

To spend fewer tokens and get more consistent results:

1. give the model precise context instead of the whole repository;
2. use CodeGraph for symbols, relationships, and call paths;
3. use rtk for compact command output and checks;
4. separate research, editing, and validation;
5. send a diff after editing instead of the full file again;
6. choose a model based on task complexity;
7. record architectural decisions in project memory.

Less context does not mean lower quality. The right context is a small, current, connected set of facts that lets the model make a decision without unnecessary reading.