19 providers · one integration

Ship on every model. Lock in to none.

The model that is best for your product changes every quarter. Fire makes that a string change: one key, one request shape, one bill across 53+ verified models — with the real cost of each call returned inline so your unit economics are a query, not a spreadsheet.

A torch whose flame flows into many glowing screens — one source feeding every model
No lock-in

Swap species_name, not your integration.

Anthropic, OpenAI, Google, Mistral, DeepSeek, xAI, Venice and more sit behind the same messages[] body and the same response envelope. Streaming, parallel fan-out and tool calls work the same way on all of them.

# Monday: the model you launched on
{ "species_name": "claude-sonnet-4-5",
  "messages": [ … ] }

# Friday: the one that just got cheaper
{ "species_name": "venice-uncensored",
  "messages": [ … ] }

# same key, same code, same bill

One billing relationship

One prepaid balance instead of a card on file with every lab. Top up via Stripe; every call debits the real amount.

One compliance surface

One data policy, one audit trail, one call_id scheme to cite in a customer dispute.

One catalog to watch

GET /v1/models with tier, modality and function filters, plus customer rankings.

Nothing to rewrite

Provider-specific quirks — reasoning budgets, image size policies, voice ids — are normalised by Fire's adapters.

Unit economics

The cost of every call is in the response.

meta.price.usd is the amount your account was charged for that call — not a list price, not an estimate. Store it next to the user id and your gross margin per feature is a GROUP BY.

Published per-model text rates and a flat per-image price mean you can forecast before you build; the portal's usage dashboard breaks real spend down by model, call type, token and day.

Cost-plus partner tier: real provider cost plus a flat, disclosed markup on every call, for teams that want pass-through rather than retail. Onboarded with a redeemable tier code.

Pricing in full →
An open ledger with a flame rising from its pages beside stacked coins and price tags
Verified, continuously

A catalog that is tested every week, not scraped once.

A model is sellable only after a live checklist passes: a real call succeeds right now, usage is reported, cost evidence exists, a price is published. The weekly audit re-runs it against every onboarded model.

✓

Live call succeeds

Not "listed by the provider" — answered, today, through Fire's own adapter.

#

Usage reported

Token counts come back from the provider, so billing is evidence, not a guess.

$

Cost verified

Provider-reported inline cost or a verified rate, checked against the published price for drift.

⟲

Pulled when it dies

A model that fails upstream is un-onboarded automatically — your fallback logic is already in the catalog.

Products, not prompts

Multi-step agents and compliance-checked pipelines, built in.

Flows (/v2/flows): DAGs of named agent personas with depends_on edges, parallel branches, repeat macros, web-search budgets and human-gate steps that pause a run until a reviewer resumes it. Queued, resumable, billed per step, designed visually in the portal.

Layer 2 image workflow (/v1/workflows/image): prompt expansion, pre- and post-generation compliance checks, rendering, generation and storage in one call — blocked images never leave Fire. The same pipeline runs ImageLab and the rest of the Modus Promethean image products.

A network of glowing nodes connected by flowing lines, a hand reaching in at a checkpoint
Integrate your way

Plain HTTPS. SDKs if you want them.

curl / any HTTP client

Every endpoint is JSON over HTTPS with a bearer token. The docs are written in curl.

Python · JavaScript · PHP

fire-sdk on PyPI, @moduspromethean/fire-sdk on npm, and a PHP client — thin wrappers over the same endpoints.

Self-describing

GET /v1/capabilities returns every endpoint schema and the model catalog without auth — generate your own client from it.

Questions

Founders ask

What does switching models actually involve?

Changing the species_name string in the request. The message shape, the auth header, the response envelope and the billing are identical across every provider Fire fronts, so an A/B between model families is a config change, not a branch.

How do we know a model in the catalog still works?

A model is only listed after it passes a live onboarding checklist — a real call succeeds, usage is reported, cost evidence exists, a sell price is published. A weekly audit re-runs the same checklist against every model; one that dies upstream is un-onboarded automatically and disappears from /v1/models and this site the same day.

What is the cost-plus partner tier?

Instead of the published retail rate, a partner account is billed the real provider cost plus a flat, disclosed percentage, computed fresh on every call. Onboarding is by a redeemable tier code. Logging, metering and the per-call price in meta.price work exactly the same way.

Can we run multi-step agent products on it?

Yes — /v2/flows runs DAGs of named agents with parallel branches, repeat macros, web-search budgets and human-gate steps. Runs are queued, resumable and billed per step. Flow definitions and agent configs are owner-scoped to your account.

Is there an SDK, and do we have to use it?

Packages exist for Python (fire-sdk on PyPI), JavaScript (@moduspromethean/fire-sdk on npm) and PHP, but the API is plain JSON over HTTPS and every example in the docs is curl. Nothing requires the SDK.

A raised hand holding a burning torch — the Fire brand emblem
Ready when you are

One integration. Every model. Real costs.

Create a free account, mint a key, ship. Ask about the cost-plus partner tier when volume justifies it.