{"slug": "build-your-ai-stack-like-you-will-need-to-replace-it", "title": "Build your AI stack like you will need to replace it", "summary": "Teams building AI features should architect for portability now because current AI service pricing is heavily subsidized and will eventually rise, according to an analysis of AI vendor lock-in. The analysis recommends routing application calls through an internal abstraction layer — using open-source gateways such as LiteLLM or Portkey, a project it says one or two engineers can complete in a few weeks — rather than calling Claude, GPT, or Gemini directly. It warns that while code portability is cheap, behavioral portability is the real cost, since prompts, fine-tuned models, embeddings, tool-calling schemas, and caching mechanics are all vendor-specific and require rework when switching providers.", "body_md": "Every AI feature you’re building is based on a price that isn’t real. Current AI services are [heavily subsidized](https://ssir.org/articles/entry/low-cost-ai-illusion-nonprofits) as model providers seek to [expand their market share](https://www.wsj.com/tech/ai/ai-giants-are-handing-out-tons-of-free-computing-power-to-grab-startup-share-c00a5c5c), and subsidies inevitably end. Just think back to the early days of Lyft and Uber, when a single ride often cost less than taking public transit. As the costs associated with building on cheap AI infrastructure slowly start to reflect reality, the architecture decisions you made to get to market quickly may be the ones hemming you in.\n\nThis isn’t unique to AI. IT leaders have always had to weigh speed-to-value against the cost of dependency. What’s different now is how fast those dependencies are being built, and how little visibility most teams have into them.\n\nAcross IT, scalability is contingent on portability. And architecting with portability in mind is the best way to minimize lock-in as AI pricing models evolve, giving you leverage in future contract negotiations, and a fighting chance of switching platforms if the costs of one vendor get too high.\n\nThe challenge is that AI providers are incentivized to make leaving as painful as possible, which they achieve through deep integrations and proprietary features. You can control some of this through architectural decisions. Other parts are structural dependencies you should at least be aware of going in.\n\nSwapping platforms will never be painless, but it’s less painful than being locked in when your vendor decides it’s time to recoup its losses, as every AI provider eventually will.\n\nThe foundation for portability is the abstraction layer, an internal service your applications call instead of hitting Claude, GPT, or Gemini directly. It uses a request format defined by you, and translates that to whatever the vendor behind it expects. If you need to change vendors later, it’s closer to a configuration change than a code rewrite.\n\nYou don’t need to build this from scratch; open-source gateways like [LiteLLM](https://www.litellm.ai/) or [Portkey](https://portkey.ai/) already handle the routing and interface. Scoped to what you actually need, it’s a small project that one or two engineers can complete in a few weeks.\n\nFrom there, audit the parts of your codebase that call a vendor’s API directly and route them through your proxy layer one at a time (have fun with that). Skip the features you’re not using yet, like fine-tuning or batch APIs, and focus on the 80% case. Think: text in, text out, and maybe tool calls.\n\nThe API call is the easy part to abstract. Other dependencies may be tougher to account for given the pressure to deploy quickly, but you should at least be aware of them.\n\nPrompts get tuned to a specific model’s characteristics, and those instructions won’t necessarily make sense to another model. If you do switch vendors, expect to re-tune each prompt. Fine-tuning a model will box you in, unless you use an open-weight model that you operate internally.\n\nVectors generated by one provider’s model won’t be compatible with another’s, so switching means re-embedding your knowledge base. Tool calling and structured output conventions differ by vendor, so code written around one model’s schema will need rewriting for another. Caching and batching mechanics carry their own vendor-specific rules and cost implications that don’t map across providers.\n\nIn short, code portability is cheap. Behavioral portability is the real cost, and no gateway tool solves that for you.\n\nMost teams don’t realize how locked into a model they’re becoming until they’re forced to move, which is the worst time to find out. How many parts of your codebase import a vendor SDK directly, versus calling a shared internal function?\n\nIf you want a real answer instead of a guess, pick one workflow that isn’t business-critical and try porting it to a different vendor. See what breaks and how long it takes to fix. That will uncover your dependencies better than a checklist.\n\nThe bottom line is that you should treat AI providers like any other infrastructure vendor where concentration risk matters. Hold AI providers to the same standard you would apply to any IT or technology vendor. There will likely always be some level of dependency, but you should know where the hooks are and choose them deliberately. That way, you’re prepared when AI price hikes inevitably arrive.\n\n*—*\n\n*New Tech Forum* **provides a venue for technology leaders—including vendors and other outside contributors—to explore and discuss emerging enterprise technology in unprecedented depth and breadth. The selection is subjective, based on our pick of the technologies we believe to be important and of greatest interest to InfoWorld readers. InfoWorld does not accept marketing collateral for publication and reserves the right to edit all contributed content. Send all** **inquiries to** *doug_dineley@foundryco.com***.**", "url": "https://wpnews.pro/news/build-your-ai-stack-like-you-will-need-to-replace-it", "canonical_source": "https://www.infoworld.com/article/4212117/build-your-ai-stack-like-you-will-need-to-replace-it.html", "published_at": "2026-09-10 09:00:00+00:00", "updated_at": "2026-09-10 09:23:45.056819+00:00", "lang": "en", "topics": ["ai-infrastructure", "ai-tools", "developer-tools", "large-language-models", "ai-products"], "entities": ["LiteLLM", "Portkey", "Claude", "GPT", "Gemini", "Lyft", "Uber"], "alternates": {"html": "https://wpnews.pro/news/build-your-ai-stack-like-you-will-need-to-replace-it", "markdown": "https://wpnews.pro/news/build-your-ai-stack-like-you-will-need-to-replace-it.md", "text": "https://wpnews.pro/news/build-your-ai-stack-like-you-will-need-to-replace-it.txt", "jsonld": "https://wpnews.pro/news/build-your-ai-stack-like-you-will-need-to-replace-it.jsonld"}}