Models

List the models your key can use with either shape:

curl https://api.topbilling.in/v1/models -H "Authorization: Bearer $TB_API_KEY"

Each entry carries id, display_name, context_window and max_output_tokens. The public Model Square adds capabilities and live availability.

Capabilities

A model advertises what it supports: chat, streaming, tool_calling, vision, reasoning, prompt_caching, token_counting. Sending a feature the model lacks returns 400 with code: capability_not_supported and the offending param, and reserves nothing.

Naming

IDs look like tb-… and are stable for as long as the model is offered. Top Billing may switch the upstream behind an ID; your prices and capabilities only change through a published pricing version or a model page update.

Aliases

A project can give a model its own name — for example my-coder — and list up to four models behind it, in order. Create aliases under API keys; every key on the project can then send "model": "my-coder".

• The request goes to the first model. Only if it fails before any output is sent — a provider error, a timeout, an overload or a 429/5xx — does it move to the next. A request that has started answering is never switched.
• You pay once, at the price of the model that answered. The credit held while the request runs covers the most expensive model in the alias.
• The response reports the alias as its model; Usage shows which model answered.
• Aliases appear in GET /v1/models for keys of the project. They cannot start with tb-, so they never hide a public model.

Switch an alias to another model and every client follows on its next request, with no code change.