Copilot Context Window Showing ~40% Reserved Output Even With Minimal Prompt

[ZainDevX]

Select Topic Area

Question

Copilot Feature Area

VS Code

Body

Title: Copilot Context Window Showing ~40% Reserved Output Even With Minimal Prompt

Hello everyone,

I recently noticed the update where GitHub Copilot's context window was increased from 128k tokens to 192k tokens, which is great.

However, I am experiencing an issue related to the context window usage.

Even when I open a completely empty chat and send a very simple message like:

hi

the Context Window indicator already shows around 40% usage, and most of that appears to be labeled as Reserved Output.

Example from the Copilot UI:

• Context Window: ~76k / 192k tokens (~40%)
• System Instructions: ~2–3%
• Tool Definitions: ~5%
• Reserved Output: ~30%+

This happens even when there is no meaningful conversation history, which makes it feel like a large portion of the context window is already consumed before doing any real work.

My questions:

1. Why is such a large portion of the context window allocated to Reserved Output by default?
2. Is there a way to reduce or manage this reserved output space?
3. Is this expected behavior with the new 192k token context window, or could this be a configuration/UI issue?

If anyone from the team or community has insight into how the reserved output allocation works or how to optimize the available context window, I would really appreciate the clarification.

Thanks.

Screenshot:

[zckLab]

What you're seeing isn't a bug or a configuration error; it is actually a standard safety feature of how GitHub Copilot manages its 192k token capacity.

Think of the "Reserved Output" as a guaranteed parking space for the AI's response. Even if you only say "hi," the system immediately sets aside about 30% of the total window (roughly 60k tokens) to ensure that if you later ask for a massive code refactor or a long explanation, the AI has enough "room" to finish writing without being cut off mid-sentence.

To answer your specific points:

• Why is it so large? It prevents the AI from running out of memory during long generations. By reserving this space upfront, the system guarantees it can handle complex outputs regardless of how much conversation history you have.

• Can you manage it? No, this allocation is managed on the backend by GitHub. There isn't a setting to reduce it because the stability of the output depends on that buffer.

• Is this expected? Yes. With the jump to 192k tokens, the absolute size of the reserved area increased proportionally to allow for the longer, more complex responses that the new model is capable of producing.

In short, you still have plenty of room (over 100k tokens) for your code and prompts. The "Reserved Output" is just the system making sure it can always talk back to you effectively.

[kamilkonior]

I have just launched Claude Code to see how much it reserves upfront, 16.5% for autocompact buffer. In practice, the amount of tokens copilot reserves is so enormous, that it leads to significant waste. I understand that it needs some spare room, but surely it doesn't need 30% of the context window, for the GPT models its even worse as they have 400k context window so 120k(~8k - 16k of LOC) is wasted. It should be tunable, so everyone can align the reserved output to particular coding style with agent in the loop.

When i say wasted, i mean that 10-20% would suffice, depending on the model, and coding style.

[TheNotary]

Thank you for sharing that @zckLab, it makes more sense having that context.

I was confused when I saw the UI element as well. I think it might be worth considering rendering the UI as a meter of available context and context actually used --subtracting out the reserved context from the total. This would allow the user to see roughly how much strain is on the model that they can do something about (compression, being more selective with tools, beginning to wrap up the session, etc.).

eg

percentage_used = (system_instructions + tool_definitions + messages + tool_results) / (model_context_window - reservations)

I'm wondering now if I've aborted sessions prematurely because of the way the UI element represented the situation.

[kierykp]

@TheNotary I agree with you; it confuses me too. I will prefer to see the context window UI percentage only based on the context used in my chat window. "Reserved Output" Should be only informative and shouldn't affect the calculations of the current context window.

I usually watch the context window size when I'm working on some feature, and when it exceeds 50%, I always switch to a new chat window.

Right now I am very confused because I don't know when my actual conversation exceeds 50% and when it is because there is some reserved output.

@zckLab could you help here?

[marcinkubica]

Why is so much different across models?

Also note tools definitions are different - I ran them all against the same tools def an no folder in workspace.

And the most important part - do we pay with premium credits upfront for this excessive amount of "reserved output" ?

[edit] Actually used ai answers on github page

Copilot Reserved Output – Summary

What “reserved output” means

Reserved output is content generated by an AI model that GitHub intentionally does not show to the user. It typically includes:

• Internal reasoning and planning
• Safety and policy scaffolding
• System-level instructions or routing metadata

Only the user‑visible output (the part you should act on) is shown in Copilot, Copilot agents, and GitHub Models.

---

Why you see different reserved output percentages

When you run the same prompt (for example, hi) across different models in GitHub Models Compare/Evaluate, each model produces a different mix of:

• Visible response text
• Internal, non-user-facing content

The percentage reflects how much of the total generated content was classified as reserved and hidden.

Short prompts exaggerate this effect.

---

Example results you observed

