Models and bundles

Picking a model on Katara means picking a bundle: a published description of exactly which weights, tokenizer, chat template, and runtime a provider must run. Every provider serving a bundle runs the same thing, so a request to katara/llama-3.1-8b-instruct@1 gets that model, whoever serves it.

Why bundles

Marketplaces without this rule end up with quietly different models behind one name. Katara’s validators send known prompts to every provider and score the answers against recorded results. That only works when the model is fixed.

It also keeps prices comparable. Providers compete on price and speed for the same bundle, not on what they secretly run.

Who publishes bundles

Katara does. A new model means writing the bundle, pinning it on reference hardware, recording the validation prompts, and approving it. Providers then choose from the approved list. They cannot add their own.

Bundle manifests

Each approved bundle’s manifest is published at https://docs.katara.com/bundles/<bundle>.json, the address recorded on chain with its hash. Providers pass that file to the node. The current bundles:

• llama-3.1-8b-instruct.v1.json: Llama 3.1 8B Instruct, 4-bit, Apple Silicon profile. Chat only; its tool-call format is not one the MLX runtime parses.
• qwen3-coder-30b-a3b.v1.json: Qwen3-Coder 30B-A3B Instruct, 4-bit, Apple Silicon profile with 32 GB of unified memory or more. Tool use for coding agents; 3B active parameters per token keep it fast.

Which machines can serve which bundle is set out in Hardware compatibility, generated from these manifests.

Live availability

/v1/models always includes Katara Cortex. Named models appear while a registered provider has a valid offer and passes the routing health checks, or their managed vendor is configured and available. A short period at full capacity does not remove a model. Models return to the list when service recovers.

The chat selector and portal refresh availability in the background, usually within tens of seconds after a health change is detected. No page reload is needed. Availability can change between listing and submitting a request, so clients must still handle 503 no_capacity.

Capabilities

/v1/models lists each model’s capabilities: whether it streams, takes tools, structured output or reasoning, and its output cap. tools: true carries a tool_contract saying exactly what was certified: the accepted tool_choice values, parallel calls, strict schemas, the largest argument tested, the concurrency tested. Published tool capabilities are limited to the runtime contract supported by recorded tool checks, and a request outside the contract is refused rather than served differently. See Tool calling.

supported_params lists the request parameters the model acts on. A parameter outside the list is refused with feature_not_supported when it carries a value, and dropped when it carries its default, so nothing is accepted and then ignored. The list carries the bundle’s temperature cap too: a temperature above it is refused.

Versions

The @1 in a model id is the bundle version. A new version, for example one that adds a CUDA profile or changes quantisation, gets a new number. Old versions keep working until they are retired.

Katara Cortex

katara/cortex@1 is not a bundle. It is the routing model: a request for it is served by one of the catalog models, chosen for availability, task and price, and the reply says which one. It is the model to use unless you need a specific one. See Katara Cortex.

Managed models

Some catalog entries are served through a vendor’s API rather than a provider’s node: katara/deepseek-chat@1 (DeepSeek) and katara/glm-5.3-flash@1 (GLM 5.3 Flash from Z.ai). No provider runs them. You can name one directly and it is served by that vendor at its published price, through the same API and payment methods, or refused with 503 no_capacity when the vendor is unavailable. Inside Cortex they are the last resort: picked only when no marketplace provider can take the request. A wallet-paid request is quoted at the vendor’s price and settled for what the reply cost. GLM 5.3 Flash always reasons before it answers, so a request to it needs max_tokens of at least the min_output_tokens its catalog entry lists, or none at all; a smaller cap is refused with 400 max_tokens_too_small before anything is sent.

Naming a model

A named model is strict. If no provider can serve it right now the answer is 503 no_capacity, never another model. Retry, or ask Cortex.

Compatibility and Live Offers

The public https://docs.katara.com/hardware.json describes pinned profiles and curated hardware choices. https://docs.katara.com/setup.json lists the same published serving manifests. Both carry the same catalog revision. Hardware documentation is generated from that catalog and the same matching rules.

GET https://api.katara.com/v1/discovery/availability reports active provider offers separately. Zero means no active offers were observed for that model. A failed, stale or missing observation means availability is unknown. Offers are signed identities and recent activity; routing still checks health, capacity and the requested capabilities.

Model Identity

Weights, tokenizer, chat template and runtime are pinned by the bundle. Provider setup verifies the selected manifest checksum and model identifier, and the node verifies downloaded artifacts before advertising. Offers, tickets and receipts bind the exact bundle and runtime profile to a registered service key.

These checks detect changed artifacts and identity mismatches. They do not prove that an independently operated provider used those weights for every request. Valid output, metering checks, runtime failure reports and provider feedback identify operational problems. Reference audits remain optional and require a suitable reference system. Performance reports and signed diagnostics are provider observations, not execution attestations.