Cloud AI providers

The four cloud AIs we deploy with.

Anthropic Claude. OpenAI GPT. Google Gemini. xAI Grok. Four providers, four model families, four release cadences - each strong at a different shape of work. Most projects ship on one; some route across several. Here is what we look at, what each provider tends to do well, and when our local-LLM offering is the better answer instead.

Last updated:

Why this exists

Picking the cloud provider before knowing the workload is picking blind.

The decision usually arrives early - first call, first paragraph of the brief - and it locks more than it looks like it locks. The provider you pick shapes the latency budget, the tool-call surface, the data flow, the pricing curve at scale, and the migration cost when the next better model lands somewhere else. None of that is recoverable by 'we will switch later'; switching later is an integration project, not a flag.

The four providers we deploy with - Anthropic, OpenAI, Google, xAI - are each strong at a different shape of work. We pick per-task on most engagements and lock to one only when the operational simplicity is worth the trade. The selection is a Discovery output, not a marketing decision.

Five things we evaluate

The selection criteria we apply on every project.

  • Pricing model

    Per-token, tiered by capability across each provider. Tier names differ - flagship reasoning, balanced workhorse, compact fast - and the absolute number per tier moves quarterly. We model your projected volume against current published rates and the realistic mix of flagship vs routine calls; the cost gap between tiers is usually 5×-20×, so routing matters more than the headline price.

  • Latency posture

    Streaming first-token latency on flagship-class models runs sub-second under normal load; reasoning-heavy or extended-thinking calls run multi-second. Provider-published benchmarks are produced on tuned hardware and short prompts - useful as a ceiling, not as a prediction for your real prompt mix. We measure p50 and p95 on a captured sample of your prompts during Discovery.

  • Tool and agentic capability

    Function calling is table stakes everywhere. Parallel tool use is supported on every flagship in the lineup; the operational quality varies. Computer use, MCP support, agentic-loop primitives, and structured-output reliability are where the providers diverge - and where the right pick depends on what your agent actually needs to do.

  • Data handling and DPA

    Each provider publishes a Data Processing Addendum. The signal we look at: training-on-input default, retention default and adjustability, sub-processor disclosure, and EU-residency options. None of the four train on API inputs by default in 2026. Retention defaults vary; EU-resident inference is available on three of four through cloud-platform routing (Vertex AI, Azure, AWS Bedrock). Where EU residency on the cloud path is not acceptable, our local-LLM offering takes over.

  • Model lineup and cadence

    Each provider ships a small lineup - flagship reasoning, balanced workhorse, compact fast - that maps onto the same routing pattern. The release cadence is the variable: Anthropic and OpenAI ship more often than Google or xAI as of this writing. The right pick today is not necessarily the right pick in two quarters; the routing layer is what makes that survivable.

Two delivery architectures

One provider, or routed across.

Both shapes ship to production every day. The choice tracks the workload mix, the operational surface you want to maintain, and your tolerance for the next-model-elsewhere problem. We deploy in either shape; here is how the trade-off usually breaks.

Single provider
all calls go through one API
  • Lower coordination overhead - one DPA, one billing surface, one paging chain
  • Faster MVP - pick one, ship, iterate; tooling integrates against one SDK
  • Concentrated risk - model deprecations, latency incidents, and pricing shifts hit every flow at once
  • Capability ceiling moves at the chosen providers release cadence
  • Switching providers later is an integration project, not a flag
Routed across providers
right model for each task
  • Best-fit per call - reasoning to one provider, structured output to another, vision to a third
  • Built-in fallback - when one provider has an incident, the rest carry the workload
  • Diversified spend - flagship cost is amortised across cheaper providers for routine calls
  • Capability stays current - new model from any provider drops into the routing layer with a config change
  • Larger integration surface - four DPAs, four billing surfaces, more operational discipline required
When each tends to win