• GPT‑5.4 → ~31.9% reserved output
• Claude Sonnet 4.6 → ~19.8% reserved output
• GPT‑4.1 → ~12.6% reserved output
• Grok Code Fast 1 → ~37.3% reserved output

This is expected and does not indicate a problem or loss of information.

---

Why trivial prompts increase reserved output

Prompts like hi:

• Trigger safety and alignment logic
• Produce very small visible answers
• Make internal scaffolding a larger percentage of total output

Even a visible reply like Hi! can result in 20–40% reserved output.

---

What higher reserved output does not mean

• It does not mean the model failed
• It does not mean useful content was removed
• It does not affect the code or answers you receive
• It does not expose or hide repository secrets

GitHub filters this content by design.

---

How to reduce reserved output in model comparisons

To get clearer comparisons:

1. Use a non‑trivial prompt
   Example:
   Reply with exactly one sentence greeting a developer.

2. Set a lower max token limit

3. Avoid placeholder or test prompts (hi, test, hello)

---

How to explain this to developers

Suggested onboarding explanation:

Reserved output is the model’s internal reasoning and safety logic. GitHub hides it by design. Different models generate different amounts of it, especially for very short prompts.

---

Key takeaway for admins

Reserved output percentages vary by model and prompt, are expected behavior, and should not be used as a quality metric. Focus evaluations on meaningful prompts and visible results.

[ribbles]

The issue that we all started burning through our copilot monthly credits a LOT faster as of last week. The response from @marcinkubica doesn't point directly to a cause. I'm very motivated to find out as I can never use more than 30% of my credits in a month, and Im already at 30% with only 6 days use.

[MateoBaravalle]

I'm having the same issue, I have reached 40% in 10 days, the past month I barely reach 45%, I started using it more, but this is crazy diferent...

[kierykp]

Mine example using Opus 4.6 today, calling 3 subagents to explore my codebase... 50% reserved context?! WTF

[ribbles]

The issue @kierykp shows in his screenshot is: System Instructions 9%, tool results 20% and files 11%. That's 40% and it didn't used to be like that. Reserved output shouldn't be used in the calculation because it hasn't been used thus confuses the measurement.

[massamba00]

@kierykp Opus4.6 is 3x more greedy than Sonnet.
I advice you to use Sonnet4.6 for coding stuff and Opus for more architectural design thinking. Hope this help!

[Nyrok]

The breakdown you're seeing (system instructions + tool definitions + reserved output eating 40%) is a good argument for treating the instruction layer as a first-class budget concern, not an afterthought.

Prose system prompts expand silently — there's no natural stopping point, so they tend to grow until someone notices the context is gone. Typed instruction blocks (role, constraints, examples, output format as separate, bounded fields) let you reason about what's consuming context before you send anything. You can prune a specific block without rewriting the whole prompt.

I've been building flompt for exactly this, a visual prompt builder that decomposes prompts into 12 semantic blocks and compiles to Claude-optimized XML. Open-source: github.com/Nyrok/flompt

The structured format also tends to be more token-efficient than equivalent prose because there's less ambiguity for the model to resolve.

[abstract-official]

I don't see the purpose of reserved context windows. Let's say there's 30% of this. Without the reserved window, when I reached 70%, there's 30% left for me, so the output won't be cut off. With the reserved window, when I reached 70%, there's 30% reserved, so the output won't be cut off. There's little difference, and reserving only adds to confusion.

[HarshitBhalani]

This is expected behavior. The context window in Copilot includes more than just your visible prompt.

Even in an empty chat, tokens are already used by:

• System instructions (internal prompts that guide the model)
• Tool definitions for VS Code features
• Reserved output space, which is preallocated so the model has enough tokens to generate a response.

Because of this, you may see around 30–40% usage even with a simple message like hi. The Reserved Output portion is intentionally kept as a buffer and currently cannot be manually adjusted.

So the usage you’re seeing is normal and not a configuration issue.

[dmytro-arkhypenko]

For me it reserved 40% and started compacting after "Hey"

[james-at-rise]

(Opus 4.6)

I get the reason for the reserved output, but this seems overtuned.

I work on a large c++ codebase. Even with a clear plan initial reads of files for plan execution can take 70k tokens. When it was reserving 30% it was fine for me, I'll have to try downgrading to 1.110

[massamba00]

@james-at-rise https://github.com/orgs/community/discussions/188691#discussioncomment-16487215

[JoshMalan1]

There's clearly an issue. I am getting the same results as others. Yesterday I had no issues with long conversations and coding tasks without ever getting close to the context window needing compaction. Today, the context window compacts nearly every other message. In one 15 minute session it's compacted 6x already.

[brianpaden289]

Seeing 60%+ reserved with Opus 4.6, VS Code 1.110.1, Copilot 0.38.2. It is compacting nearly every other command and even that doesn't free enough space to be usable.

[sg-tnt]

it's completely unusable at this point

[moveingsun]

second this, when I use claude opus 4.6 to analyze a run log of 500 row and the execution plan, it reaches 200k upper limit immediately, and then it start to took long time to compacting conversation, which make the model barely unusable, as compacting conversation is taking very long time even tho the conversation just started.

