Five days ago, GitHub set Copilot’s enterprise base model to GPT-5.3-Codex without consulting the developer. I wrote about it as you didn’t pick this model. The argument was that the model picker had moved up to the enterprise admin and the developer no longer chose what was running. Today, May 27, I want to revise that claim. The picker did not stay at the enterprise tier. It moved one notch back down — but to the organization, not to the developer. The GitHub blog dated May 26 introduces per-organization targeted model rules, and the right read is that the picker is now an org-level decision sitting between the enterprise default and the developer who runs the model.
What the rules grant and what they don’t
Per the blog: “Enterprise owners now have granular control over which GitHub Copilot models are available to each organization. With targeted model rules, you can allow specific models for specific organizations instead of relying on a single enterprise-wide setting.” The control is real. A security organization can deny a model that the finance organization permits. An engineering organization can opt into a model the rest of the enterprise has not. The single-policy floor I wrote about a week ago has become a multi-policy surface, organized by org chart. That is improvement.
The control is also real at a specific tier. The enterprise admin still picks the catalog. The organization picks within it. The developer — the person who writes the line that calls the model — still gets whatever the organization gave them. Three tiers now where there used to be two, and the developer is still at the bottom of the stack, choosing among options pre-selected for them.
The Enabled default is the part to read carefully
The piece of the blog I want to point at is the per-model setting itself. “Enabled (automatically on for all organizations) or Optional (organizations decide whether to enable it).” An Enabled model is on by default for every organization under the enterprise. The new control surface — per-organization rules — is opt-out for Enabled models and opt-in for Optional ones. The pre-selected default did not go away. It got more places to live. Every model the enterprise admin set to Enabled is automatically on for the finance org, the security org, the engineering org, every org you did not audit yet.
I want to be specific about what this means for the developer’s experience. If your enterprise admin set GPT-5.3-Codex to Enabled five days ago and your security organization did not write a per-org rule yet, you are running GPT-5.3-Codex today. If your enterprise admin set a Sonnet variant to Optional, your organization needs to opt in before you can use it. The defaults flow down through the org-chart structure the same way they would flow down through a single-policy structure. The granularity moved; the default-direction did not.
A trajectory we have seen before
The arc-closer post earlier this month, parallel agents and the per-developer meter, traced an analogous decomposition on the cost-and-budget surface — from one bill across an organization to one bill per developer. The targeted model rules are the same kind of decomposition on the policy surface — from one policy across an enterprise to one policy per organization. The trajectory is consistent: the bundle gets unbundled, one tier at a time, every time the previous tier’s grain stops being precise enough to act on. I do not expect this to be the last tier. The next one will probably be per-team rules within an organization, or per-repository overrides — the model-picker decision-tree growing more leaves, none of which terminate at the developer.
The memory layer in the same release
The May 26 changelog window also added CLI controls to Copilot Memory, with the load-bearing change being that the store_memory permission prompt now explicitly states whether the entry will be a user-level preference or a repository-level fact. The mapping is direct: memory now has two tiers — user-level vs repository-level — and the prompt makes the choice explicit at capture time. The same shape as the model picker. The same direction of evolution. A bundle that used to be one decision is becoming a decision tree, and each new node in the tree is a tier the developer does not own.
The steelman, which is real
Targeted model rules are real organizational autonomy. A finance organization does not need to ask the enterprise admin to enable a model the finance team needs for a specific compliance workflow. A security organization can deny a model the engineering team would otherwise be running, and the denial is a single rule rather than a renegotiation of the enterprise floor. The org-tier rules let organizations move independently of each other, and that independence is genuinely valuable for organizations with mixed risk profiles. The improvement is for the organization. The improvement is not for the developer who runs the model.
Where the model picker actually lives
What the targeted model rules clarify, in retrospect, is that the model-picker question — “who picks this?” — was always a tree, not a knob. The original framing in you didn’t pick this model treated it as a knob that had moved up. The right framing is that the knob was always going to grow into a tree, and the question is which leaves of the tree the developer ever gets to touch. The answer this week is: the developer touches the leaves that the organization has opted into and the enterprise has set Enabled. Three picks happened before the developer got to one, and two of those three are defaults.
The line that matters
Adding a tier to a stack of tiers is not the same as putting the choice back in the developer’s hands. The promise was control. What the week delivered was more places where someone else’s pre-selected default lives. What I changed: I stopped framing model-picker decisions as “developer vs enterprise.” There is an org tier now, the answer to “who picked your model” has at least three possible names, and the developer is none of them. The next piece in this arc traces how the parallelism story moves one tier down, in your MCP tools are running in parallel now. The release that triggered this piece is Copilot adds per-organization targeted model rules.
