# How to give AI context about your codebase (without pasting files every time)

Pasting files into the chat doesn't scale and goes stale. Here are the real ways to give AI tools context about your codebase, with the tradeoffs and the token math.

The fastest way to give an AI tool context about your codebase is to paste the relevant files into the chat. It also doesn't scale, and it goes stale the moment your code changes. Here are the actual options, from worst to best for a codebase you work in every day.

## Option 1: paste files into the chat

Works for a one-off question. Falls apart quickly: you re-paste every session, you blow the context window on big files, and the moment the code changes your pasted copy is wrong. It's manual memory that you're personally responsible for keeping fresh.

## Option 2: a hand-written CONTEXT.md / AGENTS.md

Better — a durable summary the tool can read. But it rots the instant someone renames a service, and it's loaded whole on every question whether relevant or not. On a real 1,600-file app we measured a hand-written docs corpus at ~119k tokens: often *more* than reading the code cold.

## Option 3: RAG over your files

Chunk, embed, retrieve by similarity. Scales better, but similarity search doesn't understand structure (who calls what), and the index goes subtly wrong every time you refactor — with no warning.

## Option 4: structure-aware codebase memory over MCP

Parse the repo into real structure — symbols, a resolved call graph, routes, schema — and let any AI tool read a compact map over MCP. It's query-scoped (only what's relevant), it stays correct as the code changes, and it's [~5-9x fewer tokens per question](/benchmark) than reading files cold.

| Approach | Scales | Stays correct | Token cost |
|---|---|---|---|
| Paste files | no | no | high |
| Hand-written docs | no | no | very high |
| RAG over files | yes | no | medium |
| Structure-aware memory (MCP) | yes | yes | low |

## The recommendation

For a one-off, paste the file. For a codebase you live in, give your tools structure-aware memory once and let every tool read it — no re-pasting, no rot. That's what SecondOS does, and your source never leaves your machine.

[See the product](/product) · [reproduce the benchmark](/benchmark) · [quickstart](/docs/quickstart).