Serverless Model Catalog: Available Models and Capabilities
How to discover customer-visible serverless models and validate capabilities before sending requests.
By Hostnot GPU ·
A model catalog is a configuration dependency, not a static leaderboard. A public name can remain familiar while availability, pricing or serving constraints change. Hostnot GPU clients should discover the current public identifier and then intersect the catalog information with the endpoint's accepted request fields.
What discovery actually returns
Call GET https://serverless.hostnotgpu.ae/v1/models with a bearer key granting pricing:read. The response is {"data":[...]}. Each row exposes id, name, author, modality, context_length and pricing. The ID is the public model slug used in generation, not an upstream infrastructure identifier.
An optional modality query filters rows. This handler does not implement pagination: adding cursor, offset or limit parameters does not create a page protocol. Parse the returned array defensively, and distinguish an empty valid result from a failed discovery request. See model discovery documentation for the customer workflow.
Catalog metadata is not a complete capability schema
The current response does not publish per-model booleans for tools, JSON-schema output or streaming. Do not write feature detection against invented fields. A model card might describe a capability that the public platform endpoint does not accept. For example, current chat accepts string messages with system, user or assistant roles, an optional temperature, an output token limit and stream: false; strict validation rejects extra fields.
Context length is also different from a per-message character bound. The chat handler permits at most 100 messages and 50,000 characters per message, but a model's usable token window can be more restrictive. Set input policy with the model's tokenizer guidance and reserve room for output; a schema-valid prompt need not fit the model.
Pin identity, refresh operational data
- Record the intended public model ID, task and accepted request schema in application configuration.
- Cache discovery for a bounded period suitable for your application; retain when it was fetched, without presenting it as a capacity reservation.
- On model-not-found or pricing conflict, refresh once and surface a configuration decision if the selection is unavailable.
- Require an explicit tested change to switch models: a replacement can alter license, quality, tokenization and response behavior.
Do not silently fall back to the first row. Displayed pricing may have different units across modalities, and a null or absent context value is unknown rather than unlimited. Keep provider routing and secrets outside browser configuration.
Validate a candidate without overstating discovery
A discovery GET does not run inference. Once generation is authorized, use a small representative task to check the normalized response, output quality, error behavior and billing fields. Image and video schemas differ from chat, and video currently does not use the normalized chat/image response wrapper. Build separate parsers rather than coercing all results into text. Follow the endpoint guide and the compatibility checklist when implementing the adapter.