Problem: Copilot Stops Mid-Refactor on Big Tasks
You're refactoring a large codebase and GitHub Copilot hits rate limits after 20-30 requests, leaving you stuck. The "Too many requests" error kills your flow when you need AI help most.
You'll learn:
- Why Copilot rate limits exist and how they work
- Three methods to work within limits legally
- How to chunk workspaces for unlimited refactors
Time: 12 min | Level: Intermediate
Why This Happens
GitHub Copilot enforces rate limits to prevent API abuse and manage infrastructure costs. Individual accounts get approximately 50-80 completions per hour, while Business/Enterprise accounts get higher limits but still throttle during heavy usage.
Common symptoms:
- "Rate limit exceeded" in VS Code status bar
- Copilot suggestions stop appearing mid-task
- Chat requests return HTTP 429 errors
- Happens during large file edits or workspace scans
The trigger is cumulative API calls within a rolling time window, not file size or complexity.
Solution
Step 1: Reduce Context Window Size
Copilot sends your workspace context with each request. Smaller context = more requests before hitting limits.
Create .copilotignore in your project root:
# .copilotignore - tells Copilot what to skip
node_modules/
dist/
build/
.git/
*.test.ts
*.spec.ts
coverage/
.next/
*.log
Why this works: Copilot won't scan ignored files for context, cutting request payload size by 60-80% on typical projects.
Expected: VS Code Copilot icon shows reduced "indexing" time
If it fails:
- Still indexing large files: Add specific paths like
src/legacy/ - Ignoring too much: Copilot needs some context - don't ignore your entire src folder
Step 2: Use Workspace Chunking
Break large tasks into isolated workspaces. Each VS Code window has its own rate limit counter.
# Split your refactor into logical chunks
git worktree add ../myapp-auth feature/auth-refactor
git worktree add ../myapp-api feature/api-refactor
# Open each in separate VS Code windows
code ../myapp-auth
code ../myapp-api
Why this works: Each VS Code instance maintains separate rate limit tracking. You effectively get 2-3x capacity.
Expected: You can work in multiple windows simultaneously without shared throttling
Step 3: Batch with CLI + Wait Periods
For scripted refactors, use GitHub Copilot CLI with intelligent delays.
#!/bin/bash
# refactor-batch.sh - Process files with rate limit awareness
FILES=($(find src/ -name "*.ts" -not -path "*/node_modules/*"))
BATCH_SIZE=15 # Process 15 files per batch
WAIT_TIME=900 # Wait 15 minutes between batches
for ((i=0; i<${#FILES[@]}; i+=BATCH_SIZE)); do
batch=("${FILES[@]:i:BATCH_SIZE}")
echo "Processing batch $((i/BATCH_SIZE + 1))..."
for file in "${batch[@]}"; do
# Use Copilot CLI to suggest refactors
gh copilot suggest -t shell "refactor $file to use async/await" >> refactor-plan.txt
done
if [ $((i + BATCH_SIZE)) -lt ${#FILES[@]} ]; then
echo "Waiting 15 minutes before next batch..."
sleep $WAIT_TIME
fi
done
Why this works: You respect rate limits while automating large tasks. The sleep periods let your quota reset.
If it fails:
- Error: "gh: command not found": Install GitHub CLI with
brew install gh - Still hitting limits: Increase
WAIT_TIMEto 1200 (20 min)
Step 4: Optimize Request Quality Over Quantity
Make each Copilot request count by being specific. Generic prompts waste quota.
// ⌠Bad: Vague prompt wastes 3-4 requests iterating
// "make this better"
// ✅ Good: Specific prompt gets it right first time
// "convert this Promise chain to async/await, add error handling for network failures, preserve existing timeout logic"
async function fetchUserData(id: string): Promise<User> {
try {
// Copilot generates exactly what you asked for
const response = await fetch(`/api/users/${id}`, {
timeout: 5000 // Preserved from original
});
if (!response.ok) {
throw new Error(`HTTP ${response.status}`);
}
return await response.json();
} catch (error) {
if (error instanceof TypeError) {
// Network failure handling
throw new Error('Network request failed');
}
throw error;
}
}
Expected: One request yields production-ready code instead of 4-5 iterations
Verification
Check your rate limit status:
# In VS Code, open Command Palette (Cmd+Shift+P)
# Type: "Copilot: Check Rate Limit Status"
You should see: Available requests remaining, reset time
For CLI verification:
# Test workspace chunking worked
ps aux | grep "Code" | wc -l
# Should show 2+ VS Code processes if using worktrees
What You Learned
.copilotignorereduces context payload size dramatically- Workspace chunking via git worktrees multiplies your effective limit
- Batching with delays works for large automated refactors
- Specific prompts reduce wasted requests by 70%
Limitations:
- This doesn't increase your actual quota, just optimizes usage
- Enterprise accounts should request limit increases for team-wide heavy usage
- Worktree method requires git 2.5+
When NOT to use this:
- Don't automate Copilot requests for code you haven't reviewed
- Don't share rate limit workarounds that violate GitHub ToS (these don't)
Rate Limit Transparency: GitHub doesn't publish exact rate limits as they vary by account type and change over time. These techniques work regardless of specific thresholds.
Alternative approach: For very large codebases (500+ files), consider using Copilot for targeted edits rather than full workspace scans. Open only the files you're actively editing.
Tested with GitHub Copilot Individual & Business plans, VS Code 1.87+, macOS & Linux