GitHub Copilot AI Credits Optimization — Optional Module 4: Agent Fleet Efficiency and Cost Governance Workshop

Duration: 170 minutes (including one 10-minute break); the optional runnable lab appendix adds 45 minutes and is delivered separately
Format: Optional advanced module — presentation + design exercises + optional runnable appendix
Audience: Platform and DevEx engineers, automation and SRE-adjacent engineers, Copilot program owners who operate unattended Copilot automation
Focus: Programmatic GitHub Copilot CLI and SDK automation — fixed session cost, lane profiles, isolation, pre-spend gates, layered budgets, failure handling, durable landing, and safe rollout of cost changes

Note: This is Optional Module 4 of the GitHub Copilot AI Credits Optimization curriculum. It is not part of the advertised 7-hour-10-minute core (Modules 1–3) and is not required for any core learning path. Deliver it only for teams that already run — or are about to run — Copilot programmatically in scripts, schedulers, workers, or CI/CD.

Important: Every product behavior, flag, default, and feature status in this module was verified against GitHub documentation on 2026-08-12, and the command surfaces were cross-checked against Copilot CLI v1.0.79 help output on the same date. Copilot CLI and SDK surfaces change quickly, and several controls used here are public preview or experimental. Re-verify every flag in the Appendix control reference — and re-run copilot help, copilot help environment, and copilot help limits for your installed version — before each delivery.

Workshop Overview

Modules 1–3 optimize what a person does with Copilot and what an organization measures. This optional module addresses a different failure mode: unattended automation that spends AI credits while nobody is watching.

A fleet is any set of programmatic Copilot invocations — a nightly batch, a queue worker, a scheduled audit, a CI step, or an SDK service. In a fleet, every configuration decision is multiplied by invocation volume, and every unbounded input, silent retry, duplicated worker, or discarded result becomes a recurring cost line instead of a one-time annoyance.

This module treats fleet cost as an engineering problem with four levers:

Note: This module does not reteach Modules 1–3. It assumes their vocabulary — AI credits, token categories, cached input, budgets, user-level budgets, durable accepted outcomes, and full cost per durable accepted outcome — and extends it to unattended work.

Learning Objectives

By the end of this module, participants will be able to:

1. Measure the fixed and variable cost of a programmatic Copilot lane, and design a repeatable baseline experiment instead of estimating from intuition.
2. Build a least-context, least-tool, least-permission lane profile using documented Copilot CLI controls, with feature status recorded for every preview or experimental control used.
3. Design safe pre-spend gates and a complete cache key that cannot serve a stale or wrong verdict.
4. Design layered budget, fan-out, retry, backoff, and circuit-breaker controls that fail closed without generating retry storms.
5. Verify that paid output lands durably, is consumed downstream, and is attributed to a durable accepted outcome.
6. Produce a canary-ready fleet optimization plan with an explicit quality-parity gate and rollback trigger.

Each objective is exercised in the paired lab: Objective 1 → Lab 1, Objective 2 → Lab 2 and Lab 3, Objective 3 → Lab 4, Objective 4 → Lab 5, Objectives 5 and 6 → Lab 6.

Prerequisites

Important: No core section of this module requires making a paid AI request. All six core exercises are design and review activities completed with the supplied worksheets and answer keys. The runnable appendix in the lab guide is optional, bounded, and clearly labeled, and it must never be run against a production repository, production identity, or customer data.

Important: Tool-permission flags discussed in this module are a security boundary, not only a cost control. Treat every change to them as a security-relevant change, reviewed accordingly.

Related Modules

Session Agenda

Total: 170 min (2h 50min), including the 10-minute break

Optional runnable lab appendix: +45 min — delivered as a separate hands-on block, not included in the 170 minutes.

Welcome, Prerequisites, and the Fleet Cost Model (10 min)

Key Points

