Guide
Model Marketplace and Billing
Choose models, understand price cards, and confirm capabilities and availability
Model Marketplace and Billing
The model marketplace is the entry point for choosing models and understanding call pricing, and shows the catalog of models the platform currently makes publicly available. The actual callable range is still determined by the calling group the API key belongs to and by real-time availability.
How to choose a model
- Search by name, or filter by model brand, capability, and endpoint type;
- Open the details and confirm the supported endpoints, available groups, and price type;
- Use
GET /v1/modelsto confirm the model IDs visible to this key; - Use the returned model ID in your business backend to make requests.
Model catalog fields
GET /v1/models returns the models the current key can call. The fields are described below:
| Field | Type | Description |
|---|---|---|
data[].id | string | Model ID; enter it as-is when submitting requests |
data[].object | string | Always model |
data[].created | integer | Catalog record time (Unix seconds) |
data[].owned_by | string | Provider identifier of the model, for reference only |
data[].supported_endpoint_types | string[] | Endpoint types available for this model |
The model catalog is only for confirming "whether this key can call this model". Specific parameter limits (number of reference images, input video specifications, output duration and resolution, etc.) are governed by the model details page and by the parameter errors returned by the API. The platform does not guess parameters on the model's behalf, and does not silently degrade unsupported parameters.
How to read the price card
| Display | Meaning |
|---|---|
| Input / Output | Billed separately for input and output tokens; the unit is shown as 1K or 1M tokens. |
| Cached input / Cache write | Shown only for models that support prompt caching. |
| Per call | Each successful request is billed at a fixed price. |
| Video usage-based billing | Video models are shown at the currently effective price; resolutions, durations, or modes without a price are not shown. |
Price displays are for estimation; actual charges are based on the request's actual usage, the group the request belongs to, and the server-side billing records.
Video models
The doubao-seedance and seedance series display a separate price matrix, split by "whether video input is included" and "output resolution"; supported cells show the video cost, and unsupported combinations explicitly show "Not supported".
When reading the matrix, first determine whether this request submits video input, then choose the resolution you need. For example, when you upload only text or an image reference, look at the "Without video input" column; when you submit a video as input, look at the "With video input" column. Do not infer unshown prices or capabilities from adjacent tiers.
Before calling, confirm:
- The model ID appears in your
/v1/modelsresponse; - The request uses the video endpoint
/v1/video/generations, not the text endpoint; - Reference images or reference videos meet the model's public parameter requirements;
- Your backend saves and polls the returned task ID for async tasks.
Asset references and models
Asset ingestion is independent of models: an asset only needs to be ingested once, and the platform prepares the corresponding asset reference for the current model. The same asset ID can be switched directly between models; switching models only requires changing the model field in the request.
For which models share the same asset library, and which models support portrait assets, see Asset Library API Overview.
Billing and statements
The model marketplace shows price descriptions, which are not equal to the final settlement amount. Text models are usually settled by actual input, output, and cache usage; image, audio, or video models may be settled per call, per duration, or per model-defined billing unit.
Async tasks such as video are settled on completion: a successful submission only accepts the task and does not pre-charge; after the task completes, only one actual charge record appears in the bill. Before submission, the platform checks whether the account balance (or the current API key's quota) covers the estimate for this call; if not, it returns a readable message directly and does not create the task. After the task completes, you can verify the model, time, request ID, and actual charge in the wallet or usage records.
A parameter validation failure (HTTP 400) means the request was not accepted and usually does not generate a generation task charge; billing, failure, and refund rules after a task ID has been returned follow that model's and the platform's price configuration.
Availability changes
If a model card is not shown or a model does not exist in /v1/models, it currently does not belong to this key's available catalog; switch to a similar model, and do not hard-code names of unavailable models in your client.
"No available channel" and "model temporarily unavailable" mean the model cannot be routed at this time; they do not mean the API key format is wrong. First refresh the model list or switch to a similar model; if it remains unavailable, contact platform support and provide the request ID.