concept

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.

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 `<system>` 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 model name portability

Common mistakes

FAQ

What is 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.

When should I use model name portability?

Any production app to avoid lock-in. Multi-vendor cost / fallback strategies.

What are the most common mistakes with model name portability?

Hardcoding one vendor's tool-call schema — painful to migrate later. Over-engineering portability for one-off prototypes — premature.

Last updated: 2026-06-01. Raw markdown: https://promtable.com/glossary/model-name-portability.md.