When should an organisation standardise on GitHub Models, and when must a workload move off it?

## Two decisions, not one "Do we use GitHub Models?" is really two questions with different answers: *as an evaluation and prototyping layer*, and *as a runtime for a product*. Conflating them produces both failure modes — banning a genuinely useful sandbox, or discovering on launch day that a shared prototyping quota is your production capacity. ## Where it earns its place - **Model selection.** Comparing four candidate models normally means four vendor accounts, four procurement conversations and four sets of keys. Here it is one credential and a change of model identifier, which collapses the cost of an experiment to nearly zero. Cheap experiments mean more of them, and better-evidenced choices. - **Prompt evaluation in review.** Prompts stored as files and scored in CI turn prompt engineering from folklore into something with a diff and a signal. - **Onboarding and internal tooling.** New engineers reach a working model call without a procurement ticket; low-volume internal tools never need one at all. - **Negotiating position.** Real evaluation results across vendors are the strongest input you can bring to a commercial conversation. ## Where it stops being appropriate - **Capacity you cannot allocate.** The allowance belongs to the account, not the service. You cannot give the payments team a quota and the search team another; a load test can starve a demo. Any workload whose availability matters needs capacity attributable to it. - **No production capacity commitment.** Prototyping surfaces do not carry the guarantees a customer-facing dependency needs. Paid usage raises ceilings but does not turn a developer-experience product into a contracted runtime. - **Data-handling and regional requirements.** Regulated workloads typically need stated processing terms, regional placement and contractual commitments. Confirm what applies before routing regulated data anywhere — and if the requirements are specific, that alone points to a provider or cloud endpoint chosen for them. - **Catalog churn.** Models are added and retired on the platform's schedule, not yours. A product pinned to one model needs a supplier relationship where lifecycle is communicated and versions are pinnable. ## Making the exit cheap The migration is only easy if you engineer for it from the first commit: - **Three values in configuration**: base URL, credential, model identifier. Never inline. Note the model id genuinely differs — the catalog qualifies identifiers by publisher while a vendor's own API uses the bare name — so the config must be able to express both forms. - **One client wrapper.** Application code should call your own interface, not an SDK directly, so a provider change touches one module. - **Evaluation as a portability test.** Keep the prompt evaluation suite green across endpoints. Re-run it after any move, since the same model family served from different endpoints can differ in defaults and supported parameters. - **Reject vendor-specific extensions in shared code.** Anything outside the common chat-completions surface becomes migration debt. ## Governing it - **Enablement.** Organisation and enterprise administrators control whether members can use GitHub Models at all. That is a deliberate policy decision — including whether to allow it in some organisations and not others. - **Load etiquette on shared quota.** Publish who may run load tests and large evaluation matrices, and keep routine CI evaluation on small models so it does not compete with people. - **Written exit criteria.** State the thresholds — sustained requests per minute, user-facing latency budget, data classification, need for per-team quota — at which a workload must move. Criteria written before launch are followed; criteria written during an incident are not. - **Cost visibility.** Free prototyping hides the eventual bill. Have teams estimate tokens per request and requests per day during the prototype so the production cost is known before the decision to ship is made. ## The principal-level framing Treat GitHub Models as the front of a funnel, not the whole pipe. Its value is optionality — it keeps the cost of trying a model near zero and defers vendor commitment until you have evidence. Its risk is that optionality quietly becomes dependency, because nothing forces a prototype to graduate. The organisational answer is a portability discipline plus a written trigger for graduation, so a prototype that succeeds moves on purpose rather than by accident.