Model catalog

Status: draft source inventory. The catalog download contains four registered OpenAI snapshot identities checked against official documentation on October 30, 2026. Registration identifies the model version; it does not qualify a supplier or enable inference. CheapGPU has no public model-list API or available production model catalog yet.

Coverage

The catalog tracks OpenAI, Kimi, Anthropic, and BytePlus. OpenAI has the first source records; Kimi, Anthropic and BytePlus remain planned. This is a seed inventory, not a complete list of OpenAI models.

The initial records are GPT-6 Astra, GPT-6.1 Sol, GPT-6.1 Terra, and GPT-6 Luna. Each record links its capability/protocol sources and records their check date.

Model author or family, documentation provider, API family, supplier endpoint, and offer are separate concepts. BytePlus is tracked as a provider; its listing does not determine a model’s author. Suppliers serving the same model can map to its identity, but behavior-changing versions or quantizations require distinct revisions. A supplier mapping does not create or verify a platform model.

Identity and source fields

The catalog schema shares model identity and source fields. Task specifications, API families and measurement units retain their own semantics. coverage records which requested groups have data. Every model has these fields.

Field	Representation	Meaning
model_id	Namespaced string	Proposed stable platform identity
model_revision	String or null	Pinned revision; null means unresolved
catalog_state	candidate, registered or synthetic	Unresolved source, fixed identity or test example
registration	Required only for registered	Official provider snapshot or repository commit with file identities
author_id, family_id	Strings	Model origin and family
upstream	Object or null	Provider model ID, documented snapshots, lifecycle, capabilities, constraints and dated sources
input_modalities, output_modalities	Arrays	Documented model-level modalities
tasks	Array	Typed task specifications, documented API families, execution modes and platform profile references
billing_dimensions	Array of objects	Dimension IDs and their explicit measurement units

The four OpenAI records use the exact snapshot IDs documented on their official model pages, including IDs without a date suffix. A model ID and snapshot ID can be identical. The revision is the selected snapshot, not the source check date. Records with unresolved identity or profiles remain candidates and cannot be used in a complete supplier configuration.

Changing weights, tokenizer, quantization, or another behavior-affecting variant requires a distinct revision or model entry. A mutable alias cannot silently change the revision frozen into a trade. Alias and retirement policy still need definition before live discovery.

Registered model versions

A registered record can be selected in a complete supplier configuration. Each registration declares one proof kind; fields from different kinds cannot be mixed. Every declared profile must map to a recorded native API family.

For registration.kind: provider_snapshot, set provider_id: openai and snapshot_id to the exact published snapshot. The model revision must equal the snapshot ID, the upstream snapshot list must contain it, and the dated sources must include the official OpenAI page for that upstream model ID. The platform identity is openai/<upstream model ID>. This proof kind does not require public weight files, a repository commit or artifact hashes.

For example, the registered Sol identity uses:

{
  "model_id": "openai/gpt-6.1-sol",
  "model_revision": "gpt-6.1-sol",
  "registration": {
    "kind": "provider_snapshot",
    "provider_id": "openai",
    "snapshot_id": "gpt-6.1-sol"
  }
}

This identity excerpt is part of a complete catalog record. All four records declare openai-chat-text-v1-draft.1 and openai-responses-v1-draft.1. API-specific capability conditions still apply; registration does not establish support for every tool or every API field. Supply does not resolve an alias to a newer snapshot or switch versions when the selected snapshot is unavailable.

For registration.kind: huggingface_commit, set the official repository, its 40-character commit, and an artifacts list with unique relative path, role and lowercase SHA-256 for each file. Include weights, tokenizer and configuration artifacts. The revision is hf-<commit>; the repository must match upstream.model_id, the documented snapshot list must contain the commit, and dated sources must include the exact repository tree URL. Suppliers must serve the declared files; changed weights or tokenizers require a distinct version.

Registration and configuration do not prove that an endpoint uses those files or passes the profile. Endpoint conformance, supply eligibility, live traffic and supplier offers retain their separate requirements. Prices come only from supplier offers. Candidate and synthetic records cannot complete a formal supplier configuration.

Task specifications and native interfaces

A model can have multiple tasks. Each task has one task_type, its own specification, documented upstream_interfaces and declared platform api_profiles. API family names identify source interfaces; they are not executable profile IDs or evidence of CheapGPU support. Each interface records its own execution_modes; null means the modes still need verification. The source records list modes established by endpoint-specific guidance. An unlisted mode remains unverified; the list is not a claim that every other mode is unsupported. Do not infer an endpoint/streaming combination from a model-level feature.

Each interface also requires capability_support. Each entry names a capability, its support (supported, unsupported or conditional) and conditions. An omitted capability is unverified. An empty list records no assessed capability for that API family; it does not inherit the model-level capability list.

A conditional entry requires every condition to match. field is a native JSON Pointer, and values lists its allowed string, Boolean or null values. Missing fields do not match, and null remains distinct from omission. The check reads the request without adding defaults or rewriting fields. Non-conditional entries have no conditions. These are documented source claims, not payload validation, supplier conformance results or execution authority.

Verified OpenAI scope

The October 29 check confirms a 1,050,000-token context window, 922,000-token input limit and 128,000-token output limit for all four candidates. They accept text/image input and produce text output. Their API-specific function constraints are distinct:

Model	Reasoning efforts	Responses functions	Chat Completions functions
GPT-6 Astra	low, medium, high, xhigh, max	Supported	Unsupported
GPT-6.1 Sol	low, medium, high, xhigh, max	Supported	Unsupported
GPT-6.1 Terra	none, low, medium, high, xhigh, max	Supported	Unsupported
GPT-6 Luna	none, low, medium, high, xhigh, max	Supported	Explicit reasoning_effort: "none"