• A fleet is any set of unattended, programmatic Copilot invocations. The defining property is not scale — it is that no human reviews the cost of each call before it happens.
• Interactive users self-correct: they notice a bad answer, stop, and rephrase. A scheduler does not. Every configuration mistake in a fleet is charged once per invocation, forever, until someone measures it.
• The unit of analysis for the whole module is the lane: a named class of work with one invocation profile. "Nightly dependency audit" is a lane. "Fix failing test in service X" is a lane. A fleet is a set of lanes.
• Cost optimization chooses among options that already clear the quality bar. It never lowers the bar. If a cheaper profile produces work humans must redo, it is more expensive — Module 3's full cost per durable accepted outcome is the arbiter.
• The largest savings in practice come from two places, and neither is "shorter prompts":
  1. Not paying for things the agent never uses — inherited instructions, tool schemas, MCP servers, and injected context that no task in the lane can act on.
  2. Not paying twice — duplicate workers, unnecessary retries, cache misses on identical inputs, and paid results that are thrown away.

The Fleet Cost Identity

Use this as the mental model for every later section:

Fleet cost per window
  = Σ over lanes of [ invocations
                      × (session tax + task work + fan-out + retries)
                      × (1 − avoided-call rate) ]
  + human correction cost

Value per window
  = durable accepted outcomes × value per outcome

Decision metric (Module 3)
  = full cost per durable accepted outcome

Lane Lifecycle

Every section of this module maps to one stage of this lifecycle:

                    ┌──────────────────── Governance envelope (§5) ────────────────────┐
                    │                                                                  │
  ┌──────────┐   ┌──┴───────────────┐   ┌──────────────────┐   ┌──────────────┐   ┌────┴──────────┐
  │  Queue   │──►│ Pre-spend gates  │──►│ Lane profile     │──►│  Paid call   │──►│ Verify + land │
  │ (work    │   │ (§4)             │   │ (§2) in isolation│   │ (bounded by  │   │ (§6)          │
  │  items)  │   │ probe · dedupe   │   │ (§3)             │   │  credit cap) │   │ atomic · ack  │
  └──────────┘   │ cache · ledger   │   └──────────────────┘   └──────────────┘   └────┬──────────┘
                 └──────────────────┘             ▲                                    │
                          │                       │                                    ▼
                          │ skip (free)           └────── measured session tax (§1) ── Telemetry
                          ▼                                                            ledger (§6)
                    Recorded outcome

Discussion Points

• Which of your automated Copilot invocations could run today without a human noticing the cost for a full week?
• If your fleet doubled tomorrow, which cost line would grow fastest — session tax, retries, or duplicated work?
• Who currently approves a change to an automated lane's model, tools, or permissions, and is that the same reviewer who approves production code?

1. Measure the Fixed Session Tax (20 min)

Key Points

• The session tax is the fixed cost every invocation pays before the task-specific work begins: system prompt, custom instructions, tool definitions, MCP tool schemas, and anything else injected at session start.
• One-shot runs cannot amortize conversation context across turns. An interactive user spreads the session tax over many turns in one session; a one-shot worker pays the full session-start cost for a single turn of work. Whether any provider-side cache reuse survives between separate runs is not something GitHub documents — do not assume either a cold start or a warm one; measure your own lane.
• Copilot CLI exposes the composition of a session's context window through the /context command, which reports token usage and context-window percentage for System Prompt, Custom Instructions, System Tools, MCP Tools, Messages, Free Space, and Buffer (Managing context in GitHub Copilot CLI). Those categories are your session-tax line items.
• copilot plugins list non-interactively inventories every plugin, MCP server, skill, instruction source, and language server discovered for the current working directory, grouped by kind and configuration scope, with --kind, --scope, and --json filters. It is an inventory command, not a model call. Custom agents and session-scoped hooks are not covered by it and require a live session (GitHub Copilot CLI command reference).
• GitHub does not publish a per-instruction-file, per-tool, or per-MCP-server token overhead. Any specific number is environment-specific. Measure yours; never quote someone else's.

Session-Tax Contributors and Their Instruments

Note: Prompt mode (-p) is deliberately conservative by default: memory is off unless --enable-memory is passed, and tools do not run automatically without an explicit permission grant (--allow-all-tools, also settable through COPILOT_ALLOW_ALL). Additional prompt-mode trust toggles have existed under version-specific environment variables; CLI v1.0.79 does not list any of them in copilot help environment, so do not teach them as stable controls. Confirm what your harness sets, and re-read copilot help environment for your installed version before assuming a clean baseline.

Designing a Baseline Experiment

A defensible baseline changes one factor at a time and reports a distribution, not a single run.

