Claude Code context packing for relevant code, opt-in

The problem: exploration reads cost tokens

In an unfamiliar codebase, Claude often runs a search, then reads several candidate files to find the right function. Each read adds to the context that every later request resends. Anthropic's cost page says vague prompts trigger broad scanning, and specific ones let Claude work with minimal reads.

What Anthropic suggests

• Code intelligence plugins: a single go-to-definition call replaces a grep followed by reading several files, and installed language servers report type errors after edits.
• Skills: a codebase overview skill gives Claude the structure without exploring.
• Specific prompts, and plan mode before a complex change.

Try these first. They are documented and need no extra binary.

What DCI does: context packing in three steps

DCI is Downshift's code intelligence layer. It indexes the repository in-process, ranks candidates with BM25 and packs only the selected symbols under a byte cap. The default budget is 3500 bytes, adjustable from 512 to 16384. It is off until you run downshift dci enable.

Languages: Go through the AST, and TypeScript, JavaScript, Python, Rust, PHP, Java and C# by pattern matching. Pattern matching is less precise than a parser, so I would expect more misses outside Go.

A real run on this repository

Downshift's own repository was the target. The command was downshift dci inspect "where is the tier floor applied".

The index build took 402 ms in that run. Retrieval took 5 ms and packing 0 ms.

Impact radius for a change

downshift dci impact --json Route lists the callers a change to Route could reach. On this repository it returned four: runTryReport in cmd/downshift/try.go, Handle in the Claude Code adapter, Handle in the Codex adapter and TestClassifierStability, a test. That is the set an agent should check before it edits the function.

Active and observe modes

In active mode DCI injects the packed context into the prompt. In observe mode it only records telemetry, so you can see what it would have selected. Start with observe if you want evidence on your own code before it touches a prompt.

To see what it would pick, run dci inspect on a few prompts whose answers you already know, then compare the selected files with the ones you would have opened. downshift stats --dci summarizes DCI telemetry over time.

Where it overlaps with code intelligence plugins

An LSP-based plugin answers definition and reference questions on demand, one call at a time. DCI ranks and packs a slice of code before the model starts. They are different mechanisms and can be used together. I have not compared them, and no combined measurement exists. If a plugin already removes most of your wasted reads, DCI may add little.

The honest test is your own repository: count the file reads in a session with and without it, and check that the answers stayed as good.

What is measured and what is not

A smaller context is not proof of a better answer. It could drop a file that mattered. Compare results on your own tasks, and treat DCI as a way to send less, which you still have to validate.

Related guides

• Claude Code token optimization: the levers, ranked by evidence
• Why Claude Code token usage climbs, and how to see it
• Claude Code model routing: choosing the model per task
• Install Downshift: Claude Code, Codex and Cursor hook setup

Sources

1. Anthropic docsmeasured
   code.claude.com/docs/en/costs
   code intelligence plugins, skills, specific prompts, plan mode (fetched 2026-10-19)
2. Downshift repomeasured
   README.md
   DCI scope, byte cap, languages, measured so far
3. Downshift repomeasured
   docs/reference/capability-matrix.md
   DCI status
4. Downshift CLI outputmeasured
   downshift try and downshift dci output, captured 2026-10-19 (reproduce with the commands shown)
   dci inspect and dci impact on this repository
5. Downshiftunverified
   token saving or answer quality from DCI
   not measured