[DJCallyman]

Agree with these. It's useless right now

[moleksy]

I was quite pleased with Claude Opus 4.6, but it became literally unusable, even GPT 5.3 with context window twice as large is pretty much unusable after a short while.

[marian316]

same thing happening with copilot + opus 4.6

[moleksy]

The problem that I observed is that it was working just fine until like 2 days ago, that's when I started to hit Compacting conversation every few minutes...

[Bilbin]

Same thing for me. It was working great a week ago, and after the new update, it keeps compacting and big prompts take much, much, much longer.

[ash-iiiiish]

Quick Resolution: This is expected behavior, not an issue to fix. The ~30-35% reserved output space is intentionally allocated to ensure Copilot can complete long responses without truncation.

What You Can Do:

Accept it's normal – The reservation is by design and cannot be reduced

Optimize your input space instead:

Start fresh chats for new topics

Use /clear to reset conversation history

Reference files with #file rather than pasting content

Keep prompts concise

Bottom line: No action needed – your available input space is still ~120k tokens, which is plenty for complex tasks.

[ribbles]

Accept it's normal

Its not normal to mark something as spent when its not!

[james-at-rise]

So far I am seeing a much reduced reserve on Opus 4.6 today (15-30%). Looks like the 60% on opus was perhaps unintended yesterday.

[DJCallyman]

Me too - though it didn't take it long to land in a "wait, let me approach this logically" loop

[ribbles]

While the "reserved output" issue remains, as of Monday the actual token use has gone back to how it used to be (for me), and much more under control:

[PellucidDice]

Pretty funny that they now just hides the numeric % for the reservation.

[entrptaher]

Oh! That's why it was auto compacting after only 80-100k tokens in other tools like opencode for models like Codex 5.3 via Github Copilot, because the backend is nerfed. I am pretty sure it was not like this just a few weeks ago.

[entrptaher]

Where's my 100k token? :/

[nop1984]

Copilot started to forget instructions and context extremely fast. Disappointing degradation

[jaredhagel2]

Yes, I find the same issue. I preferred how things worked before. It explained why my context started compacting at just a little above 50% context usage (since the ~30% reservation actually puts me at 80%+ total occupancy), losing important context history.

[jaredhagel2]

I'm not sure what the best approach is here. Perhaps totally leaving the 'reserved output' out of the UI? VSCode users are generally only concerned with input (at least I am) not output. So maybe the percent should just be for input? It's interesting to know how much is reserved for output, but the user who started this thread found the high percent before even starting a chat confusing, and myself and perhaps nop1984 find the low percent before context compaction confusing. So perhaps the best fix is to leave 'reserved output' out of the percent calculation. If the 'Reserved Output' is a static, non-configurable budget that we cannot use for input, then perhaps it shouldn't be part of the percentage calculation at all. Just a thought.

[Venu5198]

I don’t think removing “Reserved Output” from the UI entirely is the right fix, but you’re correctly identifying the real issue: the percentage is misleading.

Right now the UI mixes two different things:

• Actual input usage
• Pre-allocated output budget

That makes it look like you’ve already consumed ~40% of the context, which isn’t true.

However, if you remove reserved output from the percentage completely, you create a different problem: the denominator becomes unclear. Users will think they have the full 192k available for input, which isn’t the case, and that leads to confusion when limits are hit earlier than expected.

A better approach would be:

• Show Input Usage as the primary percentage (e.g., 10k / usable input budget)
• Show Reserved Output separately as a fixed allocation
• Avoid combining them into a single “used” metric

This keeps the model honest:

• Users see how much input space they actually have
• The system can still communicate that output space is reserved

Right now the UI is mixing capacity planning with consumption, which is why it feels wrong.

Your direction is right. Your implementation suggestion isn’t.

Don’t remove the concept.
Fix the accounting model in the UI.

[mosin-loantap]

So im not new here, just want to know how to get out of this situation..

[kingeke]

Hello, is there any possible solution to this, with copilot built in tools only selected, sending a simple hello already sends input tokens of 30k

How can we fix this?? it makes no sense, cause right now this is adding to our billing and its expensiveeeeeeeeeeeeee

[entrptaher]

I've stopped using copilot. That solved the problem for me. Thank you everyone!

[kingeke]

@entrptaher which are you using now if you don't mind

[ebndev]

Hello! Just wanted to follow up and close this discussion as there is outdated information.

Reserved output is capacity set aside for the model’s response and can’t currently be reduced or configured. It does not mean those tokens have already been consumed.

Copilot has since moved from the request-based model introduced in 2025 to usage-based billing for most plans in June 2026. Billing is based on input, output, and cached tokens actually consumed, not the maximum reserved capacity. Individual users can review their consumption in the usage dashboard.

See Models and pricing and Usage-based billing for individuals.

If you have additional questions on usage-based billing, please open a new discussion.