Luna’s conditional source declaration uses field: "/reasoning_effort" with values: ["none"]. Omission, null or another effort does not satisfy it. The reasoning guide and model pages establish these restrictions; they do not authorize translating Chat requests to Responses.

The catalog also records the published models’ Responses hosted tools. CheapGPU’s hosted tool contracts and runtime support remain incomplete. Batch is an asynchronous API family whose inner request endpoint needs its own validation; the catalog does not infer Batch function support from the underlying model. Astra’s background mode is documented separately from ordinary streaming.

The checked snapshot identifiers still match the provider model IDs. Their names and retrieval date do not supply the missing immutable revision evidence. model_revision remains null and api_profiles stays empty for these candidates. The source check therefore prepares qualification without claiming that any real supplier or production model has passed it.

The metadata schema defines two task types.

Task type	Specification	Example execution modes
language_generation	Context/input/output token limits, reasoning efforts and Structured Outputs constraint scope	request_response, streaming
video_generation	Duration range, resolutions, frame rates and audio output	async_task

A language specification requires structured_output_constraints, with value openai_base, openai_fine_tuned or null. This records which documented Structured Outputs field constraints apply; it does not grant profile eligibility. Null means unverified. The four published OpenAI candidates are source-checked openai_base models: their model pages do not support fine-tuning, and the Structured Outputs guide defines their base-model constraints. This dated classification does not qualify a supplier or establish an immutable revision. The synthetic catalog separately exercises base and fine-tuned scope. Never infer the class at runtime from a model name, supplier claim or request field.

The example execution modes describe declared interfaces, not defaults inferred from task type. Video limits can be null when unknown. A video record does not need a language-model token context. Other task types need their own typed specifications; do not give them invented language limits to fit the catalog.

Buyers select a defined profile for the API family they use. OpenAI Chat Completions, OpenAI Responses, Anthropic Messages and video task APIs retain their request, response and execution semantics. Suppliers select the shared profiles they implement and qualify separately for each model/task/profile. The platform handles each profile rather than building individual supplier adapters. The catalog does not translate requests or select a different API when an input is unsupported.

The synthetic catalog example contains an invented video model using example.video_tasks and async_task. Its limits demonstrate the format; they are not Seedance facts or a defined video inference API. A complete asynchronous profile must separately define creation, status reads, results, cancellation, errors and ownership.

Model capabilities and platform gaps

upstream.capabilities records model-level facts from provider documentation. Each task’s upstream_interfaces lists documented endpoint families. Their combination does not mean every feature works on every endpoint: apply constraints and verify the chosen API/profile. For example, Sol and Terra require Responses for function calling; Luna’s Chat Completions function calling requires reasoning_effort=none.

The native Responses draft defines stateless functions, reasoning controls, structured output, inline image input, typed streaming and source usage relationships. It has offline validation examples; hosted runtime availability and real supplier qualification remain capability gaps. Stateful operations, hosted tools and broader schema/image modes need additional contracts. These gaps are not intended product restrictions. The existing text-only Chat profile does not define the product’s final capability scope. See API profiles for current contract status. Video task APIs and their checker/Gateway integration also remain incomplete.

Recording an upstream capability does not advertise it as a CheapGPU feature. Until its contract, implementation and supplier qualification are verified, unsupported requests must fail explicitly. Gateway cannot drop parameters, switch protocols, or substitute another model.

Supplier-owned pricing

All model and inference prices come from supplier offers. The model catalog contains no official, list or reference prices, comparison baselines or price sources. CheapGPU does not scrape, poll, schedule updates for, or manually maintain upstream prices. Provider documentation supplies capability and API facts only.

The catalog’s billing_dimensions name measurement dimensions and units: token, second, image, frame or request. These definitions contain no rates. Supplier offers and their immutable quote versions supply exact prices, quantities, currencies and applicable conditions. Buyer limits constrain an offer; they do not supply a price. When no eligible supplier quote exists, price is unavailable. The platform does not substitute an official rate, an estimate or zero.

Admission and settlement use the accepted supplier terms and existing billing rules. This boundary does not change commission, rounding, usage relationships or already accepted transactions. Overlapping usage dimensions still require a verified profile-specific mapping.

Supplier mappings and availability

A binding contains a platform model and revision, supplier_model_id, profile_id, and declared capabilities. Requests and responses use the same supplier model ID. The synthetic catalog example uses separate invented Chat and Responses models to validate that relationship, and a video model to validate task and measurement metadata. They are separate from the real source inventory and are never offered models.

Matching requires the requested revision, profile, supported parameters and capabilities, a current conformance result, an eligible live offer, capacity, and buyer price/budget limits. Catalog presence alone establishes none of these. Actual availability belongs to Backend’s current supplier and offer state; it must not be inferred from these static source records.

Remaining catalog work

Add source-checked Kimi, Anthropic, and BytePlus records using the same format. Define immutable identity evidence, aliases, retirement and live discovery before enabling a model-list API. Connect a qualified model and offer through inference and wallet finalization with separate implementation and acceptance evidence. Model quality and supplier comparison signals remain separate from identity and availability.

Synthetic capability declarations

The synthetic Responses examples explicitly declare their four native capabilities and foreground, streaming and background modes. These invented declarations exercise the catalog format; they do not qualify any real model or supplier. Missing capability claims or modes remain unverified. A check for one model, API profile or set of native conditions does not establish support for another.