Models

This section has moved to Model registry.

Your organization’s model registry determines which model IDs your requests can use. Start by listing available models. Use an explicit ID for a particular model, or auto for the default or routing policy configured by your administrator. Model IDs are not versioned, and a dated name follows the provider’s current release; see Model lifecycle.

Step 1 - List the models your requests can use

GET /models returns the active entries of your registry, minus any whose definition sets hidden: true (see Model registry troubleshooting). Read each item’s capabilities before you send sampling or reasoning parameters. Use the SDKs or the CLI to manage the model catalog and registry.

import { SDK } from '@meetkai/mka1';

const sdk = new SDK({ bearerAuth: 'Bearer <mka1-api-key>' });

const models = await sdk.llm.models.list({
  xOnBehalfOf: '<end-user-id>', // optional — attribute the request to one of your end users
});
console.log(models.data.map((m) => `${m.id} (${m.modelType})`));

const model = await sdk.llm.models.get({ modelId: 'meetkai:functionary-pt' });
console.log(model.capabilities.supportsTemperature, model.capabilities.supportsTopP);

import OpenAI from 'openai';

const openai = new OpenAI({
  apiKey: '<mka1-api-key>',
  baseURL: 'https://apigw.mka1.com/api/v1/llm/',
});

const models = await openai.models.list();
console.log(models.data.map(model => model.id));
const model = await openai.models.retrieve('meetkai:functionary-pt');
console.log(model.id);

from meetkai_mka1 import SDK

sdk = SDK(bearer_auth="Bearer <mka1-api-key>")

models = sdk.llm.models.list(
    x_on_behalf_of="<end-user-id>",  # optional — attribute the request to one of your end users
)
print([f"{m.id} ({m.model_type})" for m in models.data])

model = sdk.llm.models.get(model_id="meetkai:functionary-pt")
print(model.capabilities.supports_temperature, model.capabilities.supports_top_p)

using MeetKai.MKA1;
using MeetKai.MKA1.Types.Components;

var sdk = new SDK(bearerAuth: "Bearer <mka1-api-key>");

var models = await sdk.Llm.Models.ListAsync(
    xOnBehalfOf: "<end-user-id>" // optional — attribute the request to one of your end users
);
foreach (var m in models.Object!.Data)
{
    Console.WriteLine($"{m.Id} ({m.ModelType})");
}

var model = await sdk.Llm.Models.GetAsync(modelId: "meetkai:functionary-pt");
Console.WriteLine(model.Object!.Capabilities.SupportsTemperature);

mka1 llm models list -H 'X-On-Behalf-Of: <end-user-id>'

mka1 llm models get --model-id meetkai:functionary-pt

curl https://apigw.mka1.com/api/v1/llm/models \
  --header 'Authorization: Bearer <mka1-api-key>' \
  --header 'X-On-Behalf-Of: <end-user-id>'

curl https://apigw.mka1.com/api/v1/llm/models/meetkai:functionary-pt \
  --header 'Authorization: Bearer <mka1-api-key>'

A list item looks like this:

{
  "id": "meetkai:functionary-pt",
  "object": "model",
  "created": 0,
  "owned_by": "meetkai-pt",
  "model_type": "llm",
  "input_modalities": ["text"],
  "output_modalities": ["text"],
  "parameter_count": null,
  "active_parameter_count": null,
  "release_date": null,
  "capabilities": {
    "supports_temperature": true,
    "supports_top_p": true,
    "supports_reasoning": true,
    "supports_reasoning_effort": false
  }
}

Field	Meaning
`id`	The name to send as `model`.
`created`	The Unix time the definition records, or `0` when it records none.
`owned_by`	The provider the platform calls for this entry. For an entry reached through an aggregator, it is the aggregator’s name; for a BYO entry, it is the definition’s `provider` label.
`model_type`	`llm`, `embeddings`, `images`, `speech_to_text`, or `text_to_speech`.
`input_modalities`, `output_modalities`	What the model accepts and produces, such as `text`, `image`, `audio`, or `video`.
`parameter_count`, `active_parameter_count`	The model’s total parameters, and the parameters active per token for a mixture-of-experts model. Each is `null` when unrecorded.
`release_date`	The model’s public release date as `YYYY-MM-DD`, or `null` when unrecorded.
`capabilities`	`supports_temperature`, `supports_top_p`, `supports_reasoning`, and `supports_reasoning_effort`. All four are `false` for anything that is not an LLM. Check what a model supports explains each flag.

