GitHub Copilot AI Credits Optimization — Module 2: Developer Efficiency Workshop

Duration: ~135 minutes (including one 10-minute break)
Format: Standalone Presentation + Hands-On Exercises + Optional Live Instrumentation Audience: Developers, technical leads, Copilot champions
Focus: Interface selection, context/customization and instruction efficiency, session lifecycle and cache awareness, and model strategy with a before/after evaluation loop — the developer-level habits that reduce AI-credit consumption without sacrificing quality

Note: This is Module 2 — Developer Efficiency of the GitHub Copilot AI Credits Optimization curriculum. It is fully standalone — you can run it on its own with a developer-only audience, no admin access required. It is also designed to slot into the full curriculum alongside:

• Module 1 — Admin Guardrails: Module 1 workshop
• Module 3 — FinOps & Team Operating Model: Module 3 workshop
• Full curriculum overview: GitHub Copilot AI Credits Optimization

Workshop Overview

GitHub Copilot billing for Business and Enterprise plans is usage-based, measured in GitHub AI Credits. Module 1 covers the admin guardrails (budgets, policies) that bound total spend. This module — Developer Efficiency — is for the people actually writing prompts and running agent sessions every day. It gives developers, technical leads, and Copilot champions a practical, non-admin-heavy playbook: which interface to reach for, how to scope context and instructions, how session and cache mechanics affect cost, and how to choose a model — all in service of completing verified work efficiently, not chasing the lowest price per turn.

Note: The 10% Auto discount and pricing snapshots reflect GitHub documentation as verified on 2026-08-08. Cache-expiration windows, customization triggers, Copilot Memory, billed surfaces, session-limit behavior, VS Code /fork cache behavior, and cached-input wording were re-verified on 2026-08-30. Re-verify all volatile claims against the Appendix sources before delivery.

Learning Objectives

• Explain the AI-credit billing basics relevant to a developer: 1 credit = $0.01, unlimited completions/next-edit suggestions, and which interfaces and surfaces are billed
• Explain how usage-based billing differs from the former premium-request mental model
• Choose the right interface (completions, Ask, Edit, Agent, Copilot CLI, cloud agent) for a given task
• Apply context- and instruction-efficiency practices: smallest authoritative context, clear task/context/stop conditions, concise grounded custom instructions, scoped instructions, narrow working-directory/tool scope, and relevant MCP/tool sets only
• Classify each customization as always-on recurring context or on-demand context, and keep, scope, or retire it accordingly
• Apply Copilot Memory hygiene: review stored facts and preferences, remove stale or incorrect entries, and never rely on memory for secrets or one-time task detail
• Use session boundaries deliberately — new sessions between unrelated tasks or research/plan/implement phases, and the Copilot CLI session-control commands for long-running work
• Write a six-field clean-session handoff that restarts work in a fresh context without losing decisions or constraints
• Explain what invalidates cached context (model switches, reasoning changes, tool changes, expired sessions), and state cached-input pricing as typically about 10% of that model's fresh-input price rather than a universal ratio
• Write and explain a valid Copilot CLI AI-credit session-limit command, identify the equivalent Copilot SDK setting, and explain how these soft controls complement monthly budgets
• Build a model strategy centered on Auto model selection, proportional reasoning, and scoped subagents — reserving powerful models for cases that justify them
• Recognize false-economy anti-patterns and evaluate cost per completed, verified task rather than cost per turn
• Compare models by full cost per durable accepted outcome and recognize how multi-stage workflow yield compounds
• Run a before/after evaluation loop on a fixed task set of 5–10 representative tasks, changing one variable at a time
• Draft a 30-day personal/team habit plan to make these practices stick

Prerequisites

Important: No exercise in this workshop requires making a live paid AI request beyond what you'd normally run. Every exercise can be completed by analyzing supplied sample prompts, transcripts, inventories, datasets, and worksheets from the LAB guide. The live instrumentation in Section 4 is explicitly optional and spends AI credits.

Session Agenda

Total: 135 min (2h 15min)

Welcome & Developer Billing Primer (15 min)

Key Points

