How OfflineCreator verifies model names and versions

Treat “current in Studio” and “newest from the vendor” as different questions

OfflineCreator verifies the model that Studio can call, not every model a vendor has announced. Retrievable public evidence answers separate questions: the Studio model page lists six display names, workflows, and credit costs; the provider disclosure says the launch catalog is routed through fal; and the MCP page says a configured client can inspect available models. The public catalog's display rows do not, by themselves, prove a provider route or a client-facing model ID.

Those checks support a narrow statement: these are the displayed Studio entries and disclosed routing facts at the check date. They do not prove that each entry is the newest model in its vendor's entire portfolio. For example, fal's FLUX 1.1 Pro Ultra page calls that endpoint the newest version of FLUX1.1 Pro, but the scope of that wording is the provider page and its named family. A newer public FLUX family, preview, or unrelated endpoint would not silently change the model currently exposed by Studio.

Compare the provider schema without importing it into MCP

Endpoint identity is only half of a freshness check. Open the provider's current schema and compare its required fields, enums, and defaults with the Studio adapter and published MCP schema. The fal pages currently expose route-specific controls: FLUX Schnell documents image-size presets, inference steps, seed, and output format; FLUX Pro Ultra documents a broader aspect-ratio list and other API options; Recraft V3 documents image size and style; Veo 3.1 Fast documents resolution, duration, aspect ratio, and audio controls.

Those fields describe direct fal APIs. They are not promises that OfflineCreator MCP accepts the same inputs. Published MCP 0.1.1 exposes `list_models`, requires `generate.modelId` to come from that catalog, and limits the generation request's aspect-ratio enum to `16:9`, `9:16`, or `1:1`. A provider schema can remain valid while the Studio adapter deliberately exposes a smaller surface. Verification therefore records both schemas and avoids copying a provider-only field into an MCP request.

Run the monthly verification in a fixed order

Start with the retrievable public Studio catalog and record every displayed launch entry's name, workflow, and credit cost. Read the provider disclosure separately for routing. Then open each exact fal endpoint page and compare its heading and current input schema. Finally, compare the published MCP release and tool schema so the documented client-facing example and accepted request fields remain explicit. Do not infer an unpublished Studio-ID-to-endpoint mapping from matching family names.

Record the access date, evidence URLs, mismatches, and the next expiration date. This research uses a monthly cadence: the product claims checked on August 9, 2026 expire on September 8, 2026 unless they are reverified earlier. A mismatch should block a “current” claim until the source of truth is reconciled; it should not be explained away by choosing the most convenient label. Authenticated production calls are outside this research boundary, so an operator should also run `list_models` before a consequential generation.

Monthly evidence set

Public catalog + provider disclosure + provider schema + published MCP schemaPreserve exact URLs and the check date; do not rely on screenshots or search snippets alone.

Recognize the stale-name failure mode before generation

Suppose a brief asks for “the latest FLUX.” Choosing `flux-pro` because its display name contains “1.1 Pro Ultra” answers a different question: which configured Studio entry has that name. The correct decision path is to ask whether the brief needs the newest public vendor family or a supported Studio route. If it needs Studio, select from the current catalog. If it needs a specific public release that is absent, report that gap rather than substituting the nearest family name.

A second failure occurs when an endpoint evolves but an old integration note survives. Confirm the provider endpoint on its current API page before diagnosing payload errors, then compare accepted MCP inputs with direct-provider inputs. This separates three causes that otherwise look alike: a stale display label, a changed provider route, or an unsupported provider-only parameter. None of these can be resolved reliably from a marketing family name alone.

Evidence boundary and next actions

A version record is current only while its retrievable evidence still agrees. Compare the public Studio display, the separately disclosed provider route, the provider's exact endpoint page, and the published MCP interface. If one layer differs, label the mismatch and stop short of claiming that a copied identifier is current. Public display names are useful for readers, but they are not substitutes for a live client-facing model ID or a provider endpoint.

No retrievable ledger source, public permalink, or content hash currently substantiates the internal Studio-ID-to-endpoint mapping required by this page. This researched draft therefore does not assert that mapping. Under the page's overlap guard, that unavailable evidence should consolidate into the parent model guide hub until a retrievable source exists. Use the endpoint-identifiers guide for provider identifiers, and confirm the live Studio ID with `list_models` before generation.