Limit of Copilot Spaces

[hminhman]

Select Topic Area

Question

Copilot Feature Area

Copilot Workspace

Body

Copilot Spaces: “Exceeded size limit” at 210% with ~185 small files — what’s the actual limit and best doc strategy?

Hi everyone 👋
I’m setting up GitHub Copilot Spaces as a knowledge base for my project, but I’m hitting a size limit much earlier than expected, and I can’t find clear documentation about the quota/limits.

What I’m trying to do

• Create a Space so Copilot can answer questions and do better refactoring/impact analysis with more context.
• I can connect a GitHub repository successfully.
• Copilot suggests: “link specific files for better results.”
• So I tried to add references to specific files/folders (docs, specs, tests, etc.).

The problem

When linking specific files/folders, I get this error:

You've exceeded the size limit for this space. Remove some references to continue.

What confuses me:

• The Space shows a progress bar around 210%.
• I only referenced about 185 files, and each file is < 30KB (mostly .md and small config/test files).

This makes me suspect the limit may not be based on raw file size, or the progress bar may be calculated differently (tokens/indexing/embeddings), or there may be a bug.

Steps to reproduce

1. Create a new Copilot Space
2. Connect a GitHub repository
3. In the Space, try to add specific references (folders/files)
4. After adding ~185 files → the size bar goes beyond 100% (e.g., 210%)
5. The Space blocks adding more references with the message above

Expected behavior

• A clear explanation of:
  • What the limit actually is (MB? number of files? tokens? indexed content size?)
  • How the progress bar is calculated
• Or at least a guideline like:
  • “Max X files” / “Max Y MB” / “Max Z tokens” per Space

Questions

1. What are the exact Copilot Spaces limits?
   • Total content size per Space?
   • Number of references?
   • Per-file limits?
   • Token/index size limits?
2. How is the “% used” progress bar calculated?
   • Raw bytes vs extracted text vs tokenization/embeddings?
3. Are certain file types counted more heavily?
   • e.g., .lock, generated files, JSON snapshots, large config files, etc.
4. What’s the recommended document strategy for Spaces?
   • If we can’t reference many files, what should we prioritize?
   • One curated PROJECT_OVERVIEW.md?
   • A small set of key docs (architecture, ADRs, workflows, runbooks)?
   • Include tests and API specs or keep them minimal?
5. Any workarounds or best practices?
   • Avoid referencing whole folders?
   • Prefer fewer curated Markdown docs?
   • Known “gotcha” paths to exclude?

What I’ve tried / notes

• Repo connection works, but Copilot encourages linking specific files for better answers.
• The referenced files are mostly plain text (.md, small config/test files); no large binaries.
• I couldn’t find an official doc/spec about Copilot Spaces limits and how the quota is measured.

Suggestions (if this reaches the product team)

• Publish official limits and what unit they use.
• Show a breakdown of what consumes the quota (top folders/files by “cost”).
• Provide a “recommended docs template” for Spaces (Architecture / Domain model / Key flows / Runbook / Testing).
• Improve the warning message to include current usage, max usage, and what changed.

If anyone knows the real limits or has a proven strategy for which documents to add to a Space, I’d appreciate any guidance. 🙏

[TadashiDevs]

Yeah, that 210% progress bar is super misleading.

You definitely aren't hitting a storage limit (MBs) — you’re hitting a context / token budget.

Think of it this way: Since you already connected the repository, Copilot can “see” your code whenever it needs to. But when you manually add ~185 files, you’re trying to force-feed all that text into its active memory at once. That’s why it chokes, even with small files.

The fix that works for me:

Stop adding code files manually: Trust the repo connection for source code (.js, .ts, config).

Only reference the "Brain": Use the Space references just for high-level docs like Architecture, ADRs, or rules.

Basically, treat the references list as a cheat sheet for the AI, not a backup of your file system. Keep it to your top 20-30 docs and it should work fine.

Cheers!

[RajeshwarShingade]

Copilot Spaces quotas appear to be enforced on indexed semantic content, not raw repository size.

From experimentation, the Space “usage %” seems to include:

Extracted plain text
Tokenization overhead
Embedding/index storage
Possibly duplicated semantic chunks across files

This explains why:

Many small .md, .json, and test files can exceed the limit
The progress bar can jump past 100% unexpectedly
Folder references consume far more than expected

What to prioritize in a Space:

Highlevel intent and structure, not raw source
Architecture overview
Domain concepts
Critical workflows
Operational notes / runbooks

What to avoid:

Entire folders
Tests, snapshots, fixtures
Lock files and generated configs
Large JSON/YAML specs unless summarized

Proven workaround:
Create a single “Copilotoptimized” document that consolidates:

Project purpose
Architecture diagram (described in text)
Core modules
Important APIs
Common questions / decisions

Then reference that document instead of dozens of files.

Agreed that GitHub should:

Publish hard limits (tokens / embeddings)
Show a perfile “cost” breakdown
Improve the error message with current vs max usage

Until then, curation beats volume for Copilot Spaces.

Copilot Spaces work best as a curated semantic context, not a mirror of your repository.