GitHub flipped Claude Haiku 5.5 to general availability in Copilot on October 7, and the Copilot CLI picked it up the next day in version 1.0.94. The changelog entry is short and reads like routine model plumbing: a lightweight model for "fast, high-volume work like subagents, quick edits, and terminal tasks," with early testing that says it "matched Claude Sonnet 5 on many coding tasks while using significantly fewer tokens and steps." For anyone running Copilot as a daily agent, a new model in the picker is not a no-op. Four separate config surfaces now decide whether Haiku 5.5 runs your work, and only one of them did you or your team explicitly choose. I traced all four this week, mostly to answer one narrow question: when a subagent fires, whose model choice is that?
What actually shipped, on which day
Two releases, two days. On October 7 the GitHub changelog announced GA for Copilot Pro, Pro+, Max, Business, and Enterprise, billable "at provider list pricing under usage-based billing." The model appears in eleven surfaces: VS Code, Visual Studio, Copilot CLI, the cloud agent, the Copilot app, github.com, GitHub Mobile on iOS and Android, JetBrains IDEs, Xcode, and Eclipse. The rollout is gradual, so absence in your picker today proves nothing about tomorrow. On October 8, Copilot CLI 1.0.94 added Haiku 5.5 to model selection and to --model completions, which is the part that matters for scripted and CI usage, where nobody is looking at a picker.
The default you inherited
The first config surface is the one nobody on your team chose. Copilot Business and Enterprise administrators manage model access through the model policy in Copilot settings, and the changelog states the default plainly: "Under default model enablement, new models are automatically enabled unless an administrator has turned off the global default or explicitly disables this model." Read that again from the org side. GA day is the day the model enters your company, not the day someone approves it. If your security review process has a queue, and every queue does, Haiku 5.5 joined production ahead of it. That is defensible as a product decision, GitHub cannot very well ship models opt-out-dark for every customer, but it converts "which model ran that refactor" from a question with an owner into a question with a timestamp.
The recommended list and the Auto tier
The second surface is the picker's recommended list. CLI 1.0.93, also October 7, says: "Model picker updates the recommended list to prioritize GPT-6.1 Sol, GPT-6 Astra/Luna, and Claude 5.5 models." A recommended list is a default with better marketing. If you pick a model manually every session, it does not touch you. If you ride the Auto routing tier, the tier decides, and 1.0.90 (September 30) added "user and managed startup defaults for the Auto routing tier, including strict and user-overridable organization policy." So the model that runs your next turn can trace back to an org policy you have never opened, layered under a recommendation list a vendor reordered this week. None of that is malicious. All of it is invisible unless you look.
settings.json is the only user config that counts now
The third surface is local, and it just moved. CLI 1.0.93 also shipped: "Read user settings only from ~/.copilot/settings.json; user-setting keys in ~/.copilot/config.json are ignored." If your team setup docs still point at config.json, those keys are quietly dead and have been for two days. The same file holds the subagent recursion budget, subagents.maxDepth, whose default dropped from 6 to 4 in CLI 1.0.71 back on July 16, "to curb runaway recursive sub-agent delegation," with usage-based billing users still able to raise it up to 128. If you never touched it, your delegation depth changed under you three months ago. 1.0.92 (October 5) added copilot config subcommands to list, read, set, and remove settings, so auditing no longer requires an editor:
# what the CLI actually honors today copilot config list # the recursion budget, post-1.0.71 default grep -n "maxDepth" ~/.copilot/settings.json # dead keys living in the ignored file grep -n "model\|subagent" ~/.copilot/config.json { "subagents": { "maxDepth": 4 } } Custom agents and the critic
The fourth surface is per-agent model bindings. Custom agent entries carry their own model choice, and 1.0.92 changed how settings follow it: "Custom agent model entries keep model-bound reasoning effort only when that model is selected." Swap the model, and the effort tuning you dialed in does not come along. The rubber-duck critic goes further and picks "a complementary model strategy that picks an opposite-family model" (in the CLI since 1.0.64, June 23), so the critique of your Claude session can run on a GPT model and the other way around. Neither binding lives in your repository the way a rules file does. If you run multiple agents in parallel, the state files that keep them sane are repo material, but the model each one runs is config scattered across three layers we just walked through.
"Matched Sonnet 5" is a harness claim
The performance sentence deserves skepticism on principle, and GitHub would probably agree. "In early testing" is a harness result, and harness results are exactly what Hugging Face punctured when the same model scored 33% or 62% depending on the harness configuration. The claim I would take to the bank is the shape of it, not the score: fewer tokens and fewer steps is the right economics for subagent work, because subagents are volume work billed at provider list pricing under usage-based billing. A cheaper model that needs two extra rounds to finish can cost more than a pricier one that lands in one. Run your own pass on your own repo before flipping any default. If you want a pre-built verification workflow for exactly this kind of claim-checking, we sell Verify First for that.
A 10-minute audit
Do this once and write down the answers. One, copilot config list, and confirm nothing you care about still lives in config.json. Two, open the org model policy page if you have admin access, or ask whoever does, and record whether default model enablement is on. Three, run /subagents in a session and check which agents report a model binding and which inherit. Four, check what the Auto tier resolves to for you, since 1.0.93 reordered its recommendations this week. Five, note which of the eleven surfaces your team actually uses, because a model selected in VS Code says nothing about what Copilot CLI uses in CI, the selection is per surface.
Pin what you can, because the list drifts
The picker is not a stable place to store an intention. 1.0.92 also "removed retired models from the model picker and supported CLI selections," which means an unpinned default drifts every time a vendor rebalances a list, and 1.0.93 just proved that rebalancing happens on any random Tuesday. What survives is what you wrote down: a named model in a custom agent entry, a maxDepth you set yourself, an org policy with a decision behind it, and instructions files that name their assumptions. This is the same argument as version-pinning your agent rules and configs, which is the whole thesis behind AgentConfig Studio ($29) and its free Next.js sample if you want to see the shape first. The model layer will keep moving. Your config layer is the part that can hold still, but only if you pin it on purpose.