• 1 AI credit = $0.01 USD — that's the entire conversion you need as a developer; deeper budget math (pools, ULBs, spending limits) belongs to Module 1
• Code completions and next-edit suggestions (NES) remain unlimited on paid plans and are not billed in AI credits — write code in your editor with completions on and never think about credits for that part of your flow
• Chat, Edit mode, Agent mode, Copilot CLI, Copilot cloud agent, Copilot Spaces, GitHub Spark, and third-party coding agents are all billed in AI credits — anything that involves a conversational or agentic request to a model draws from your credits
• Every billed interaction is priced from token categories, not a flat per-request fee:
  • Input tokens — your prompt plus whatever context is attached (files, terminal output, prior turns)
  • Cached input tokens — context reused from earlier in an active session, priced lower than fresh input
  • Cache write tokens — the cost some models charge to write context into the cache the first time
  • Output tokens — what the model generates back to you, typically the priciest category per token
• You do not need budget-level math to act on this — the practical takeaway is: the more unnecessary context and output you generate, the more tokens you burn, and this workshop is about trimming the unnecessary parts without trimming quality

Billed vs. Unbilled at a Glance

Note — surfaces developers often forget: Copilot Spaces is a billed surface, not free context storage; GitHub Spark is also included in GitHub's billed AI-credit feature list. Third-party coding agents are in public preview, must be enabled by policy, and consume AI credits plus GitHub Actions minutes for the agent session. Module 1 covers the same billed-surface list from the admin side; see Usage-based billing for organizations and enterprises.

Replace the Premium-Request Mental Model

Important: Request count alone no longer explains cost. Two requests can consume very different credits when their context, model, tool output, reasoning, or generated output differs.

Note: For the full budget, pooling, and policy mechanics behind AI credits, see Module 1 — Admin Guardrails. This module assumes credits exist and focuses only on what you, as a developer, control.

One-Minute Paired Check

With a partner, classify each activity as billed or unbilled:

1. Accept an inline code completion in the IDE
2. Ask Copilot Chat to explain a test failure
3. Accept a next edit suggestion (NES)
4. Start a Copilot CLI session that sends a prompt to a model
5. Ask GitHub Spark to generate or update an application

Answer: 1 and 3 are unbilled; 2, 4, and 5 are billed. Opening an interface or configuring a control is not itself the billing event — a request sent to the model is.

Discussion Points

• Before today, did you know completions/NES were unbilled while Chat/Agent/CLI usage was billed?
• Which token category — input, cached input, cache write, or output — do you suspect your own sessions consume the most of?
• What's one habit you already suspect is burning more tokens than it needs to?

1. Right Interface for the Task (Hands-On) (15 min)

Key Points

• Use the right interface for the task. Completions/NES are unlimited — reserve billed interfaces (Chat/Edit/Agent/CLI/cloud agent) for work that actually needs reasoning, multi-file coordination, or terminal-native automation
• Matching interface to task avoids two failure modes: using a billed, heavyweight interface for a trivial edit, and using a lightweight interface for work that genuinely needs broader context or multi-step execution

• Interface choice is not just about cost — it's about giving the model the right amount of autonomy and tooling for the job. An Agent-mode task given to Ask mode will stall; a one-line rename given to Agent mode wastes a turn deciding it doesn't need to explore
• Copilot Spaces, GitHub Spark, and third-party coding agents are billed surfaces too, but they are shared-context, application-building, and task-delegation surfaces rather than day-to-day coding interfaces — the same "smallest sufficient interface" rule applies to them

Discussion Points

• Where on your team does interface choice default to "Chat/Agent for everything," even for small edits?
• Has completions/NES adoption on your team ever stalled because Chat felt more familiar?
• What would it take to make "smallest sufficient interface" a habit rather than an afterthought?

2. Context, Customization & Instruction Efficiency (Hands-On) (35 min)

Key Points

• Smallest authoritative context: attach only the file(s), snippet, or documentation actually needed for the task — not the whole repository "just in case." Extra context becomes extra input tokens on every turn
• Clear task, context, and stop conditions make the biggest difference of anything on this list:
  • Task: state what you want changed, where, and what "correct" looks like — not just "fix this"
  • Context: name the specific files, errors, logs, or examples that matter, so the agent doesn't have to explore to find them
  • Stop condition: tell the agent what "done" looks like, so it doesn't keep iterating, refactoring unrelated code, or adding extra commits past the point of value
