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
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.
Top comments (0)