Saving tokens in GitHub Copilot

If you are not sure why you need a premium reasoning model, start with Auto.

• It routes by task complexity, availability and system health
• You will not keep an expensive model pinned for routine work
• 10% discount on the multiplier for paid plans
• Manual override for architecture or hard debugging remains available

In practice, for normal work this means you save 10% compared with pinning a specific model — and often also get a cheaper model that can handle the task.

Understand this repository and fix the login problem.

Focus on src\auth\login.ts and tests\auth\login.test.ts. Bug: validateEmail rejects user+tag@example.com. Add a test and fix only this behavior.

Rule: concrete file paths are cheaper than exploring the whole repository.

Bonus: batch related tasks into one prompt.

In src\auth\login.ts: 1. validateEmail — allow user+tag@example.com 2. add a test in tests\auth\login.test.ts 3. add a docstring to the function 4. record the change in CHANGELOG.md

Instead of "do you understand the whole thing?", ask:

Find the smallest set of files I need to understand the event-driven flow. List only paths and one sentence why. Do not summarize the whole repo.

Only then give the task — knowing what is relevant.

Explain in detail everything you changed.

List: changed files, why, tests. Max 5 bullets.

"Caveman" output style for reports:

Done. List: files, why, validation, risks. No intro. ≤5 bullets.

The same information in three versions. It shows the "sweet spot" between readability and compactness.

For terminal output, a screenshot is an antipattern. Instead of 5,000 lines of CI log, send only the relevant excerpt:

Command: npm test Exit code: 1 Relevant error: TypeError: Cannot read property 'id' of undefined at UserService.findById (src/services/user.ts:42) Last 30 lines: ...

For visual questions, it is more efficient to use Playwright MCP or browser canvas.

The tokenizer is trained mostly on English text, but this is not dogma:

1. Structured format erases most of the difference
2. Quality comes before saving
3. Cost of a mistake > cost of tokens

Create a POST endpoint /api/users that validates required fields name and email, returns 400 on error and 201 with the created user on success.

POST /api/users
Validate: name req, email req+valid
400 errors
201 user

Please, could you create a new HTTP endpoint of type POST at path /api/users that accepts JSON with fields name and email, validates that both values are present and the email is in the correct format, and on success returns 201 Created with the created user object, while on validation error it returns 400 Bad Request with error details?

Always-on instructions are a recurring tax — you pay them on every turn.

Let the agent write context for the future.

Write into .github\skills\auth-flow\SKILL.md a concise (≤60 lines) description of the auth flow as we have just understood it. Focus on: entry points, key files, pitfalls, what to do when changing it. No prose, only lists and links.

MCP has three hidden cost layers:

1. Tool definitions and JSON schemas loaded into context
2. Tool call arguments as output tokens
3. Tool results replayed as input in the next step

1. search or list candidates 2. choose one 3. fetch only the detail you need for the decision 4. summarize the result before continuing

If an algorithm exists that solves the task exactly, do not force the model to do it across several turns.

Typical candidates:

• JSON → XML / CSV conversion
• Token counting, log slicing, schema validation
• Dependency graph extraction
• Sort, filter, dedupe large data
• ID generators, parameterized templates

The economics are always the same: old cache is cheapest, fresh input ~10×, output ~60×.

/chronicle tips, /chronicle cost-tips and /chronicle improve serve as regular self-reflection.

Parallel agents can save wall-clock time, but multiply input tokens if they read the same files.

Use a subagent when:

• The work is truly independent
• Context can be sharded by service / file area
• A cheaper model is enough
• The result can come back as a short summary

Do not use when:

• All agents need the same context
• The task is sequential
• Coordination overhead dominates

Token efficiency is not a one-time audit — it is an engineering discipline with a feedback loop.

Measure:

• input, output, cached tokens
• number of turns
• tool calls
• latency
• retry rate
• quality of result

on: pull_request
  paths: ['.github/skills/**', 'AGENTS.md', '.github/prompts/**']

steps:
  - run: copilot-token-lab run --scenarios skills-regression --iterations 3
  - run: copilot-token-lab compare --baseline main --head HEAD
  - fail-if: weighted_units_delta > +10% AND quality_score < baseline
  - comment-pr: report.md