• Concise, grounded custom instructions: keep repository-wide instructions (for example, copilot-instructions.md or AGENTS.md) short and specific — they apply automatically to every interaction in their scope, so noise there is a recurring cost (see the always-on versus on-demand table below)
• Scoped/path-specific instructions: put detail that only applies to part of the repo (a language, a service, a folder) into scoped instructions that load only when relevant, instead of bloating the repo-wide file
• Use only relevant MCP/tool sets: a large MCP server's full tool catalog adds tool definitions to every request; enable only the toolsets the task actually needs
• Start in the narrowest correct working directory: Copilot CLI limits file access to the current working directory and its subdirectories by default. Use /cwd to inspect or change that root and /add-dir only when the task genuinely requires another directory
• Separate tool visibility from tool approval: --available-tools and --excluded-tools control which tools the model can see; --allow-tool and --deny-tool control approval behavior. Denial rules take precedence, and permission flags do not expose a tool that was filtered out
• Keep repository discovery clean: maintain .gitignore and other applicable ignore rules for generated output, dependencies, and non-source artifacts so searches and context collection focus on authoritative files
• Output concision: ask for the diff or the specific change rather than a fully restated file when a shorter response satisfies the task
• Deterministic guardrails — tests, linters, security checks: unit tests, linters, and security scans give a clear pass/fail signal that catches drift early. Teams that invest here see fewer retries and more predictable results, which lowers total token consumption even though each individual check adds a small amount of tokens upfront

