Models

Browse the models your platform has deployed, compare their capabilities and prices, and jump straight into the Playground.

Running Models Only

The Models page (titled "Running Models" in the UI) displays only models that have active deployments. If a model is not currently deployed, it will not appear in the list. Contact your platform administrator to request deployment of additional models.

Model Catalog

The catalog offers a grid view (default) and a list view. Use the toggle beside the search box to switch between them. Search models... filters on name, description and type as you type.

There are no other filters, sort controls or pages: everything your tenant can reach is on one screen. Export Excel downloads the catalog if you need it outside the portal.

In list view, each row carries:

Column	Description
Model	Name, description and capability badges
Status	Deployment state
Pricing	The effective rate, in the unit that applies to the model type
Type	What the model does
Action	View Details and Playground

Which models you see

Your catalog holds two kinds of model:

• Public models, available to every organization on the platform.
• Private models, which appear only for the organizations your operator has granted them to. One private model can be granted to several organizations at once.

A model you have not been granted is simply not in your catalog: it is absent from the list, and calling it directly returns 403 Forbidden. Grants and revocations take effect immediately — a model withdrawn from your organization stops appearing and stops answering on the next request, with no waiting period.

Every catalog read applies that same rule. The Models page, GET /v1/models, GET /api/v1/models and the model detail endpoints all return your organization's own models, the models granted to your organization, and public models, and nothing else.

Asking for a model you cannot see is answered exactly like asking for a model that does not exist: GET /v1/models/{model_id} replies with the ordinary 404 Model '{model_id}' not found. A 404 there means only "not in your catalog", and tells you nothing about whether any model of that name exists elsewhere on the platform. A private model that has been granted to your organization is served normally, whether you address it by its name or by its Model ID.

The detail page states whether a model is public or private under Specifications. To have a private model granted to you, contact your platform administrator.

Model Logos

Models are shown with their brand's logo rather than a generic type icon. The logo is rendered everywhere a model is identified: the catalog grid, the catalog list rows, the model detail header, the Playground model picker and the ⌘K search palette.

Not every model has one. Where a logo is missing, the previous type icon or the model's monogram is drawn instead, so a model without a logo still renders exactly as it always has.

Capability Badges

Each model shows its first two capabilities as badges. When there are more, a +N control follows them, labelled "Show {count} more capabilities" for screen readers.

The overflow opens on hover or keyboard focus, and a click pins it open so you can read it without holding the pointer still; click again to close. It also closes on Escape, a click outside, or any scroll or window resize.

The model detail page has no overflow: it lists every capability as a chip under Capabilities.

Status

Pill	Meaning
Running	Deployed and available for inference
Ready	Deployed and ready to serve
Updating	The deployment is being rolled out, scaled, or is still pending

An Updating model cannot be opened in the Playground; its tooltip reads "This model is being updated. Try again in a moment." Try again once the rollout settles.

Every model on this page is deployed. If a model is missing from the list, it is not currently deployed, so contact your platform administrator to request it.

Retiring Models

A model on its way out carries a second, amber chip beside its status pill rather than in place of it: Retiring, or Retiring · 41 days left once a retirement date has been set. The status pill still reads Running, because a retiring model keeps serving every request exactly as before, right up to its retirement date.

Underneath the chip, the catalog states the two facts that matter:

• "Retires on {date}." — the retirement date, always shown in UTC, or "A retirement date has not been set yet." when the model has been announced but no date has been fixed. Where there is no date, no countdown is shown at all.
• "Use model-name instead." — the successor to move to. Where there is deliberately no successor, a short note from your operator says so instead.

The countdown is rounded down, so a model with 30 hours left reads 1 day left, never 2.

Both the grid and the list view carry the chip, and so does the Playground model picker — on the palette row and on the resting model card — and so does the model's own detail page. A model is chosen with its deadline in view wherever you meet it, including on a deep link or a search result that lands straight on the detail page without passing the catalog first.

The banner

When your organization has actually called a retiring model in the last 30 days, a banner appears at the top of the Models page naming each affected model, its date and its successor, with a link to the deprecation policy. It is deliberately not shown to organizations that have never called the model: a banner everyone sees is a banner nobody reads.

What happens on the retirement date

A retiring model stays in the catalog and serves every request as usual until its retirement date. After that date it leaves the catalog, and a request naming it is refused with 410 Gone and the successor named in the reply. Switching before the date is up to you — see Model Deprecation.

Your operator also emails every organization that is calling a retiring model, at up to five points: on announcement, then 30 days, 7 days and 1 day before retirement, and once more on the retirement day itself. Each notice names the model, the retirement date, the successor or the operator's note, and — where the figures are available — your own request and token volume on that model. Nothing is sent until a retirement date has been set.

Availability

A model can be in your catalog, deployed, and still be unable to serve for a while — most often because the provider behind it is refusing requests. The platform checks this continuously and stops sending traffic to a model it has judged not to be serving.

A model in that state is not removed from your catalog. It keeps its place in the list, keeps its grants, its pricing and its Model ID, and it is still returned by GET /v1/models. Catalog membership is a durable fact; whether the model is answering right now is not, and the two are reported separately.

