Fire vs calling OpenAI, Anthropic or Google directly

Side by side

N integrations or one.

Dimension	Through Fire	Direct to each provider
Credentials	One `fire_sk_` key. Provider keys stay in Fire's vault; your code and agents never hold them.	One key per provider, rotated and secured per provider.
Billing	One prepaid balance; every call debits the exact amount and returns it in `meta.price.usd`.	A card and an invoice per provider; cost reconciled from each dashboard after the fact.
Request shape	One `messages[]` body and one response envelope for all 19 providers. Change `species_name` to change model.	Each SDK's own shape, parameters and error codes; switching providers is a code change.
Modalities	Chat, images, edit, upscale, speech, transcription, decisions and multi-agent flows on the same key.	Per provider, where offered.
Catalog health	53 models, each live-tested on onboarding and re-audited weekly; dead models are pulled automatically.	You find out a model was deprecated when the call fails.
Latency	Provider time plus one hop and Fire's processing — tens of milliseconds.	Provider time only.
Price	Published retail rate, or on partner accounts provider cost plus a disclosed markup. Fire's margin is real and visible.	Provider list price. Cheaper for a single-provider workload at scale.
Newest provider features	Available once onboarded and verified — not on day one of a provider beta.	Day one.
Audit trail	Every call logged with `call_id`, tokens, price, duration and error; content only if you opt in.	Whatever each provider's dashboard exposes, in each provider's format.
Feedback loop	Report or rate any call by `call_id`; ratings feed public rankings.	Support tickets per provider.

What the hop buys

The number you were charged, on every call.

Direct APIs tell you tokens; you compute cost from a price sheet and hope it hasn't changed. Fire does that computation at the moment of the call — against the published rate or the real provider cost — and returns the result as meta.price.usd. Store it beside the user id and your margin per feature is one query.

The same hop normalises the awkward parts: reasoning-model budget floors, per-model image size policies, voice ids, and provider error codes become one vocabulary.

# one body, any provider

curl -X POST https://fire.prosaga.net/v1/chat \

  -H "Authorization: Bearer $FIRE_API_KEY" \

  -d '{"species_name":"gemini-2.5-pro",

      "messages":[{"role":"user","content":"…"}]}'

# → { "content": "…",

#     "usage": {"input": 412, "output": 96},

#     "meta": { "price": {"usd": 0.00118}, "call_id": "…" } }

Being straight about it

When you should go direct.

⚡

Latency-critical loops

If your product's budget per call is under ~100 ms, an extra hop is a real fraction of it. Call the provider directly for that path.

β

Provider-specific betas

A brand-new endpoint or parameter Fire has not onboarded yet. Fire adds features after they are verified, not the day they are announced.

%

Single-provider volume

If you will only ever use one provider at serious scale, their list price beats cost-plus. Fire's margin pays for aggregation you would not be using.

Most teams mix: Fire for the bulk of traffic and the portability, a direct key for the one provider-specific feature they rely on. Nothing in Fire stops you.

Keys

Fewer secrets in fewer places.

Going direct means a provider credential in every service that calls a model, each one a rotation to schedule and a leak to worry about. Through Fire there is one key, and it is a badge for your account rather than a credential for anyone's infrastructure — revoke it in the portal and nothing upstream changes.

Need a third-party service from inside an agent? The vault broker forwards the call with the credential injected server-side. The agent never sees it.

Fire for AI agents →

Questions

Teams weighing this ask

How much latency does Fire add?

One extra HTTPS hop plus Fire's own work — auth, billing gate, adapter translation, logging — which is on the order of tens of milliseconds on top of the provider's own response time. For a multi-second generation it is noise; for a sub-100 ms classification loop it is measurable, and going direct may be right.

Is Fire more expensive than going direct?

Retail accounts pay a published per-model rate; cost-plus partner accounts pay the real provider cost plus a flat, disclosed percentage. Either way Fire is charging for the aggregation, so a single-provider workload at scale can be cheaper direct. What you buy with the margin is one key, one bill, one audit trail, a tested catalog and the price of every call in the response.

What do we lose by going through Fire?

Access to provider features Fire has not onboarded yet — a brand-new beta endpoint, an exotic parameter, a model that has not passed the onboarding checklist. Fire normalises the common surface; if you need a provider-specific edge, call that provider directly for that feature.

Do we have to choose one or the other?

No. Many teams run the bulk of traffic through Fire for portability and accounting, and keep a direct key for the one provider-specific feature they depend on. Nothing in Fire prevents that.

What happens to our prompts in transit?

Fire forwards them to the provider you chose and, by default, keeps only the call's metadata afterwards — prompt and response content is discarded unless your account opts in. The provider's own retention policy still applies upstream, exactly as it would if you called them directly.

Ready when you are

Keep your direct keys. Add one that reaches everything.

A free account and your first key take a minute. Route a slice of traffic through Fire and compare the numbers.

Get your API key → Fire vs OpenRouter