Model availability depends on where the request came from. Some providers restrict access by geography, and when a model is unavailable in your location it does not return an error, it simply disappears from the list; the remaining options keep working. That yields a property which is awkward for planning: the set of models is not a property of the plan but a function of two variables, the first being what is enabled in the account and the second being the place a person works from. Geography turns into an entry question of adoption rather than a detail sorted out along the way.
The naive view here is entirely natural. The subscription looks the same for everyone, the interface is the same, team settings are shared, the documentation is shared. Everything else in the tool really is independent of place: rules, the project index and the agent's modes behave identically in any country. It is logical to expect the same of the model list, all the more so because that list looks like part of the product rather than a reflection of someone else's access policy.
The expectation breaks at the moment the disappearance turns out to be silent. A missing row in the list does not look like an incident: nobody gets a message, nothing fails, work continues on what remains. Two people on one team in different countries see different lists and get different results on the same task, and the conversation about it starts with mutual accusations of sloppiness rather than with a check of geography. The binding can be tighter than a set of models: some plans are available in one country only, are confirmed by verifying a phone number of that country, and attempts to connect from outside or through a VPN may be blocked. So geography is verified, not inferred from good intentions.
The mechanism for working around unavailability consists of three routes, and all three stay inside the same restriction. The first is automatic selection, which picks an available model for each request and therefore does not trip over a disappearance. The second is a manual choice among the remaining enabled models, when predictability matters rather than the mere presence of an answer. The third is your own provider key, added in the model settings. The reason none of the routes widens geography is simple: the restriction lives at the provider rather than in the editor, and each provider maintains its own regional coverage and documents it on its own side.
Betting on your own key is the most common misconception on this topic, and it is worth unpacking. The key answers the question of which contract the call runs under and at whose expense; it does not answer the question of where the call came from. The condition is stated plainly: your own key makes sense if the provider serves your region. And even with it, calls may still fail if the provider blocks the region. Your own key changes the payment route and sometimes the limits, but it does not move the workstation into another jurisdiction.
Different settings close different parts of the task, and confusing them wastes the most time. It helps to lay out once what each of them solves and what it does not. Below is that map: automatic selection saves you from a disappearance but also hides it; a manual choice gives predictability inside the permitted set; your own key connects the provider directly but does not lift its regional block; phone number verification confirms the country for plans tied to a country; a model available everywhere the product operates removes the dependence of choice on place but says nothing about where processing happens; enterprise data residency keeps processing in country for supported features only.
Data residency answers a different question, and mixing it with availability is unnecessary. Availability says which model will answer; residency says where inference, processing and storage happen. At the enterprise level this is a separate enrollment procedure, done per team: today US-only residency is what gets enabled, while European Union and Iceland coverage is available on request and for inference only; the full set - inference, processing and storage for supported features - is kept in region only in the US variant. The procedure has a monetary side too: model rates carry a surcharge and the set of available families narrows. The load-bearing word here is supported. The boundary runs along a list of features rather than around the whole product, and that list together with its exclusions is described in the privacy and data governance documentation rather than picked by a switch in team settings.
| What is configured | What it solves | What it does not solve |
|---|---|---|
| Automatic model selection | Picks an available model for each request | Does not bring back an unavailable model and hides the disappearance |
| Manual choice among the remaining models | Gives predictability inside the permitted set | Does not widen the set beyond what the region allows |
| Your own provider key | Connects the provider directly if it serves the region | Does not lift the regional block on the provider's side |
| Country phone number verification | Confirms the country for plans tied to a country | Is not bypassed by a VPN or a connection from outside |
| A model available in every region the product operates in | Removes the dependence of choice on location | Does not govern where processing and storage happen |
| Enterprise data residency | Keeps inference, processing and storage for supported features in country | Does not extend to anything outside the supported list |
The price of these two things differs. Geographic binding costs you the ceiling of the result: part of the models is unavailable, and the ceiling is set by what remains. Some models work everywhere the product operates, including the European Union, and remove part of the selection problem, but they say nothing about the place of processing. Residency costs a procedure: the enterprise level, a separate enrollment and a narrower feature surface, because outside the supported list the guarantee does not hold. It is justified when the requirement is external - a regulator, a customer contract, an internal data policy. Nobody pays that price for a feeling of safety.
The result is verified differently from how it was configured. The model list is inspected from the actual location rather than from behind a VPN, and compared across several people in different countries: a divergence in lists explains a divergence in results faster than any log analysis. After automatic selection is turned on, look at which model actually answered rather than which one was intended. Your own key is verified by one production call rather than by the fact that the key was saved: saving always succeeds, the refusal comes from the provider. Residency is verified feature by feature, marking what is inside the boundary and what is outside it.
The typical failures repeat from team to team. Treating the model list as a property of the plan and planning work around a model the region does not have. Explaining the difference in results between two developers by skill rather than by geography. Buying your own provider key as a means of bypassing a regional block. Working around a plan's country binding through a VPN and being surprised by the block. Taking model availability for data residency. And assuming residency covers the whole product without checking the list of supported features and exclusions.