Each entry in the model list carries an is_serviceable field:

Value	Meaning
true	The model is answering and is being served normally
false	The model has been judged not to be serving; requests to it are refused
null	Not known, or not applicable — models served on the platform's own infrastructure report null

A request to a model marked false is refused before it is forwarded, with 503 and error.code model_unavailable, plus a Retry-After header. Nothing is billed, and the error text names only the model — never the provider or the reason. See Error Handling for how to tell that refusal apart from an upstream failure.

A model that is merely slow is still served. Only a model judged not to be serving at all is refused, so a provider working through a queue does not cost you access to the model.

Recovery is automatic. Once the model starts answering again, the platform resumes serving it on the next check — there is nothing to re-request and no grant to restore. If the check itself has not run recently enough to be trusted, the model is served rather than refused: the platform does not gate on a stale verdict.

The Status pill is not the same thing

The Status column above reports the deployment, so a model can read Running on this page while is_serviceable is false. If you are choosing a model programmatically, branch on is_serviceable, not on the status.

Separately, a model can no longer be registered against a provider identifier that the provider does not actually offer — registration is refused at the point an operator adds it. That is an operator-side action, but the effect for you is fewer catalog entries that would only ever have failed at the provider.

Model Details

Click any model, or View Details, to open its page. It has four sections:

Where the model is on its way out, the Retiring chip sits beside its status pill here too, with the retirement date and the successor underneath — the same marking, and the same rules, as in the catalog. See Retiring Models.

Specifications

Context window, estimated VRAM, disk size, whether the model is public or private, and the Model ID, which is the identifier you pass as model in API requests. Click it to copy.

Capabilities

Every capability the model declares, listed in full.

API Usage

The endpoint this model is called on, so you can see at a glance whether it belongs on /v1/chat/completions, /v1/embeddings, /v1/images/generations, /v1/audio/transcriptions or /v1/audio/speech.

Pricing

The model's rate, in the unit that applies to its type. See Pricing below.

Try in Playground

A Try in Playground button opens the Playground with this model already selected. There is no dropdown to pick from; the button carries the model with it.

Model types that have no Playground surface (embeddings, for example) show the button disabled with the tooltip "This model type has no Playground surface yet". Call those models directly from the API.

Model Types

Chat Models

Designed for conversational interactions:

• Accept message arrays
• Support system prompts
• Maintain conversation context

Use your-chat-model with /v1/chat/completions. See Streaming for token-by-token responses.

Completion Models

Text completion without conversation structure:

• Accept text prompts
• Generate continuations
• No message roles

Embedding Models

Generate vector representations:

• Convert text to vectors
• Used for semantic search and retrieval
• Fixed dimension output

Use your-embedding-model with /v1/embeddings. Embedding models have no Playground surface.

Image Generation Models

Generate images from a text prompt:

• Accept a prompt, size, and diffusion settings
• Return one or more images per request

Use your-image-model with /v1/images/generations. See the Image Generation guide.

Speech-to-Text Models

Turn recordings into text:

• Accept audio uploads over the transcription and translation endpoints
• Return plain text, timed segments, or subtitle files
• Some also support realtime streaming over a WebSocket
• Priced by the length of the input audio rather than per token

Use your-speech-model with /v1/audio/transcriptions. See the Speech to Text guide and Realtime Transcription.

Text-to-Speech Models

Turn text into spoken audio:

• Accept text, a voice, an output format, and a speaking speed
• Return an audio file
• Priced by the length of the input text rather than per token

Use your-tts-model with /v1/audio/speech. See the Text to Speech guide.

Each text-to-speech model publishes the voices, output formats and speed support it offers, and the catalog reflects what that model declares. A voice outside the published list is rejected at request time, so read the voice list from the model's page rather than assuming a name.

Pricing

Prices are shown per model, in the unit that matches how the model is metered.

Token Models

Chat, completion and embedding models are priced per token. The portal renders those rates as USD per 1M tokens, separately for input, cached input and output. Output tokens are usually the most expensive.

note

The portal displays a per-million figure for readability. The API payload expresses the same price per single token. The two describe the same rate; only the scale differs.

Speech-to-Text

Speech-to-text is metered per second of input audio, rounded up. The catalog usually displays a per-minute figure because it reads better, but the billing unit is the second: a 90-second recording is billed as 90 seconds, not as two minutes.

Some models also carry a minimum billed duration, so that very short clips still cover the cost of a request. Where one is set, the list shows "min {n}s billed" next to the price and the detail page states "Minimum {n} seconds billed per request".

The length of the transcript has no effect on the price; only the input audio counts.

Text-to-Speech

Text-to-speech is billed on the text you send, priced per 1,000,000 characters, with a cap of 4096 characters per request. The duration of the audio that comes back does not change the price.

Free and Unavailable Prices