GET /models/{model_id} returns 404 for a name that is not in the catalog, for one that is in the catalog but inactive, and for one whose definition is hidden. The gateway does not say which, so a response cannot reveal what other organizations have.

Step 6 - Check effective prices

GET /models/pricing/effective returns the rate your organization pays for every model it can call. Any bearer can read it, with no role or scope, because anyone whose requests are billed can see the rate they are billed at. Audit fields such as who set a price stay on the admin pricing routes.

const prices = await sdk.llm.models.listEffectivePrices({});
console.log(prices.currency);
for (const row of prices.data) {
  console.log(row.model, row.source, row.rates);
}

prices = sdk.llm.models.list_effective_prices()
print(prices.currency)
for row in prices.data:
    print(row.model, row.source, row.rates)

var prices = await sdk.Llm.Models.ListEffectivePricesAsync();
Console.WriteLine(prices.EffectivePricesResponse!.Currency);
foreach (var row in prices.EffectivePricesResponse!.Data)
{
    Console.WriteLine($"{row.Model} {row.Source}");
}

mka1 llm models list-effective-prices

curl https://apigw.mka1.com/api/v1/llm/models/pricing/effective \
  --header 'Authorization: Bearer <mka1-api-key>'

source is org_override when a price override was set for your organization through PUT /models/pricing/org/{org_id}, cluster_default when a cluster entry uses the operator’s rate card, and unpriced (billed as 0) otherwise. An organization admin can set that override for their own organization’s active byo entries with setOrgPrice, read it back with listOrgPrices, and remove it with clearOrgPrice; an override on a cluster entry is cluster-admin only. currency is the cluster-wide ISO 4217 code, or null until the operator sets one.

Troubleshooting

Symptom	Cause	Fix
`404 model_not_found` with `Model 'x' not found. Check the model ID and try again.` from `/responses` (`/chat/completions` and agents say `Model 'x' not found or not supported`), or `404` from `GET /models/{model_id}`	The name is not active in your registry, its definition is hidden, or the key belongs to a different organization.	Find the entry in the catalog and activate it. If it is already `active`, check that the key belongs to the same organization and that the definition is not hidden (see the `hidden: true` row).
`auto` fails while named models work (`/extract` and `/classify` report `Model 'auto' is not available to your organization for extract.`)	No override is set and the operator’s default is not active in your registry; the override’s target was deactivated (`resolvable: false`); or the cluster’s YAML defines no `autoModels` entry for that endpoint.	Activate the default target, set an override to an active model, or clear the stale override. With no YAML default, only an override makes `auto` work on that endpoint.
`409 Model 'x' is active from source 'byo'` on activation	Another source holds the name.	Deactivate that entry first, or keep it and leave this one unactivated.
`422 Catalog entry 'x' from source 'cluster' is not available`	No access grant for that id, the wrong `source`, or a BYO id nobody defined.	Check the catalog (Step 2) for the id and its source; ask a cluster admin for access.
`422 The cluster org must activate its own catalog with source 'byo' or 'serving'`	You are acting in `org_cluster`.	Use the entry’s real source, or switch to the tenant organization.
`403 Organization admin access required`	The bearer’s organization role is `member`.	Use an owner or admin key, or a console session with that role.
`403 API key is missing required scope(s): write:registry`	The key was minted without the scope.	Mint a key with `write:registry` (owners and admins only).
An entry is `active` in the catalog but missing from `GET /models`, and requests naming it return `404`	Its definition sets `hidden: true`. A hidden definition never resolves for a user request; a hidden cluster model is reachable only as the target of another model’s reroute rule.	Expected. Point requests at a non-hidden entry.
A cluster model disappeared from the catalog and requests to it fail	A cluster admin revoked access, which deactivates the name.	Ask for the access grant back, then activate again.

Model administration

Activation, catalog grants, and bring-your-own model configuration are covered in Model registry. Auto routing explains routing policies.

Get started

SDKs and CLI

Responses

Standalone APIs

Agents

Evals

Compute

Authentication

Production

Step 1 - List the models your requests can use

Step 6 - Check effective prices

Troubleshooting

Model administration

​Step 1 - List the models your requests can use

​Step 6 - Check effective prices

​Troubleshooting

​Model administration

Step 1 - List the models your requests can use

Step 6 - Check effective prices

Troubleshooting

Model administration