Questions, answered plainly.

The control plane between your application and the AI providers you already pay. You connect your own provider accounts; one API covers text, image, video and audio across them; and INFRO handles routing, retries, failover, request logs, cost attribution and policy. You keep the models and the accounts you already chose — what changes is that there is one integration, and one place the cost and latency of every request is visible. Your providers still bill you for model usage, at your rates; INFRO charges a subscription for the software.

Not yet — though the gateway is further along than 'planned'. It is deployed at api.infro.io, the console is deployed at dash.infro.io, and the model catalog and complete API documentation are public and final enough to review. What is not open is self-serve purchasing and general key issuance: early-access accounts get keys first. Nothing on this site is purchasable today, and every capability we describe carries the release it lands in rather than being implied to exist.

If you use one model from one vendor and nobody has asked what it costs, you probably should go direct — that is a real answer and we would rather give it than waste your evaluation. INFRO earns its place when at least one of these is true: you run several models across several vendors, a provider incident has taken your product down, someone has started asking which customer or feature is spending what, or provider keys have started appearing in more than one place. You still call the same providers on the same accounts; you stop owning the integration, the failover and the accounting between them.

Nothing. 0% markup on model spend, and it is structural rather than a promise: your requests run on your own provider accounts under your own credentials, so your provider invoices you directly and INFRO is never party to that transaction. There is no arrangement under which we could take a percentage of it. What INFRO charges is a flat subscription for the control plane — the gateway, request logs, cost attribution, budgets, policy and the audit log — and it is priced on gateway requests and organization features, never on tokens.

No. A model id resolves to the model that id names — no smaller variant, no quantized build, no shortened context — and your request reaches your provider as you wrote it. If a model id ever resolves to something else, that is a bug and a serious one. What INFRO adds is around the request rather than inside it: which of your connections served it, what it is estimated to cost you, whether a fallback rescued it, and whether it was allowed by your policy.

For text, no. The endpoint speaks the OpenAI request and response shape, so you change the base URL, the key, and the model string — two lines in most codebases — and your client library, request bodies, response parsing, and error handling are untouched. Image, video, and audio use one consistent INFRO shape across every model, which is new code, but it is new code you would otherwise have written per vendor.

It adds a hop, and pretending otherwise would insult you. The gateway is being built to run at the edge, at the point of presence nearest your caller, against a published routing-overhead target of under 40 milliseconds — a target, stated as one, because there is no production traffic yet to measure. Two things will keep the hop honest: every request records its own latency in the console, so the number that matters gets measured on your workload rather than asserted by us, and long renders are dominated by generation time, where milliseconds of routing are noise.

That is the design. You connect the provider accounts you already hold, so your negotiated rates, committed spend, discounts, quotas and enterprise agreements keep applying exactly as they do today — your provider bills you, at your prices, and INFRO takes none of it. If you have negotiated rates below the published ones, enter them in the console and every cost figure INFRO shows you is computed from yours rather than from a list price. Leaving is the same two lines as arriving: change the base URL and the key back, and your provider accounts are untouched because they were always yours.

Routes are scored against live error rate, latency, and rate-limit pressure, so a degrading route leaves rotation. On a timeout or a 5xx before the response has started streaming, the request is retried on another route. Your application sees a successful response instead of somebody else's incident. Once a stream has started we cannot silently restart it — a partial response is surfaced as one rather than quietly re-rolled.

We become one more dependency — that is the honest cost of the trade, and you should price it in. Three things make it survivable. The status page runs on a separate, far simpler deployment than the gateway, so it stays up to tell you. Text speaks the OpenAI shape, so keeping a direct provider key and a base-URL switch in your config is a two-line contingency we actively recommend. And there is no published uptime SLA, because a service with no operating history cannot honestly offer one; enterprise agreements carry a contractual SLA.

Yes, and the migration back is the same two lines that brought you in. Your usage history exports as request-level CSV and over the usage API, so your cost record leaves with you rather than living only in our console. We would rather earn the renewal than hold the integration hostage — a customer who cannot leave has no reason to trust anything else on this page.

