Your team has a working demo and a feature estimate. Before you put a release date in front of customers, check which parts of that estimate depend on a provider’s permission, access programme or temporary benefit.
A model announcement may precede access for your organisation. Ownership of generated text may coexist with restrictions on how you use the service. Credits may cover the prototype while leaving the ongoing funding decision unresolved. Each condition can change what you can responsibly promise.
For a CTO committing a customer-facing feature, the useful outcome is a decision: accept the dependency, constrain the feature around it, or defer the commitment until a missing condition is settled. The relevant agreement matters throughout; an announcement or help page cannot establish your company’s complete contractual position.
Answer in 60 seconds
Before committing an AI feature to customers, establish access through the intended production organisation, clarify the proposed use under the applicable agreement, and fund operation beyond credits or introductory pricing. If continuity depends on changing provider, evaluate the replacement on the actual task and check that the recovery workflow can operate.
Then make one decision: accept the dependency and record when to revisit it, constrain the feature around the unresolved condition, or defer when that condition is essential to the promise.
In this article
- Identify the AI provider dependency behind the feature
- Confirm model access before committing to a release
- Check API terms and output-training permissions
- Plan production costs after API credits expire
- Test an alternative before promising a provider switch
- Accept, constrain or defer the AI feature
1. Identify the AI provider dependency behind the feature
An AI provider dependency is a part of the feature that relies on conditions controlled by the model supplier, such as access eligibility, permitted use or pricing.
Those conditions can change within days. On 3 June 2025, Windsurf CEO Varun Mohan wrote: “With less than five days of notice, Anthropic decided to cut off nearly all of our first-party capacity to all Claude 3.x models.” Windsurf had to find capacity with third-party inference providers and warned of short-term availability issues for users trying to reach Claude. Anthropic said it was “prioritizing capacity for sustainable partnerships” (TechCrunch).
Consider a hypothetical support assistant inside a software product. It answers customers’ questions from current help material, cites the supporting page and passes uncertain cases to a person. The team also wants to explore using approved generated replies to train a smaller specialist model later. Each provider example below tests a different assumption in that proposed feature.
Write down what a customer will be able to do at release. In this example, the promise is a supported answer from the current help material, with a route to human support when the system cannot establish one.
That description gives you something to evaluate. Can the proposed implementation retrieve the right page, distinguish an outdated instruction and handle a question the documentation does not answer? What happens if the model is unavailable? Which part of the experience still works?
Then separate the first release from the later training idea. The assistant’s ability to answer today and your permission to reuse its outputs in another model are separate decisions. Treating the second as an assumed future saving could distort the architecture or business case for the first.
For each consequential assumption, keep the evidence beside the feature decision: the exact model and access route, the applicable document or account setting, when it was checked, and what would change if it ceased to hold. Give someone responsibility for resolving uncertainty and revisiting the decision when the relevant condition changes.
An introductory price or credit benefit ending under its existing conditions is different from a later contractual amendment. For example, Anthropic’s amendment clause, M.3, provides for updates to take effect 30 days after either posting or the customer’s receipt of other Notice. Updates responding to changes in law or regulation take effect immediately on posting or Notice; changes are non-retroactive. In your feature record, include the clause that applies to your agreement, where updates and notices appear, who checks them and which change reopens the release decision.
The purpose is to find the assumption that can move the release date, scope or operating budget. A long supplier questionnaire is of little help if that assumption remains unanswered.
2. Confirm model access before committing to a release
Google’s 28 October 2026 Gemini 4 Carbon announcement describes a staged rollout, starting with a subset of cyber defenders and extending to additional trusted partners. It describes broader developer and business availability as a future step. That announcement does not establish access for your organisation.
It also announces introductory rates of US$2 per million input tokens and US$10 per million output tokens, followed by US$4 and US$20 after the introductory period, without giving an end date. It does say Carbon launches at the same introductory price as Argon, and Google’s pricing page lists Argon at those rates through 30 November 2026, then US$4 and US$20 from 1 December. Carbon was not on that page on 6 November, so its own date is still open.
For the hypothetical assistant, the immediate question is whether the intended production organisation can use the candidate model through the route your product will need. A successful demonstration elsewhere does not answer that question.
Before making the model part of the release commitment, establish the available account, endpoint and capacity for the expected workload. If access is still conditional, choose an available implementation you can evaluate, reduce the promise to match what is available, or leave the date conditional. Waiting for a particular model is a product choice that deserves an explicit reason.
The check we would run first is a single test: put the feature through the company account it will ship on, with your own material, at realistic volume and at paid rates. That one test reaches access, quota, quality and cost together.
Budget for the applicable ongoing rate as well as the introductory price. An unknown promotion end date should remain an unresolved input, rather than become an assumed period of lower cost.
3. Check API terms and output-training permissions
Anthropic’s default commercial terms, effective 17 June 2025, address output ownership in section B and competing use in section D.4. The latter says customers may not “access the Services to build a competing product or service, including to train competing AI models or resell the Services except as expressly approved by Anthropic”. Reading the ownership provision alone would miss that separate restriction.
The Claude output-training help page leaves a further question. Its opening broadly refers to written permission for model training and development, while a later section allows non-competing specialised models, such as classifiers and summarisation tools. Its prohibited examples include general purpose chatbots, models designed for open-ended text generation and using outputs as training targets, and a support model trained on approved replies could sit close to those. Those passages do not give a clear answer for every proposed training pipeline.
In the support example, draw the proposed path: generated answer, human approval, stored training example, specialist model, intended users. Ask the provider to clarify that concrete use under the applicable agreement. Obtain scoped contract advice where necessary before relying on the permission.
Meanwhile, decide whether the first release has value without that later training step. If it does, keep the training plan outside the committed scope until the question is resolved. If the business case depends on that step, the uncertainty belongs in the approval decision now.
4. Plan production costs after API credits expire
OpenAI’s API credit guide says eligible ChatGPT Pro and Business subscriptions can link their benefit to an API organisation. Eligibility includes ownership requirements and a matching account email. Credits apply to the linked organisation, expire at the billing-cycle boundary and do not roll over; Business workspaces paying annually upfront receive a year’s grant with annual expiry. The benefit stays subject to API rate limits. Future grants stop when a subscription becomes ineligible.
For the assistant, record the receiving organisation and who controls its funding. Then estimate operation without the benefit: representative requests, input and output usage, paid rates, and the surrounding retrieval and application costs.
Compare that estimate with the feature’s proposed price or budget. Decide how the service will be funded after credits are used or expire, and what customers will experience if funding is unavailable: the guide says that when no credits remain, API requests fail with HTTP 429 and the error code credit_balance_exhausted. The credit balance and the capacity to serve requests answer different questions.
A benefit can make experimentation easier. Treat its eligibility and renewal conditions as part of the funding arrangement when deciding whether it can support a customer commitment.
5. Test an alternative before promising a provider switch
For this feature, assess LLM vendor lock-in through the work needed to move it: integration changes, evaluation, data preparation and the effect on customers.
An adapter around a model API can give your code a place to change the integration. It leaves a further question: will a replacement preserve the experience you promised?
A replacement can also arrive without a decision on your side. Google’s changelog for 2 November 2026 says that from 1 December 2026, all API requests to gemini-2.5-pro will automatically route to gemini-3.8-flash and be billed at that model’s rates. A feature built on the older model moves to a different model and its rates on a published date, so the comparison below has to happen before then.
For the support assistant, compare candidates on the same representative questions and source material. Include an outdated page, conflicting instructions and a question with no supported answer. Inspect whether the system cites relevant evidence and escalates appropriately. Compare the surrounding work too: prompt changes, output handling, retrieval, response time and operating cost.
Set acceptance criteria from the feature’s needs before interpreting the comparison. A replacement that produces fluent text but mishandles unsupported questions would require a product decision. You might change the workflow, add review or retain the original provider. An API response alone would not establish a usable substitute.
The advice we would argue with is that keeping a backup provider is enough. A second integration proves that a call goes through, not that the feature still does what you promised. Keeping one is reasonable when the backup has been evaluated on the real task and the team can run it. It lets a team down when the backup exists only as code nobody has tested since it was written.
Our guide to building an AI assistant, agent or platform follows this sequence: model choice comes after evaluation on the actual material, and a second model needs a demonstrated purpose in the workflow. It adds another component to test and operate.
For this feature, an alternative might be a reviewed draft for support staff while automatic answers are unavailable. That changes the customer experience and the human workload. Check that the support team can operate it before describing it as a recovery option. Our guide to stopping an AI workflow develops the separate question of what a controlled stop interrupts.
6. Accept, constrain or defer the AI feature
Bring the evidence back to the release discussion. The table below illustrates possible decisions for the hypothetical assistant; it reports no tested implementation or client result.
| Condition | Evidence to establish | Possible product decision |
|---|---|---|
| Access depends on a staged programme | Access through the intended organisation and production route, with relevant capacity | Keep the release conditional or evaluate an available candidate |
| Later training depends on unresolved output use | Applicable agreement and clarification of the actual training path | Exclude training from the committed scope; defer if it is essential to viability |
| The estimate relies on credits or introductory pricing | Eligibility, expiry, ongoing rates and a funded operating estimate | Accept the paid cost, change scope or revisit the business case |
| Continuity depends on another implementation | Evaluation against the promised task and an operable recovery workflow | Accept the interruption, constrain the promise or fund the required alternative |
Accepting a dependency can be a reasonable decision. For example, you might accept one provider for a bounded release because access is established, the intended use is clarified, paid operation fits the budget and a defined interruption is tolerable. Record that reasoning and the event that would reopen it.
Constraining the feature is useful when the valuable part can proceed independently of the unresolved assumption. Here, the assistant might launch without the future training commitment, or initially prepare replies for human review. State the resulting experience clearly in the roadmap and customer communication.
Defer when the missing condition is essential to the promise. If the feature requires an unavailable model or depends financially on an unconfirmed training path, more implementation work will not settle that condition.
Our own line is this. We build on one provider when access is confirmed on the production account, the use is allowed and the paid cost fits the budget. We won’t promise a date on a model you can’t access yet, or “we can switch any time” before the switch has been tested.
Conclusion: settle the assumption behind the commitment
On a working call with a CTO, we put it this way: “Before we promise this feature, let’s list what has to stay true on the provider’s side: access, terms and price. Anything we don’t control goes in the plan as a risk, with a date to recheck it.”
The next step is small: take the feature currently awaiting commitment and identify its most consequential unsupported assumption. Attach the current evidence, name who will resolve it and write the scope, date or budget decision that follows from each answer. That gives the next roadmap discussion a concrete issue to settle.
Review the feature with us
If that decision needs an external technical review, bring the feature promise, proposed architecture, provider route and unresolved condition to our Fractional CTO architecture and roadmap review. The service includes vendor evaluation and starts with a fixed quote for the agreed scope.
Frequently asked questions
Output ownership alone does not settle the permitted use of the service. In the Anthropic example, the commercial terms separately restrict competing uses, while the help page leaves questions about particular training paths. Describe the intended pipeline and clarify it under the applicable agreement before relying on that reuse.
Credits can contribute while available under their conditions. To approve the feature, estimate operation at the applicable paid rates and establish who will fund it after the credits are used or expire. Check API capacity separately from the credit balance.
A second integration does not establish portability. A usable substitute must meet the feature’s acceptance criteria on representative material, and the recovery workflow must be operable. Include changes to behaviour, integration work, cost and human workload in that decision.
Sources and limits
Sources checked: 6 November 2026. The linked provider documents support the specific access, terms, pricing and credit details discussed here. The Windsurf account comes from TechCrunch’s report of 3 June 2025, which quotes both companies.
The support assistant is hypothetical; no provider comparison, migration or recovery exercise was performed for this article. Your applicable agreement and account configuration need checking before relying on the examples for a release decision. The positions stated as ours are recommendations, not results from a measured project.