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
Section titled “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
Section titled “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
Section titled “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.
Capabilities
Section titled “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. Every provider of a bundle passes the same certification before the bundle may advertise tools, 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
Section titled “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
Section titled “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
Section titled “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 wallet, 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. Wallet-paid requests cannot use vendor models yet.
Naming a model
Section titled “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.