We never train on your prompts, inputs, or outputs, and we never sell them. Usage metadata — model, timings, token counts, cost — is always recorded, because it is what your bill is computed from. Prompt and completion content is a separate, optional feature that is off by default; turn it on per organization and choose the retention window, or leave it off and content is never written to disk. The two live in separate stores precisely so one can be deleted without touching the other.

Not yet, and we will not claim otherwise. Regional processing requires infrastructure entitlements we have not purchased, and a hostname that merely looks European is a compliance claim a customer can falsify in one request. When it is genuinely enforced we will say so; until then, assume requests are processed wherever capacity is, and treat that as a reason to talk to us before signing anything that depends on residency.

Today the honest answer is that you read the documentation — it is complete, including the error taxonomy and webhook signatures. A browser playground that runs any catalog model and hands you the equivalent API call is on the roadmap, not built. Since text keeps the OpenAI request shape, the cheapest real evaluation once keys open is pointing an existing client at a new base URL for one endpoint.

Two separate bills that never move together. Your providers invoice you for model usage, directly, at your own rates — INFRO is not in that transaction and takes 0% of it. INFRO invoices you for a plan: a flat monthly or annual subscription for the control plane, priced on gateway requests and organization features rather than on tokens. There is a free Developer plan with smaller allowances and no time limit, and committed volume gets an enterprise agreement with invoicing. Provider spend never appears on an INFRO invoice.

The frontier set the day it matters, plus the budget and open-weight workhorses behind it — 150+ across text, image, video, and audio. GPT-5.6, Claude Fable 5 and Sonnet 5, Gemini 3.1 Pro, Grok 4.6, Sora 2, Veo 3.1, Kling O3, Seedance 2.5, Nano Banana Pro, Seedream 5.0, FLUX.2, Suno V5.5, ElevenLabs V3. The full catalog with pricing is on /models, and new releases land under the same request shape you already use.

As an async job. You submit, get a job id back immediately, then either poll the job endpoint or — better — receive a signed webhook when the render completes. Finished media is copied to INFRO storage under your account, so output URLs keep working instead of expiring when the upstream cleans up.

Yes, and that is what organizations are for. Invite members with roles (owner, admin, developer, analyst), give each member and project its own spend ceiling, restrict which models each project may call, and read the audit log for who changed what. SAML/OIDC sign-in with SCIM provisioning is part of an enterprise agreement rather than self-serve.

No, and we will not imply otherwise on a slide. A certification audits an operating history and the gateway does not have one yet, so there is nothing for an auditor to examine. What exists instead is published rather than promised: the security posture, the DPA with Standard Contractual Clauses, the subprocessor list, and the acceptable use policy, all on the site and readable before you contact anyone. Send your questionnaire anyway — we answer every question including the ones where the answer is not yet. If a certificate is a hard gate on your side, tell us at the start and we will say plainly that we cannot clear it today.

The list is published at /subprocessors, and a new subprocessor is announced 30 days before it begins processing. Infrastructure vendors are named outright. Model providers are listed by category and named under NDA — a DPA obliges us to disclose who processes data, while the product's whole design is that a customer never learns which upstream served a given request, and naming the pool publicly would undo that for everyone. The page explains the asymmetry rather than leaving you to notice it.

Yes, on an enterprise agreement: the subscription is invoiced quarterly or annually on your terms rather than charged to a card. That is an invoice for the software only. Model usage is invoiced to you by your own providers on whatever terms you already have with them, and no arrangement with INFRO changes that or puts it on an INFRO invoice.

You can, and plenty of teams do. It means three vendors, three dashboards, and the gaps between them — the router knows where a request went, the proxy knows what it looked like, and neither knows what it cost against your budget. INFRO is one layer doing the whole job: the request that was routed is the request that was traced, priced, and checked against your organization's policy. One integration, one place to look.