Do I need a layer that can swap model vendors without app changes?

You probably don’t need a vendor-swapping layer unless one of these is true:

• You expect to switch providers often due to cost, quality, latency, or policy changes.
• You want multi-model failover or routing by task.
• You’re building a platform/product where customers choose their own provider.
• You need strong portability for compliance, procurement, or lock-in risk.
• You’re still experimenting and don’t know which vendor will win.

If your app is:

• relatively small,
• using one vendor well,
• and you don’t anticipate a near-term switch,

then a dedicated abstraction layer can be extra complexity with little benefit.

Good reasons to add one

• You want to hide vendor-specific APIs behind your own interface.
• You need standardized request/response objects.
• You plan to support multiple models for different use cases.
• You want easier testing and retries.
• You want centralized logging, cost tracking, and rate-limit handling.

Reasons not to

• Abstraction can flatten useful vendor-specific features.
• It adds maintenance and can become a leaky abstraction.
• “Swap without app changes” is hard in practice because vendors differ in:
  • tool/function calling
  • streaming formats
  • image/audio support
  • context windows
  • safety controls
  • pricing and quotas

Practical recommendation

A good middle ground is:

• keep vendor-specific code at the edge,
• define a small internal interface for the 80% use case,
• but allow escape hatches for vendor-specific features.

That gives you portability without over-abstracting.

If you want, I can give you a decision checklist or a minimal adapter/interface design for this.