Important: A trivial probe measures the session tax. It does not tell you whether a reduced profile still solves real tasks. Never adopt a cheaper profile on probe evidence alone — Section 6's canary gate exists for exactly this reason.

What Is Measurable Today, and What Must Be Verified

Exercise Connection

Lab 1 — Session-Tax Inventory and Baseline Design (10 min): participants inventory the contributors in a supplied lane description, mark each as required/optional/unknown, and write a one-factor-at-a-time baseline experiment. No paid calls.

Facilitation — no live demo required: this section teaches instruments, not a demonstration. If you choose to show copilot plugins list live and it fails (no CLI, no network, unexpected output), stop after one attempt and switch to the illustrative sample output in the lab's Backup Path section. Do not troubleshoot the CLI in front of the room — the teaching point is what the categories mean, and the sample carries it.

Discussion Points

• Do you currently know what fraction of a typical automated invocation is session tax versus task work? If not, what would it cost you to find out?
• Which instruction files, MCP servers, or skills in your automation exist for humans rather than for the agent?
• What would convince your team that a reduced profile is safe — a token delta, a credit delta, or a quality comparison on real tasks?

2. Lane Profiles for Model, Context, Tools, MCP, and Permissions (30 min)

Key Points

• A lane profile is the explicit, version-controlled configuration for one class of programmatic work. Nothing in a fleet should inherit "whatever the CLI defaults to" — defaults change, and an inherited default is an unreviewed decision.
• Copilot CLI separates tool visibility from tool permission, and the distinction matters for both cost and security (Allowing and denying tool use in GitHub Copilot CLI):
  • --available-tools and --excluded-tools control which tools the model is aware of and can choose from. A tool that is not visible cannot be used at all, even if it is also allowed. These options take tool names as your installed CLI and agent configuration name them; GitHub's reference does not publish a stable enumeration, so discover the names in your own environment before pinning them in a profile.
  • --allow-tool and --deny-tool control permission — whether a tool runs without prompting. Deny rules always take precedence over allow rules, even when --allow-all is set or an approval was previously saved. The CLI's own documented examples use identifiers such as write, shell, shell(git:*), shell(git push), and SERVER(tool).
  • If --available-tools and --excluded-tools are used together, the CLI applies the allowlist and ignores the denylist.
  • Visibility is a token and scope-creep control; permission is the security boundary. Enforce a read-only lane with denials first, then narrow visibility once you have verified the tool names your version uses.
• Command-line --allow-tool and --deny-tool apply only to the current session and are not written to the persisted permissions-config.json. Saved approvals from interactive use can otherwise leak into automation running as the same identity — an audit item for every fleet.
• Model selection is a routing decision, not a habit. GitHub's guidance is to match capability to work: reasoning models for architecture and complex debugging, mid-tier models when the plan is already clear, lighter models for routine well-scoped changes; auto model selection is recommended as the default and carries a documented 10% discount on model costs for paid plans, and it changes models only at cache boundaries (Optimizing your AI usage).
• Escalate model capability on a measured signal recorded in code (for example, "escalate only when the deterministic check still fails after the first attempt"), never by default and never by operator habit.
• Configuration churn is expensive: changing reasoning effort, context size, or the set of enabled tools and MCP servers during a session invalidates the cache. Fleet lanes should decide everything before the session starts and change nothing during it.

Model Routing and Measured Escalation

Route before you tune. In a fleet, the model decision is made once per lane and applied thousands of times, so it deserves a written rule rather than a preference.

An escalation rule is only a cost control when it is measured and recorded in code:

Note: A lane whose escalation rate climbs over time is telling you the cheap arm no longer clears the quality bar. That is a routing decision to remake with data, not a rule to loosen quietly.

Lane Profile Fields

Every lane profile in your fleet should be a reviewed file with these fields:

Three Reference Lanes

Use these as the starting shapes in the lab. The values are design defaults to argue about, not recommendations to copy blindly.

Read-Only Means Enforced, Not Requested

A read-only rule written in prompt text is a request. A read-only rule enforced by the harness is a guarantee. Enforce it with permission first, because deny rules use identifiers the CLI itself documents and deny always wins:

