---
title: Where your Copilot tokens actually go
date: 2026-09-14
tags: ai, copilot, tokens, context
summary: MCP servers, instruction files and long sessions all eat your context window. Small habits that save tokens.
---

> "Context matters" is true for AI and for every argument you've ever had. Say too little and it misunderstands you. Say too much and it forgets the point.

Most people using GitHub Copilot never look at where their tokens go. Then a response is slow, an instruction gets forgotten, or a session feels dumber than it did an hour ago. The reason is almost always context: too much of it, the wrong kind, or none when it was needed.

Here is what happens under the hood, and a few habits that reduce context and token use.

## The context window

Every AI coding assistant works inside a context window: a fixed budget of tokens the model can see at once.

In GitHub Copilot CLI you can check it yourself with `/context`. It splits usage into system prompt, custom instructions, system tools, MCP tools, messages, free space and a buffer.

This is a real `/context` on an empty chat, before I had sent a single prompt. MCP tools alone took 20% of the window, and the buffer another 28%. Only 43% was left for me.

```ascii caption="/context on an empty chat: 78k of 264k tokens used (29%)"
System Prompt  [#........................]   14.2k   5%
System Tools   [#........................]   11.5k   4%
MCP Tools      [#####....................]   51.9k  20%
Messages       [.........................]       0   0%
Free Space     [...........              ]  112.3k  43%
Buffer         [.......                  ]   74.0k  28%
```

## MCP servers cost tokens just by existing

Every connected MCP server puts its tool names, descriptions and parameter schemas into the context, on every message, whether you use them or not. A few servers with many tools can use a big part of your window before you type anything.

**Better:** keep only the MCP servers you need for the current task and disconnect the rest.

## Instruction files: small and split

Copilot reads `.github/copilot-instructions.md`, `AGENTS.md`, and path-specific files in `.github/instructions/*.instructions.md`.

The common mistake is one giant file with coding style, architecture, testing rules and deployment notes. That file is loaded in full on every request.

**Better:** one short file for what always matters, and smaller files with an `applyTo` pattern for the rest, for example one each for backend, frontend and tests. Only the ones that match the files you are working on get loaded.

Small files are also easier to keep correct. Nobody rereads 300 lines to check if they are still true. You can even ask Copilot to do the split for you. It creates the files and links them.

This is what the top of a split-out file looks like. The `applyTo` line is what keeps it out of the context unless you touch a matching file:

```ascii caption="testing.instructions.md"
---
description: 'Testing conventions for xUnit test projects and the TestingTools shared project'
applyTo: '**/*.Tests/**,**/TestingTools/**'
---

### Testing
- **xUnit v3** (`xunit.v3`) as test framework
- **NSubstitute** for mocking
- **Shouldly** for assertions
```

## Give it a map

Without guidance, an agent searches and reads through your repo again and again to understand the structure. That costs tokens and time in every session.

A short architecture note helps: where the entry points are, how the modules relate, where the config lives. Then it can look things up instead of rediscovering them. `/init` creates a starting file. Use it as a base and keep it lean.

## Habits while you work

- **Match the model to the task.** Small, fast models are fine for routine edits and lookups. Save the big reasoning models for hard debugging and design. Auto model selection works if you don't want to think about it.
- **One task per session.** Use `/clear` or `/new` when you switch. Old history stays in the context and is useless once the task is done.
- **Long session, same task?** Use `/compact` to summarize the history instead of losing the thread with `/clear`.
- **Switch off what you don't use.** Instruction files and MCP servers can both be toggled per session.

## Prompting

Vague prompts cost more overall. The prompt itself is short, but the agent has to explore, guess and often redo work. Say what you want and where.

Also, don't assume the editor knows what you are looking at. Some integrations add your open tabs automatically, some don't, and this has changed over time. Attach the files that matter. A few well-chosen files beat whatever happens to be open. And if your extension does pull in open tabs, that can bloat the context too.

## Input vs output tokens

The habits above reduce what goes in. There is a second lever: input and output tokens are not priced the same. Providers often charge three to five times more for output. A long prompt is relatively cheap, a long answer is not.

Ways to cut output:

- Ask for the answer, not the story: "no preamble, no summary, just the change."
- Cap the format: a bullet list or a line limit stops the padding.
- For code changes, ask for a diff, not the whole file again.
- Set a stop condition: "max 5 items, stop after the list."
- Tell it not to repeat context you already gave it.

Trimming your prompt saves a little. Trimming what the model writes back saves a lot more.

Have fun burning tokens :-)