How we route, by provider.

  • Anthropic Claude

    Default for long-context reasoning, careful tool use, and agent loops where the failure mode of going off the rails matters more than raw speed. The Sonnet tier carries most of the production weight in our deployments; Opus handles the heavy reasoning calls; Haiku covers high-volume routine.

  • OpenAI GPT

    Default for structured-output reliability and the largest mature ecosystem of tools and integrations. Strong at JSON schema adherence and function-calling fanout patterns. The mini and nano tiers carry routine workloads at attractive cost.

  • Google Gemini

    Default for multimodal workloads - image, audio, and long-document inputs - and the longest-context window in the lineup. Strong fit when EU-resident inference via Vertex AI is a hard requirement. The Flash tier is one of the cheapest capable options in the high-volume tier across the four providers.

  • xAI Grok

    Default for real-time-information tasks where the model needs current state of the world. Used selectively rather than as a workhorse; pairs well with the others as a current-events fallback in research-heavy agents.

The four cloud providers, in detail

What each provider actually offers.

  • Anthropic Claude

    Pricing - per-token, tiered across the Opus / Sonnet / Haiku lineup. Prompt caching available to compress repeat-prefix workloads. Latency - sub-second streaming on Sonnet-class for short prompts; multi-second for extended-thinking calls. Tools - function calling, parallel tool use, computer use, and an agentic harness for packaging multi-step workflows. Data handling - DPA on file with sub-processor disclosure; no training on API inputs by default. EU-resident inference is available via AWS Bedrock and Google Cloud Vertex AI.

  • OpenAI GPT

    Pricing - per-token across the GPT-5 family with full / mini / nano variants; reasoning models priced on a separate ladder. Latency - sub-second on the smaller variants; multi-second on reasoning models. Tools - function calling, parallel tool use, structured outputs with strict schema mode, and an Agents framework. Data handling - Standard DPA available; opt-out from training on API inputs is the default for paid API tiers. EU-resident inference is available through Azure OpenAI Service.

  • Google Gemini

    Pricing - per-token across the Gemini 2.5 family with Pro / Flash / Flash-Lite tiers. Latency - sub-second on Flash tier; longer on Pro for reasoning calls. Tools - function calling, parallel tool use, native multimodality (image, audio, video, PDF), and the longest published context window in the lineup. Data handling - DPA via Google Cloud terms; no training on API inputs in the paid Vertex AI path. EU-resident inference is available via Vertex AI region selection.

  • xAI Grok

    Pricing - per-token across the Grok-4 family with full / mini / fast variants. Latency - sub-second on the mini and fast tiers. Tools - function calling, structured outputs, and a real-time information mode that pulls current state of the world from xAI infrastructure. Data handling - DPA available on the enterprise tier; training-on-input defaults vary by tier and should be verified per project. EU-resident inference posture is less mature than the other three providers.

FAQ

Five things people ask.

How do you decide which provider to use for a given task?
Latency budget, structured-output reliability, tool-call patterns, data residency, and cost at projected volume. We measure p50 and p95 on a captured sample of your prompts during Discovery and produce a written routing recommendation with the reasoning behind each route.
What happens if the provider we pick deprecates a model we depend on?
Each provider publishes deprecation timelines on their model documentation pages; we track them and migrate before the cutoff. The routing layer abstracts the model name from the application call site, so the migration is a config change and a smoke-test pass - not a refactor.
How do you handle data residency for regulated workloads?
EU-resident inference is available on three of the four providers via cloud-platform routing - Vertex AI, Azure, AWS Bedrock. The data flow is documented in the DPA before any data flows. When EU residency on the cloud path is not acceptable, our local-LLM offering takes over and the cloud providers stay outside the data flow entirely.
Can we change providers after the project ships?
Yes. Provider selection lives in the routing layer, not in your application code. Changing the route on a workload is a config edit plus a smoke-test pass. The routing layer is the part of the architecture that buys you that flexibility.
What is your routing approach in practice?
A small opinionated set of routes per workload, written down and reviewed quarterly. Reasoning-heavy tasks go to the strongest reasoning model; structured-output tasks to the most reliable schema-following model; high-volume routine calls to the cheapest capable model. Every route is documented with the reasoning and a fallback chain so it stays debuggable when the lineup shifts.
AI that already runs

Tell us your workload mix.

We model API versus Local for your actual numbers and produce a written routing recommendation across the four providers above. Free.

Live · powered by Gemma-4 · running on our hardware in Sofia