# Model name portability **Source:** https://promtable.com/glossary/model-name-portability > Model name portability is the principle of writing app code that survives swapping the underlying LLM provider (Claude → GPT → Gemini → local) without rewriting prompts, tool definitions, or response parsing. --- Model name portability is the principle of writing app code that survives swapping the underlying LLM provider (Claude → GPT → Gemini → local) without rewriting prompts, tool definitions, or response parsing. Tight provider coupling makes vendor-switch painful: different prompt formats, different tool-call schemas, different response shapes. Portability strategies: (1) use a multi-model SDK (Vercel AI SDK, LiteLLM, OpenRouter) that normalizes the request / response shape, (2) write prompts in vendor-neutral natural language (no `` tags or vendor-specific markers), (3) use structured output via JSON schema (which all providers support similarly), (4) keep tool definitions in OpenAI / MCP format. Trade-offs: portability sometimes means missing vendor-specific features (Anthropic's prompt caching, OpenAI's function-calling strict mode, Google's grounding). Production reality: most teams stay multi-vendor for cost / fallback reasons, so portability work is rarely wasted. ## When to use - Any production app to avoid lock-in. - Multi-vendor cost / fallback strategies. ## Common mistakes - Hardcoding one vendor's tool-call schema — painful to migrate later. - Over-engineering portability for one-off prototypes — premature. ## Related terms - [llm-gateway](https://promtable.com/glossary/llm-gateway) - [model-router](https://promtable.com/glossary/model-router) - [bring-your-own-llm](https://promtable.com/glossary/bring-your-own-llm) *Last updated: 2026-06-01* --- Original page: https://promtable.com/glossary/model-name-portability Maintained by Promtable (https://promtable.com). Content: CC BY 4.0. Cite as "Promtable — https://promtable.com/glossary/model-name-portability". Contact: info@vibecodingturkey.com.