# Read-only audit lane: mutation denied, no clarifying questions,
# machine-readable output, bounded credits, transcript captured for review.
copilot -p "$PROMPT" \
  --no-ask-user \
  --model "$LANE_MODEL" --effort low \
  --deny-tool 'write' --deny-tool 'shell' \
  --disable-builtin-mcps \
  --max-ai-credits "$LANE_CREDIT_CAP" \
  --output-format=json \
  --share "$RUN_DIR/transcript.md"

Narrowing visibility is the second, token-saving step, and it is version-specific:

# Add visibility restriction only after verifying the tool names your
# installed CLI uses — substitute the names you observed, do not copy a list.
  --available-tools '<TOOL-NAME>,<TOOL-NAME>'

Important: Verify option spellings and values for your installed CLI version with copilot help before shipping a profile. An unknown option is rejected: CLI v1.0.79 exits non-zero with error: unknown option '--deny-toool' and makes no model call, so a misspelled flag fails loudly. The real fail-open risk is a valid flag carrying a wrong or unverified value — a tool name, pattern, or MCP server name that matches nothing still parses, and the lane runs without the restriction you believed you applied. Verify restrictions by observing behavior, not by reading your own command line.

Disabling Context Is a Trade, Not a Win

The only honest way to decide is to compare cost per durable accepted outcome on representative tasks, with a quality-parity gate. That is Section 6.

Exercise Connection

Lab 2 — Design Three Lane Profiles (15 min): teams complete the lane-profile worksheet for the three reference lanes, then justify each reduction with the evidence they would need before adopting it. No paid calls.

Facilitation — compression cue (30-minute section): if you enter this section more than five minutes behind, present the lane profile field tables as a read-out instead of a walkthrough and reduce Model Routing and Measured Escalation to the auto discount sentence plus the escalation trigger. Protect Visibility vs. Permission, Read-Only Means Enforced, and the full 15 minutes of Lab 2 — the worksheet is the artifact participants keep.

Discussion Points

• Which of your automated invocations currently run with broader tool permissions than the task requires, and what would break if you narrowed them tomorrow?
• Where would an escalation rule ("try cheap, escalate on failure") beat always using a capable model — and where would it cost more?
• Who reviews lane profile changes today? Should a permission change require the same review as a production deployment?

3. Isolation, Worktrees, and Concurrent Ownership (20 min)

Key Points

• The working directory is a configuration input. Copilot CLI discovers instruction sources, MCP servers, skills, and language servers relative to the current working directory and configuration scope. Moving a worker changes what it inherits — in both directions.
• A worker started inside a directory tree that carries large human-oriented instruction files inherits them on every invocation. A worker moved out of that tree may silently lose the MCP servers or instructions it actually needed. Both are configuration bugs; both are found the same way — run copilot plugins list from the exact working directory the harness uses, not from your shell's default directory.
• Resolve configuration paths relative to the harness's own location rather than hardcoding absolute paths, and commit configuration files in the same change as the code that references them. A clone or worktree copy must keep working without edits.
• Copilot CLI provides documented isolation controls with distinct maturity levels:

Important: --worktree and --sandbox are documented as experimental. Do not build a fleet whose safety depends on an experimental flag without a non-experimental fallback and an explicit re-verification date. Sensible fallbacks are generic engineering practice, not Copilot features: a per-worker clone plus filesystem permissions in place of --worktree, and running the worker inside your existing container or VM isolation in place of --sandbox. Neither is a documented Copilot control, and neither inherits Copilot's tool-permission model — you still need --deny-tool rules.

Important — worktree conflicts: worktrees are shared Git state, not private sandboxes. Two workers that reuse the same worktree name collide; a worktree left behind by a killed run keeps its lock and its branch checkout, so the next run either reuses dirty state or fails to create the worktree; and --worktree conflicts with --resume, --continue, and --connect. Every lane that creates worktrees needs a unique name per run, a cleanup step, and a stray-worktree recovery procedure (git worktree list, git worktree remove, git worktree prune).

• Per-lane configuration isolation — giving each lane its own COPILOT_HOME so that saved permissions, settings, and state do not leak between lanes or from interactive use — is a harness pattern built on a documented environment variable, not a documented fleet feature. Teach it as a pattern, verify it in your environment, and record the verification.
• Session transcripts and gists can carry sensitive content. --share-gist publishes to GitHub.com and is not available to Enterprise Managed Users or GitHub Enterprise Cloud with data residency (*.ghe.com). Prefer --share=PATH into a controlled location with a retention rule.