What Good Custom Instructions Contain (and Don't)

Important — a prompt that's too short is not the goal. A prompt that omits the context the model actually needs produces a wrong or incomplete answer, which triggers follow-up prompts that cost more in total than one well-scoped prompt would have. The goal is the smallest sufficient prompt and context — not the shortest possible one.

Always-On vs. On-Demand Customization

Not every customization contributes its full body to every turn. Some are recurring context; others load their full instructions or content on demand when invoked, selected, or chosen as relevant. Knowing which is which tells you where trimming actually pays.

Trigger behavior source: Copilot customization cheat sheet and About agent skills.

Important: "More customization" is not automatically "more cost per turn." The recurring cost concentrates in always-on instruction scope and enabled tool schemas. Moving detail out of always-on instructions and into a prompt file, custom agent, or skill keeps the capability while removing it from every turn. Use /context in Copilot CLI to see the actual split between instructions, tool definitions, and message history before you trim anything.

Copilot Memory Hygiene

Copilot Memory is in public preview and is subject to change. It lets Copilot store and reuse what it learns instead of re-reading the same conventions every time.

Source: About GitHub Copilot Memory.

Hygiene practices:

• Review your stored memories on a schedule — at minimum when a convention changes, when a project is archived, or when Copilot repeats advice that no longer matches the codebase. Users can view and delete their own preferences; repository owners can review and delete repository-level facts (Managing Copilot Memory for your personal account)
• Delete incorrect memories immediately — repository-level facts are re-checked against the current branch and skipped when they fail validation, but obsolete entries should still be removed; user-level preferences rely on Copilot's judgment that they still apply
• Never persist secrets, credentials, tokens, customer-sensitive data, or personal data in memory or in any instruction file. Secrets belong in a secret store; sensitive data belongs out of prompts entirely
• Never persist one-time task detail — ticket numbers, temporary branch names, or "for this sprint only" context are prompt content, not durable facts
• Keep the boundary clear: durable, reviewable, team-owned rules belong in custom instructions where they are versioned and code-reviewed; memory is Copilot's own learned layer on top, and it needs periodic human review
• Memory changes what context gets assembled, so treat it as a correctness and consistency control that you audit — not as a guaranteed credit reduction

Note — consistency with Optional Module 4: In Copilot CLI prompt mode (-p), memory is off by default and must be opted into with --enable-memory. Unattended automation should make that an explicit, recorded lane decision rather than an accident — see Optional Module 4.

Discussion Points

• What's the difference between trimming a prompt for efficiency and trimming away information the model actually needs?
• Does your team's current copilot-instructions.md (or equivalent) read as specific and grounded, or generic?
• Which of your team's customizations are genuinely always-on, and which are on-demand and therefore cheap to keep?
• Which review trigger belongs in your team's workflow: an architecture change, repository archival, or Copilot repeating stale advice?
• Where does your team currently skip deterministic checks (tests/linters/security scans) in a way that likely costs more tokens later through rework?

☕ Break (10 min)

3. Session Lifecycle, Handoff, Cache & Session Limits (Hands-On) (25 min)

Key Points

• Start a new session when you switch to an unrelated problem. A long thread carries its entire history into every new request — an unrelated question doesn't need yesterday's debugging context
• Start a new session between research, planning, and implementation phases. Research explores the codebase; planning produces a structured spec (often with a stronger reasoning model); implementation executes against that plan (often with a cheaper, execution-focused model). Carrying all three phases in one thread accumulates context none of the later phases need
• For a long, still-relevant Copilot CLI thread, don't restart — manage it instead with the session-control toolkit below
• Cache awareness: within one active, on-topic session, reusing a stable session lets the model reuse cached context. Cached input is typically billed at about 10% of that model's fresh-input price — roughly 10x cheaper — but this is not universal. Some models price cached input higher than that, so check the selected model's row on the official pricing page before quoting a figure or encoding a ratio in a team policy (Models and pricing for GitHub Copilot)
• What invalidates the cache (forces the full context to be re-sent and billed as fresh input):
  • Switching models mid-session — a different model can't reuse another model's cache
  • Changing reasoning effort, context size, or the set of enabled tools/MCP servers mid-session
  • Coming back to an old, expired session — caches currently expire after 24 hours of inactivity for OpenAI models and after 1 hour for most others. Returning after the applicable window rebuilds the cache from scratch; re-verify these windows before delivery (Optimizing your AI usage)
• Set an AI-credit session limit for agentic work: this capability is in public preview. In interactive Copilot CLI, use /limits set max-ai-credits NUMBER; use /limits unset to remove it. In non-interactive mode, pass --max-ai-credits NUMBER. The Copilot SDK equivalent is sessionLimits.maxAiCredits when creating or resuming a session (CLI session limits, SDK session limits)
• Session limits are soft: an in-progress response completes, so actual use can exceed the configured number slightly. Interactive CLI prompts you to reset or raise the limit; non-interactive CLI ends; SDK applications handle the exhausted-limit event
• Session limits are soft, per-task controls that complement — not replace — monthly user-level budgets and spending limits, which are set by admins and cover total consumption (see Module 1)

Copilot CLI Session-Control Toolkit

Compaction Is a Tradeoff, Not a Reflex

• Copilot CLI automatically compacts near the context-window limit, and /compact lets you trigger it earlier
• Compaction sends the conversation for summarization, replaces the old history with a structured summary, and frees most of the context window
• Fine-grained details can be lost; review /session checkpoints if continuity or an earlier decision matters
• Compact a long, still-relevant thread before its next phase — do not compact after every turn or use it to preserve an unrelated conversation that should simply start fresh

Important — three things this section does not claim: (1) it does not promise one universal cached-input discount ratio across all models, (2) it does not say you should never start a new session, and (3) it does not treat compaction as free or lossless. Restart when the problem or phase changes; compact when the task remains relevant and the smaller summary is worth the summarization step and possible loss of detail.

Clean-Session Handoff Template

When you do start a clean session, the cost you want to avoid is re-deriving what the last session already figured out. Write these six fields — in the last session or from your notes — and paste them as the first message of the new one.

• Keep it to roughly a screen of text. A handoff longer than the history it replaces defeats the purpose
• Write it in the outgoing session while the detail is fresh; asking the outgoing session to draft it is a legitimate, cheap use of a turn
• A handoff complements — it does not replace — the built-in continuity controls:

Discussion Points

• Where does your team currently restart sessions unnecessarily, forfeiting the cache discount?
• Where does your team keep one sprawling session going long after the topic has changed?
• Would a default AI-credit session limit help or hinder your team's typical agentic workflows?
• How would you explain "cache invalidation" to a teammate who just wants to know "why did this turn suddenly cost more"?
• Which of the six handoff fields does your team most often lose when work moves between sessions, days, or people?

4. Model Strategy, Verification & Before/After Evaluation (Hands-On) (25 min)

Key Points

• Auto model selection is the default choice for most work. It routes each task to a model matched to its complexity along cache-friendly boundaries (never switching mid-task) and applies a 10% discount on the model-cost portion of the bill for paid plans
• Auto is generally available in Copilot Chat on github.com, VS Code, Copilot CLI, and the GitHub Copilot app. Other IDEs and extensions may offer an Auto option that's optimized primarily for reliability/availability rather than task-complexity routing — confirm current behavior for your specific IDE before assuming identical behavior everywhere
• Use regular reasoning by default for supported models, and raise the reasoning level only for tasks that clearly need deeper analysis. Configurable reasoning is available in VS Code and Copilot CLI for supported models; higher reasoning consumes more tokens
• Lightweight models for routine, well-scoped tasks (formatting, documentation updates, small well-defined edits) where you already know a smaller model reliably succeeds
• Reserve manually selected powerful/reasoning models for architecture decisions, complex debugging, and cases where retries or quality requirements clearly justify the added cost — not as a default "just in case" choice
• Run subagents on cheaper, scoped models. A subagent operates in its own session with context scoped to one focused task and doesn't inherit the main agent's full conversation history, so a lighter model is often sufficient — and it doesn't disturb the main agent's cache the way a mid-session model switch would
• There is no fixed multiplier table to memorize under usage-based billing — cost is driven by tokens × per-model, per-category pricing, not a flat per-request multiplier

Quality-First Verification & False-Economy Myths

• Judge cost per completed, verified task — not cost per turn. A cheap, low-quality result that needs a human rework cycle, or a second and larger request to fix it, costs more in total credits and time than doing it right once
• Pair deterministic guardrails (tests, linters, security checks from Section 2) with model choice: a well-scoped task run on an appropriately capable model, verified by a fast automated check, is the efficient path — not the cheapest model regardless of outcome
• Use full cost per durable accepted outcome for model escalation, not AI-credit price alone. Full cost includes AI usage plus human review/correction and relevant compute; durable acceptance requires the result to pass its defined acceptance rule without material correction and remain valid through its stabilization period
• Keep multi-stage agent workflows as short and recoverable as the task allows. When every stage must succeed, end-to-end acceptance compounds across the chain; removing a redundant stage or making one failed stage retryable can improve economics more than trimming a small number of tokens

Full-Cost Model Decision

Note: The powerful model costs more per attempt but less per durable accepted outcome. This is a decision framework, not a universal model ranking; use measured acceptance and full-cost data for the task category.

Before/After Evaluation Loop (Fixed Task Set)

Every change in this workshop — a trimmed instructions file, a pruned tool set, a new session boundary, a different model — is a hypothesis. The loop below is how you turn it into evidence instead of an opinion. It is tool-neutral: no product, extension, or vendor beyond Copilot itself is required.

Record these fields per task, per arm:

• Decision rule: adopt the change only when full cost per durable accepted outcome improves and durable acceptance does not get worse. A cheaper arm with lower acceptance is a regression
• One variable at a time. If you change the model and the instructions file, you cannot attribute the result to either
• Small sets are fine. Five to ten representative tasks give a directional answer for a team habit decision; they do not give a statistically robust org-wide claim, so label the result accordingly
• No paid call is required to learn this. The LAB supplies a completed before/after dataset — you do the arithmetic and make the decision on paper

Optional — live instrumentation (spends AI credits): If your team wants real numbers instead of the supplied dataset, capture them with /usage and /context in Copilot CLI, the CLI Chronicle session data and its cost tips, and the cost/session signals your IDE exposes. This is optional, it consumes credits, and it should run on a task set you already intended to complete.

Discussion Points

• Where does your team currently default to the most powerful model "just in case," even for routine tasks?
• What's one deterministic check (test, linter, security scan) your team could add tomorrow that would reduce rework?
• Have you seen a case where a cheap or fast answer actually cost more time and credits once rework is counted?
• Should model selection be a personal habit, a team default, or something enforced by policy?
• Which optimization on your team is currently believed rather than measured, and what fixed task set would settle it?

5. Hands-On Optimization Capstone & Close (10 min)

Key Points

• Every practice in this workshop — interface choice, context and customization, session lifecycle and handoff, and model strategy — compounds. None of them is a silver bullet on its own
• The most durable outcome of this workshop is a written personal or team habit plan you actually revisit, not just a good feeling for one afternoon
• Small, consistent habit changes (trimming one instructions file, adopting one session-boundary rule) tend to outperform an ambitious plan nobody follows

Discussion Points

• Which single habit from this plan will you start using in your very next Copilot session?
• What would make you tell a teammate to adopt one of these habits today?
• If your team adopts this plan, how will you know in 30 days whether it worked?

Recap

• Right interface first: completions/NES for small local edits; Chat/Edit/Agent/CLI/cloud agent for work that needs reasoning or coordination — and remember Copilot Spaces, GitHub Spark, and third-party coding agents are billed surfaces too
• Smallest authoritative context and clear task/context/stop conditions beat "shorter prompts" as a rule of thumb
• Concise, grounded instructions and scoped tool sets keep every request lean; always-on instructions and enabled tool schemas are the recurring cost, while prompt files, custom agents, and skills load on demand
• Review Copilot Memory (public preview) like any other stored state: delete stale or wrong entries, and never persist secrets or one-time task detail
• Session boundaries and cache awareness matter — new session for a new problem or phase, /context//compact for a long relevant CLI thread, and awareness of what invalidates the cache
• Cached input is typically about 10% of a model's fresh-input price, but verify the model before quoting or encoding a ratio
• Use the six-field clean-session handoff when you deliberately leave a thread; it complements /compact, /resume, and VS Code /fork
• Use /usage, /resume, /cwd, and /add-dir intentionally; keep file and tool scope no broader than the task requires
• Auto model selection is the default; manual choice (lightweight or powerful) is the justified exception
• Judge cost per completed, verified task — never per turn — and don't fall for false-economy myths
• Compare model and workflow choices by full cost per durable accepted outcome; keep multi-stage chains short or recoverable
• Settle disagreements with a before/after loop on a frozen 5–10 task set, changing one variable at a time

Note — where this goes next: These habits are individual and interactive. When the same work runs unattended — Copilot CLI in a script, scheduler, or CI job, or a Copilot SDK service — nobody reviews the cost of each call, so the habits have to become enforced configuration. That is the subject of Optional Module 4: Agent Fleet Efficiency and Cost Governance, an optional add-on outside the core curriculum duration.

Appendix: Official Sources & Facilitator Reference

Key URLs

Note: Dated facts carry multiple verification dates. The 10% Auto discount and pricing snapshots reflect the docs as verified on 2026-08-08; cache-expiration windows, the customization trigger model, Copilot Memory behavior and preview status, and the cached-input formulation were re-verified on 2026-08-30; the billed-surface list and third-party-agent preview status were re-verified on 2026-09-01. Re-verify against these live URLs before every delivery of this workshop.

Instructor Preflight Checklist

• Re-verify the Auto model selection discount rate against the live About Copilot auto model selection page
• Re-verify cache-expiration windows against Optimizing your AI usage, then check cached-input pricing against Models and pricing and spot-check that cached input is still roughly 10% of fresh input for the models your team uses
• Re-verify that Copilot Memory is still in public preview, and that its scopes are still repository-level facts and user-level preferences (About GitHub Copilot Memory)
• Re-verify the billed-surface list, including Copilot Spaces, GitHub Spark, and third-party coding agents, and the preview status of third-party coding agents
• Re-verify the customization trigger column against the live Copilot customization cheat sheet
• Confirm Copilot CLI is installed and that /usage, /context, /compact, /cwd, /add-dir, /session checkpoints, /limits set, /limits unset, and --enable-memory match the current command reference; have a recorded/screenshot fallback ready
• Re-verify session-limit preview status and stop behavior, VS Code /fork cache preservation for the next request, Auto routing and availability, and subagent context isolation against their linked primary sources
• Bring a real (or de-identified sample) copilot-instructions.md excerpt for the customization inventory exercise
• Print or share the LAB guide worksheets (before/after prompt, customization inventory, tool inventory, memory triage, session limit, clean-session handoff, before/after evaluation, 30-day habit plan) for attendees without laptops
• Confirm this module is running standalone or as part of the full curriculum, and mention Module 1/Module 3 accordingly during the welcome

Backup Plan

If a live CLI or Chat demo is unavailable (no license, connectivity issue, or UI change):

1. Walk through the Interface Comparison and Billed vs. Unbilled at a Glance tables as a slide-only discussion
2. Use the supplied before/after prompt, sample instructions excerpt, tool inventory, and before/after evaluation dataset from the LAB guide instead of live editing or live instrumentation
3. Reference the official docs URLs above and screen-share the documentation pages as a substitute for the live product UI
4. Keep the hands-on worksheets (LAB guide) as the primary artifact attendees leave with, regardless of demo availability

Workshop guide for GitHub Copilot AI Credits Optimization — Module 2: Developer Efficiency (standalone; part of the GitHub Copilot AI Credits Optimization curriculum alongside Module 1 — Admin Guardrails and Module 3 — FinOps & Team Operating Model)