Provider disclosure in a multi-provider AI router
In a multi-provider AI router, provider disclosure means naming who will process a generation at quote time—before credits move—alongside subprocessors, retention boundaries, and route-attempt records.
AI router provider disclosure is the act of naming who will process one image or video generation before that job is submitted—not after the fact, and not only as a static legal catalog. In a multi-provider router the public model ID can stay fixed while the inference route changes. Trust therefore depends on whether the selected provider is visible at quote time, whether subprocessors and retention boundaries are linked honestly, and whether route attempts leave an auditable record.
OfflineCreator’s documented AI Router states that cloud generation discloses the selected provider before submission, and that Studio, REST API, CLI, and MCP share the same provider disclosures. A signed quote records the selected route with options, rate card, credit charge, and expiry before credits move. That is selection-time disclosure: the buyer sees the route envelope they are about to approve.
Adjacent industry patterns show why the timing matters. Aggregators such as OpenRouter describe themselves as gateways to third-party model-provider APIs governed by those providers’ Model Terms. Independent commentary on routing substitution warns that without in-band identity, buyers can lose the chain from requested model to served weights. Those external patterns reinforce the disclosure question; they do not transfer another product’s privacy, retention, or availability promises onto OfflineCreator.
- Disclose at selection
- Before submissionName the selected provider while the quote is still rejectable.
- Keep the catalog separate
- Catalog vs this route/cloud-ai-providers owns the full launch catalog; this URL owns timing at selection.
- Record the attempt
- Route-attempt rowsPersist provider identity with request ID and quote linkage for reconciliation.
Failure mode: a catalog page mistaken for selection-time disclosure
The common trust failure is treating a provider directory as if it answered the selection-time question. A catalog can list who is admitted to a launch set without telling you which route a router will pick for this request, whether that choice is locked into the quote, or whether an alternate attempt after failure is recorded against the same approved charge. Buyers then approve credits while the inference hop remains anonymous until after the fact.
MarkTechPost’s July 2026 analysis of model-identity fracture under routing makes the same structural point from the outside: some systems notify the served model in-band, others publish routing rules without per-task assignment, and aggregator documentation can warn about quantized or substituted serving that logs may not surface. OfflineCreator’s separation of concerns is deliberate. The complete launch catalog and supplier checklist live on /cloud-ai-providers. This URL owns disclosure at route selection—when the selected provider is shown before submission and bound into the signed quote—while LocalForge remains the separate offline path when inputs cannot leave the machine.
- Wrong surface
- Catalog ≠ this quoteA launch list does not by itself prove which provider will run the next job.
- Identity risk
- Substitution without noticeExternal commentary flags routers that change served identity without clear in-band disclosure.
- Scope boundary
- Selection-time ownershipThis page owns timing at selection; /cloud-ai-providers owns the complete catalog.
Selected-provider disclosure, quote timing, subprocessors, retention, and attempt records
Treat the evidence requirement as five checks that fail independently. Selected-provider disclosure asks whether the buyer can see which cloud provider will run the approved job. Quote timing asks whether that identity is bound into the signed quote before credits reserve. Subprocessors ask which other processors handle account, billing, hosting, or generation data outside the inference hop. Retention boundaries ask how long generation history, temporary uploads, and audit logs are kept under the published privacy policy. Route-attempt records ask whether each submit or failover attempt stores enough metadata to reconcile what happened.
OfflineCreator’s live cloud provider disclosure states that Studio sends generation inputs to the provider serving the selected model and that the current launch catalog is routed through fal. The same page’s supplier admission checklist includes reviewing data-retention and training terms. The Privacy Policy names fal.ai for generation processing, lists Stripe, Supabase, Cloudflare, and Google among other service providers, and publishes retention windows for generation history, temporary uploads, and sampled security logs. Tracked multi-provider routing notes reviewed August 8, 2026 add the operational half: the selected provider and attempt are persisted around submission, polling stays sticky to the provider request ID, and every attempt stores route, request ID, quote, actual cost, latency, status, and sanitized error metadata.
Do not invent stronger promises than those pages state. The live catalog currently discloses fal for launch models; managed alternate routes described in internal routing notes are not treated here as anonymously confirmed live production availability for every account. Retention figures are the published OfflineCreator boundaries—not a claim about how long every upstream model provider keeps copies under their own terms.
- Selected-provider disclosure
- Named before submitOfflineCreator documents disclosure of the selected provider before submission.
- Quote timing
- Signed route envelopeThe quote records selected route and charge before credits move.
- Subprocessors
- Generation plus platformPrivacy Policy lists fal.ai for generation and other services for billing, auth, and hosting.
- Retention boundaries
- Published windowsGeneration history, temporary uploads, and audit-log windows are stated on /privacy.
- Route-attempt records
- Sticky request IDsEach attempt stores route, quote, latency, status, and sanitized errors.
Where to go next
If you need the broader product overview—stable model IDs, Kayak-style booking language, and the full router narrative—use the parent AI Router page. Keep this URL focused on provider disclosure at route selection for the query “ai router provider disclosure.”
If you need the complete launch catalog and supplier admission checklist, open cloud provider disclosures. If an agent must request the same disclosed path through MCP, continue to AI routing with MCP. If you need a single API surface for generation while disclosure stays attached, continue to the unified AI generation API.
Canonical ownership and evidence boundary
This URL owns disclosure at route selection for “ai router provider disclosure,” including selected-provider visibility, quote timing, how subprocessors and retention boundaries attach to a routed generation, and route-attempt record expectations. It does not own the complete provider disclosure catalog on /cloud-ai-providers, retail pricing merchandising, or competitor win/loss claims. The parent /ai-router hub owns the broader AI generation router overview.
Supported product statements are limited to OfflineCreator’s documented router behavior, live cloud provider disclosure, and published Privacy Policy. Supported external statements are limited to MarkTechPost’s July 2026 model-identity analysis and OpenRouter’s published Terms describing third-party model-provider access. This draft does not assert that every managed alternate route is anonymously live, does not invent retention promises for upstream model providers, and does not claim measured privacy, reliability, or customer outcomes.