Concurrent Ownership

Two watchers whose scopes overlap will race to fix the same target, and you will pay twice for one outcome — sometimes with conflicting results.

Note: Isolation without cleanup becomes its own problem. Every worktree, clone, temporary directory, and transcript needs an owner and a deletion rule — decided when the lane is designed, not after disk fills. Include stray-worktree recovery in the runbook: list them (git worktree list), remove the abandoned one (git worktree remove <path>, adding --force only for a worker you know is dead), then git worktree prune.

Exercise Connection

Lab 3 — Two-Watcher Fleet Review (10 min): participants review a supplied two-watcher fleet description, identify the overlap and inheritance defects, and specify the fingerprint, lease, and cleanup rules that fix them. No paid calls.

Discussion Points

• Could two of your automations act on the same target today? How would you find out — and would the duplicate spend be visible in your reporting?
• What in your automation would break first if a worker ran from a different directory than expected?
• Which experimental controls would you be comfortable depending on, and what fallback would you require before doing so?

☕ Break (10 min)

Use the break to note which lane in your own environment is the best canary candidate for Section 6.

4. Pre-Spend Gates, Cache Correctness, and Prompt Budgets (30 min)

Facilitation — post-break reset (60 seconds, inside this section's 30 minutes; the agenda is unchanged): before the first slide, invite the room to stand if they are able, roll the shoulders twice, look at something roughly 20 feet away for 20 seconds, and sit back down. State that participation is optional. Then give the section's one-sentence promise — "the cheapest call is the one you never make" — and start. The section budget is roughly 1 minute reset, 14 minutes of content, and 15 minutes for Lab 4.

Key Points

• The cheapest call is the one you never make. Every paid invocation should sit behind a ladder of deterministic checks that can answer "this work is unnecessary" for free.
• A gate that is only usually right is worse than no gate: a wrong "already done" verdict silently drops real work. Gates must be conservative — when uncertain, spend.
• Cache correctness is a data-integrity problem, not an optimization. A cache key that omits an input that can change the answer will confidently serve a wrong verdict, and the failure is invisible in cost reporting because it looks like a saving.
• Bound every prompt field that can grow. Unbounded diffs, log tails, accumulated notes, and generated file contents are the most common cause of oversized, expensive, low-quality calls.
• Copilot CLI already bounds one growth source for you: tool output larger than 20 KiB is saved to a temporary file by default, and the model receives the file path and a preview instead of the full output (Managing context in GitHub Copilot CLI). The documentation names an environment variable for that threshold, but CLI v1.0.79 does not list it in copilot help environment — treat the variable as version-sensitive (claim ledger) and bound large inputs in your harness, where the cap is yours to test.

The Pre-Spend Gate Ladder

Evaluate in this order; stop at the first gate that resolves the item.

Note: Gate 7 is a pre-spend decision and produces budget_refused. A cap that is reached during a run — most commonly the per-run --max-ai-credits soft limit — is a different outcome, run_cap_exhausted, because credits were already spent. Section 5 separates the two.

Important: Gates 3 and 4 are the highest-value gates in most fleets and the easiest to get wrong. "The file exists" is not the same as "the correct current artifact exists," and "the test passed" is not the same as "the test ran."

Complete Cache Keys

A result cache is safe only when the key covers everything that could change the verdict.

Cache hygiene rules that belong in the same design:

• Missing key component in an old entry = cache miss. Never guess.
• Record provenance with every stored result: key components, timestamp, run ID, and whether it was later accepted.
• Decide the negative-result policy explicitly. Caching failures can be correct (deterministic refusal) or dangerous (transient outage). Default to not caching transient failures.
• Provide a documented bypass implemented in your harness (for example, a --no-cache flag on your own runner — not a Copilot CLI option) and log every bypass so a permanent bypass cannot hide.
• Set a TTL based on how quickly the underlying inputs go stale, and invalidate on profile change.

Prompt Budgets and Bounded Fields

Note: Whether a specific prompt layout improves provider-side cache reuse is not something GitHub documents at the byte level. What is documented is that mid-session changes to model, reasoning, context size, or the enabled tool/MCP set invalidate the cache, and that cached input tokens are typically billed at a fraction of fresh input. Optimize for stability of configuration first; treat prompt-layout cache theories as hypotheses to measure.

Exercise Connection

Lab 4 — Unsafe Cache-Key Review (15 min): teams review an intentionally unsafe cache design, list the omissions, and describe the specific wrong result each omission can produce. No paid calls.

Facilitation — compression cue (30-minute section): if you are behind, deliver Complete Cache Keys as the two split slides without commentary, reduce Cache Hygiene to its three bold rules (miss on unknown, never cache transient failures, log every bypass), and cut the prompt-budget table to the two rows the room reacted to. Never shorten Lab 4 — it is the highest-value exercise in the module.

Discussion Points

• Which paid call in your current automation could be replaced by a deterministic check tomorrow?
• If your rubric or prompt template changed today, would any cached verdict in your system still be served? How would you know?
• What is your policy for caching failures — and does it distinguish a deterministic refusal from a service outage?

5. Runtime Governance for Budgets, Fan-Out, Retries, and Breakers (30 min)

Key Points

• Autonomous lanes need governance because a single bad day can erase a quarter of savings. Governance is layered: organization budgets bound the blast radius, the harness bounds the fleet, and per-run caps bound one invocation.
• A lane that bypasses the harness budget module is invisible spend. Every paid call goes through one check() before and one record() after — no exceptions, including ad-hoc scripts.
• Record honestly. If one logical task fans out into three model calls, record three. Undercounting hides exactly the lanes you most need to see.
• Copilot's own per-run cap is a soft limit and is in public preview. --max-ai-credits sets a soft maximum for AI credits; if a response is in progress when the limit is reached, that response completes, so actual usage may slightly exceed the configured number. In non-interactive mode, the run ends when the limit is reached. GitHub documents session limits as currently in public preview and subject to change, and notes they work best when set above 30 AI credits because most model calls cost more than 20 (Setting an AI credit session limit in GitHub Copilot CLI). CLI v1.0.79 also enforces a floor of 30: --max-ai-credits 10 is rejected with Use at least 30 AI credits. Pick a value above 30 — this module uses 40 — and treat a cap that stops a run as a signal to decompose the task, not a number to raise.
• Session limits do not replace user-level budgets or spending limits, which govern overall monthly consumption (Optimizing your AI usage). Module 1 owns that layer.

Layered Budget Controls

Important: The identity a fleet runs as consumes credits like any other user, and a user-level budget applied to that identity is a hard stop. Decide deliberately whether a hard stop on your automation identity is the outcome you want, and coordinate it with the Module 1 owner.

Outcome Taxonomy

The single most common dispatcher defect is treating every non-success as "the model failed." The second is treating "we declined to spend" and "we spent and ran out" as the same event.

Why budget_refused and run_cap_exhausted must be different outcomes:

Important: An automatic retry after run_cap_exhausted is the most expensive mistake in this taxonomy: each attempt pays close to the full cap and lands nothing. Retry must be gated on a change — smaller work item, different lane, or a reviewed cap decision — never on time alone.

Backoff, Breakers, and Parking

• Exponential backoff with jitter (for example, 10m → 20m → 40m, capped) recovers quickly when conditions change. A long fixed timeout is a throughput tax that outlives the incident that caused it.
• Park on refusal, do not poll. When a pre-spend budget check refuses, park the whole worker for a fixed window and log one summary line. Per-item refusal checks at poll cadence generate thousands of log events per day and hide real signal.
• Escalate, do not retry, on run_cap_exhausted. Record the spend, increment the attempt, and route the item to a human or a decomposition step. The item stays queued but blocked until someone changes the work or the cap.
• Trip breakers on consecutive model_failure only. Counting routing, policy, budget, or "already done" outcomes punishes the model for the dispatcher's mistakes and takes down healthy lanes.
• Half-open carefully. After the open window (a defensible default is 20 minutes), allow exactly one probe item; close on success, reopen for the next window on failure.
• Dead-letter with context. An item that exhausts its attempts must land in a dead-letter queue with the last outcome, the profile hash, and the transcript pointer — never be deleted.
• Refused work is delayed, not lost. The queue must still contain it after the park window.

Where Runtime Cost Data Comes From

Important: GitHub's billing views attribute usage to identities, models, organizations, and cost centers — not to your lane names. Lane-level attribution is your harness's responsibility: record the lane, profile hash, and run ID in your own ledger and reconcile totals against the dashboard. Do not promise lane-level chargeback from GitHub reporting alone without verifying the dimensions available to you.

Exercise Connection

Lab 5 — Dispatcher Outcome Taxonomy (15 min): teams map nine supplied run results — including a pre-spend budget refusal and a post-spend cap exhaustion — to outcomes, retry behavior, breaker counting, and queue action, then identify which mapping errors would cause a retry storm, silent work loss, or repeated partial spend. No paid calls.

Facilitation — compression cue (30-minute section): if you are behind, teach the layered budget table and the first half of the outcome taxonomy live, hand the second half to the lab worksheet, and cut the backoff bullets to three (backoff with jitter, breakers on model_failure only, refused work is delayed not lost). Keep the budget_refused versus run_cap_exhausted contrast — it is the new decision this section exists to teach — and keep Lab 5 at 15 minutes.

Discussion Points

• Does your automation today distinguish "the model failed" from "the service was unavailable" and "the work was already done"?
• What would your fleet do if a budget refused every call for two hours — and how many log lines would that generate?
• Which layer would catch a runaway lane first in your environment, and how long would it take?

6. Durable Landing, Telemetry, Canary Rollout, and Capstone (20 min)

Key Points

• The most expensive token is one spent on a result that gets thrown away. A fleet is only as efficient as its landing path.
• No silent success. A merge, write, or publish step that finds nothing to do must say so distinctly — a dedicated exit signal or a prominent warning — not exit successfully while the caller acknowledges and deletes the work item.
• Exit codes are a contract. Adding a new failure signal changes the behavior of every caller. Trace all callers before changing one, because a signal that is correct for one lane can quarantine every item in another.
• Never acknowledge on ambiguous success. Validate the output, write atomically (or verify the merge), record provenance, and only then acknowledge. If validation is inconclusive, retain the item.
• Fixes do not count until deployed. Long-running workers load code at start; committing a change without restarting the service means the old code is still spending. Commit, deploy, restart, then confirm the new behavior in live logs.
• Resolve shared paths through one helper. Two components with different ideas of "the current round" means paid work written where nobody reads it.

The Landing Contract

Fleet Telemetry: What Every Run Records

Those fields roll directly into the Module 3 metric: full cost per durable accepted outcome, per lane. Cost per invocation and tokens saved are diagnostics; they are not the decision metric.

Canary Rollout for Cost Changes

Treat a cost-optimization change exactly like a production code change.

Baseline ──► Canary one lane ──► Quality-parity gate ──► Adversarial review ──► Expand ──► Monitor
   │              │                      │                      │                 │         │
   │              │                      │                      │                 │         └─ rollback trigger stays armed
   │              │                      │                      │                 └─ one lane at a time
   │              │                      │                      └─ integration seams, cache keys, flag spelling and values, exit-code blast radius
   │              │                      └─ durable acceptance must not regress
   │              └─ same task mix, same window, single variable
   └─ measured, not remembered

Important: Report savings as measured cost per durable accepted outcome, not as assumed token reductions. A profile that saves tokens and loses acceptance is a cost increase wearing a savings label.

Exercise Connection

Lab 6 — Capstone: Fleet Lane Optimization Checklist and Canary Scorecard (12 min): teams complete the capstone templates for one anonymized real lane, naming the canary lane, the single variable, the quality-parity gate, the rollback trigger, and the owner. No paid calls.

Facilitation — pacing (20-minute section): this section carries a 12-minute lab, so the live budget is about 8 minutes — roughly 2 minutes on the landing contract, 2 on telemetry, 3 on canary rollout, and 1 for the hand-off. Deliver the tables as pointers, not readings. The claim ledger and the "Translating Playbooks" table are reference material in the deck appendix; do not teach them live unless the room asks.

Discussion Points

• Where in your pipeline could paid work land somewhere nobody reads, and how long would it take you to notice?
• Which lane is your best canary — highest volume, lowest blast radius, clearest acceptance signal?
• What is your rollback trigger, and who is allowed to pull it without a meeting?

Recap

• A fleet's cost is fixed session tax plus variable task work, multiplied by invocations and inflated by retries, fan-out, duplication, and discarded results.
• Measure the session tax before optimizing it: /context, /usage, copilot plugins list, and a one-factor-at-a-time baseline — never someone else's token numbers.
• A lane profile pins model, effort, context tier, tool visibility, tool permission, MCP set, instructions, memory, credit cap, isolation, and fan-out. Nothing inherits a default.
• Tool visibility and tool permission are different layers; deny always wins; permission changes are security changes.
• Isolation controls exist at several maturity levels — -C, --add-dir, and COPILOT_HOME are documented options; --worktree and --sandbox are experimental and need a fallback.
• Deterministic gates and complete cache keys avoid paid calls safely; an incomplete cache key is a correctness bug that looks like a saving.
• Governance is layered: organization budgets, fleet envelope, per-run soft credit cap (public preview, minimum 30 in CLI v1.0.79), harness fan-out caps, worker concurrency, and retry caps — with honest accounting at every level.
• A failure taxonomy prevents retry storms and breaker misfires; a pre-spend refusal parks the work, a post-spend run_cap_exhausted records the spend and blocks retry until the task or the cap changes; dead-lettered work keeps its context.
• Paid work counts only when it lands, is consumed, and is accepted — verified in live logs after deployment.
• Roll out cost changes like production changes: baseline, canary, quality parity, adversarial review, expand, and keep the rollback trigger armed.

Appendix

Package Artifacts

Important: The four templates are also inlined as printable copies in Appendix B of the lab guide, because the published site renders the lab page but does not publish the templates/ folder. Participants reading the published lab therefore need no repository access. The templates/ files remain the editable sources — change both copies in the same edit and keep them identical in content.

Key URLs

Copilot CLI Control Reference (documentation verified 2026-08-12; help output cross-checked against CLI v1.0.79)

Claim Ledger: Verify Before Delivery

These items are not settled facts and must be presented as measurement questions, not product guarantees.

Translating Playbooks From Other Agent CLIs

Teams often arrive with a playbook written for a different agent CLI. The principles usually transfer; the commands usually do not.

Important: Never present a flag from another vendor's CLI as a GitHub Copilot flag. If a control does not exist in the current Copilot documentation, say so, and implement the principle in your harness instead.

Instructor Preflight Checklist

• Re-verify every row of the Copilot CLI Control Reference against the live command reference; update the verification date in the guide, lab, and deck together
• Confirm the current status of --max-ai-credits (public preview), --worktree, and --sandbox (experimental) and say the status out loud when the slide appears
• Confirm the audience actually operates programmatic Copilot automation; if not, deliver Module 2 or Module 3 instead
• Decide before the session whether the optional runnable appendix will be delivered, and confirm participants have a non-production sandbox and authorization to spend
• Print or share the four templates for participants without laptops — printable copies are inlined in Appendix B of the lab guide, and the editable sources are in templates/
• Prepare one anonymized real lane from your own environment as a worked example; remove customer names, repository names, and internal figures
• Confirm the Module 1 budget owner is identified for the layered-governance discussion
• Re-run copilot help, copilot help environment, and copilot help limits on the delivery machine and note any drift from the control reference

Backup Plan

If any live element is unavailable (no CLI, no license, restricted network, or a UI change):

1. Deliver all six core exercises from the lab worksheets — none of them requires a live product.
2. Replace any live inventory demonstration with the illustrative sample copilot plugins list output in the lab's Backup Path section (Lab 1 and Lab 3 both reference it). Say out loud that the sample is synthetic and that real output differs by machine.
3. Screen-share the linked documentation pages instead of the product when a flag's behavior is questioned.
4. Skip the optional appendix entirely; it is not required for any learning objective.
5. If a documented flag has changed since verification, say so explicitly and record it as a follow-up rather than improvising a replacement.

Workshop guide for GitHub Copilot AI Credits Optimization — Optional Module 4: Agent Fleet Efficiency and Cost Governance (optional; excluded from the 7-hour-10-minute core curriculum of Modules 1–3)