• A model your operator has declared free shows Free in place of a rate. A rate that merely happens to be 0.00 is not the same thing and is not labelled Free.
• An amber Price unavailable means a per-use model came back without a price. That is a data problem rather than a free model. The detail page says so explicitly and asks you to contact support before using it.

Negotiated Rates

When your organization has a rate below list price, the list price appears struck through immediately before the price you actually pay (screen readers announce it as "List price"). The model's detail page also shows a Your negotiated rate badge on the pricing card.

What Is and Is Not Billed

• Only successful requests are billed. Requests that fail with a server-side error are recorded in your usage history for visibility and carry no charge.
• Audio usage holds no plan quota. It is billed separately from token usage and is not drawn from a plan's included tokens or from a commitment allowance in either direction.

Your effective rates and current spend are on the Usage and Billing pages.

Using Models

In the API

Use the Model ID from the detail page:

response = client.chat.completions.create(
    model="your-chat-model",
    messages=[...]
)

GET /v1/models returns the same identifiers programmatically, together with each model's is_serviceable flag — see Availability.

Serving Region

Where an operator has recorded it, a model carries a region: one uppercase ISO 3166-1 alpha-2 code naming the jurisdiction the model is served from, such as TR, DE or US. EU is also a valid value, for a model an operator can only place inside the Union.

It is a single value, not a list, and it is optional: a model with no recorded region carries no region key at all on GET /v1/models — never null, never an empty string. Branch on the key being present.

In the portal, the region is shown in the Playground model picker and on the selected-model card, as a flag and the code, labelled "Region: {code}" for screen readers. A model with no region shows nothing there — no placeholder and no dash.

Retirement Fields in the API

A model being retired carries up to five extra fields on GET /v1/models and GET /v1/models/{model_id}:

Field	Description
deprecated_at	ISO-8601 UTC timestamp: when the retirement was announced
sunset_at	ISO-8601 UTC timestamp: when the model stops serving. Never earlier than deprecated_at
replacement_model_id	The successor's catalog id
replacement_model_name	The successor's model name — the string you would put in model. Use this one; it is resolved for you
replacement_note	Used instead of a successor, when there deliberately is none

Branch on presence, not on null

Each of the five is omitted entirely when it is not set. A model that is not being retired carries none of them. A null meaning "not being retired" and a null meaning "being retired, no date fixed yet" would be two facts and one value, so neither is ever sent — test for the key, not for a truthy value.

deprecated_at without sunset_at is a legitimate, expected state: announced, date not yet fixed. The model keeps serving and is never refused while it is in that state.

Once the retirement date passes, the model drops out of GET /v1/models at the same instant the inference endpoints begin refusing it, so a model you can read out of the listing is never one the next request would reject. See Model Deprecation for the headers and the refusal.

Logos in the API

Each entry in the model list carries the fields needed to render its logo yourself:

Field	Description
logo_url	Path to the logo bytes, already carrying a version parameter so you can cache it aggressively
logo_source	Whether the logo comes from the model's brand or from a model-specific override
logo_updated_at	When the logo last changed
brand	A summary of the model's brand: its name and website

The bytes themselves are served by:

curl https://api.bulutistan.ai/api/v1/models/{model_id}/logo

This endpoint is anonymous — no Authorization header — because a browser <img> tag cannot send one. Only the logo bytes are open in this way: GET /api/v1/models and GET /api/v1/models/{model_id} still require authentication. Responses carry a long cache lifetime and an ETag, so replaying the tag as If-None-Match answers 304 Not Modified.

The logo endpoint lives on /api/v1 only

GET /v1/models/{model_id}/logo returns 404, even though /v1/models works. Build logo URLs from the logo_url field rather than by appending /logo to a /v1 path.

A 404 from the logo endpoint means one of two things

A model that has no logo and a model your organization cannot see both answer 404, and the two are deliberately indistinguishable. Treat a 404 as "no image to show" and fall back to your own placeholder.

In the Playground

Open the model's detail page and click Try in Playground, or open the Playground and pick the model from the picker. The Playground chooses its surface from the model's type, so a speech-to-text model lands you on the audio workspace and an image model on the image workspace.

Model Selection Guide

The catalog is per-platform, so pick by capability rather than by a fixed name. The Models page shows each model's type, capabilities, context window and price, which is everything this table asks you to weigh.

Use Case	What to look for
General chat	A chat model with a moderate context window and the lowest per-token price
Complex reasoning	A chat model that lists a reasoning capability and a large context window
Code generation	A chat model whose description or capabilities mention code
Semantic search	An embedding model (/v1/embeddings accepts only these)
Vision input	A model whose capabilities include vision
Image generation	A text-to-image model (see Image Generation)
Transcription	A speech-to-text model (see Speech to Text)
Live transcription	A speech-to-text model that also lists realtime support
Spoken output	A text-to-speech model (see Text to Speech)
Cost optimisation	The smallest model that still passes your evaluation set

Requesting Models

Need a model that's not listed?

1. Confirm it doesn't appear in the Running Models list
2. Contact your platform administrator
3. Request deployment

Factors affecting availability:

• GPU resource requirements
• License restrictions
• Platform configuration