← Back

Capabilities

Stop being locked in to whichever model you integrated first

The model your teams picked eighteen months ago is now a fact about your architecture. It does not have to be, and unpicking it should not need a release from every team that ships AI.

A better model launches, or a provider raises prices. Someone works out what switching costs, the answer is a quarter of engineering time across a dozen services, and the conversation ends. That is not a model problem. It is a purchasing position you gave away by accident.

Model choice in your source
12services to edit
12releases to schedule
7teams to persuade
1quarter, realistically
Model choice in policy
0services to edit
0releases to schedule
1person to decide
1afternoon
Fig 06AThe same switch, before and after.

What it changes for the business

  • You get to negotiate. A provider who knows you cannot leave prices accordingly. Being able to move in an afternoon changes the conversation.
  • Model decisions stop being release decisions. Choosing a cheaper or better model becomes a change of configuration rather than work for every team that touches AI.
  • A provider outage stops being your outage. Traffic moves to an alternative automatically instead of waiting for someone to ship a fix.
  • Data questions get an answer. Where a model runs is something you set centrally, so "can we use this model for that data?" has a place to be decided.

How it works, briefly

Your applications keep the client library and the request shapes they already use, and point at Squidder instead of at a provider. Which model actually serves each request is decided by your policy, per application. More than twenty providers are supported behind that single point, including the major hosted ones and models you run yourself.

How this is handled elsewhere How Squidder does it
Model name hard-coded in each service Chosen by policy, per application
Switching means a release per team Switching is a configuration change
Provider keys spread across repositories Held in one place, not in your code
Outage means an incident and a rollback Automatic failover to an alternative
Locked to one vendor's ecosystem One way of working across all of them

Model routing

Which model serves each application. Changed here, not in anyone’s source.

4 applications
ApplicationModel serving itRuns inFailover30 days
support-assistantclaude-sonnet-4.5eu-westTwo alternates1.2M
claims-assistantgpt-4.1-minieu-westOne alternate840k
contract-reviewclaude-opus-4us-eastTwo alternates96k
catalogue-enrichllama-3.3-70bon-premNone2.4M
Fig 06BFour applications, four models, decided centrally.

Where it fits, and where it does not

Anything sitting between your request and a provider is a thing that can be wrong, and a parameter it does not recognize is a parameter that does not arrive. That is why an untranslated path exists for the cases where you need a provider's exact behavior, including a capability released last week. Use the common path for the common case and the exact one where fidelity matters.

Where to start

Take the least critical service you have that calls a model. Point it at the gateway and change nothing else. Then switch its model centrally and confirm the service never noticed. That is the whole proof.