Katara Cortex

katara/cortex is the model the API serves. Send it any chat request and Katara picks a model for it: whichever candidate is available, fits the task, and costs the least under a published ceiling. When a provider drops out between one message and the next, the next message is still answered.

What it picks from

Cortex chooses among the catalog’s chat models. Marketplace models come first: with Katara Community on, every marketplace model that can serve the request is tried before any managed model, whatever the task. A managed model, one that Katara serves through a vendor’s API rather than a provider’s node, is picked only when no marketplace provider can take the request or every one that tried failed. A vendor never wins on price against a provider that can serve you. Among managed models, the order depends on what the request needs (next section).

Community providers run on their owners’ hardware, and a large model may take longer to start answering than a vendor would. Cortex waits for it: at least 60 seconds for the first token, and longer for a long prompt (three times the start the provider’s measured speed predicts, up to five minutes), after which the provider counts as failed and the next candidate is tried. A request with tools gets no first-token limit on Katara Community, since many runtimes send nothing until a whole call is written; it moves on when the provider fails. Each vendor model has its own, shorter first-token budget: 10 seconds for the Light model, 20 for Standard and 45 for Deep. A provider that is full or returns an error is passed over at once. Marketplace providers are part of Katara Community, so a request with Katara Community turned off chooses among managed models only, whether it is paid with account credits or USDC.

Every candidate is checked against your request first. A request with tools only goes to a model that takes them, with your tool_choice and tool names, and one with images, sound, video or a PDF only to a model that reads them (Images, audio, video and PDFs); a response_format nobody serves is refused with feature_not_supported.

Light, standard and deep

Before a request is routed, its latest message is sorted into one of three tiers, and each tier has its own order of managed models:

Tier	For	Managed models, in order
light	greetings, thanks, small talk, a single common fact, a trivial edit	Light, then Standard
standard	ordinary questions, explanations, short writing, summaries, simple code	Standard; for a request with an attachment, then Deep
deep	maths, multi-step code or debugging, expert medical, legal, financial or scientific questions, long dense documents	Deep, then Standard

Backup models follow in every tier and answer only when the tier’s own models cannot. Otherwise a model from another tier is not used: a light request does not go to the Deep model, and a deep one does not go to the Light model. Not every backup model reads attachments, so the Deep model backs up Standard for a standard request that carries one.

A request with a video is always deep. One with an image, a recording or a PDF is at least standard. When the message cannot be sorted in time, the request is standard. Katara also decides how much the model reasons. reasoning_effort and thinking are accepted, so clients that send them keep working, and change neither the tier nor the thinking. Katara Community, when it is on, still comes before every managed model in every tier.

How it orders them

1. Availability: a model with no provider that passes the selection filters is skipped, and a model whose recent requests mostly failed ranks after the ones that answer, until it answers again.
2. The conversation: a conversation that Cortex already served stays on the model that served it while anyone serves that model, and on the same provider or vendor while that one is available, so an agent loop sees one model for the whole session. This holds even when a cheaper provider appears later: a conversation that started on a vendor because no provider was up stays on the vendor. Only a new conversation goes back to the marketplace. A conversation does move when its tier changes: after small talk on the Light model, a hard question goes to the Deep model. A conversation a backup vendor answered while the tier’s first model was away goes back to that model once it can serve. The conversation is recognised by your key and the first message of the transcript, and forgotten after thirty minutes without a reply. Wallet-paid conversations are recognised by the first message alone for now.
3. Task fit: katara.task in the request (code, chat, or extract) says what you are doing. Without it, a request that carries tools counts as code. Models are tagged with the tasks they are preferred for. Task fit orders marketplace models among themselves and the backup vendors among themselves; it never puts a managed model ahead of a marketplace one or ahead of its tier’s own models.
4. Price: among what is left, the cheapest; then the faster of two at the same price.

Every reply, from a provider or from a vendor, passes the same validation before you see it. A reply with nothing in it, a tool call that cannot be delivered, or a stop the runtime did not mean is refused and the next candidate is tried; nothing is charged for a refused reply.

{
  "model": "katara/cortex",
  "messages": [{ "role": "user", "content": "Refactor this function." }],
  "katara": { "task": "code" }
}

The katara block is read by Cortex and removed before the request reaches any model.

Answers about Katara

Add "knowledge": true to the katara block to give the model what Katara’s documentation and website say about your question:

"katara": { "knowledge": true }

Katara looks up your latest message on its own servers and adds a system message just before it: which model is answering, and the passages that match, each with its page. The rest of the conversation is left as you sent it, so its start, and what the model’s cache holds of it, stays the same. The added text counts as input tokens. Without the flag a request reaches the model as you sent it. Requests paid with x402 do not take the flag.

What you see

Whatever model name the request carries, the reply’s model is katara/cortex and system_fingerprint is katara-cortex, in every chunk of a stream as well. The katara object carries the charge, not the model that served it:

"katara": {
  "cost_usdc": "0.000018",
  "provider": "0xfFe5…38DC"
}

The signed receipt behind the charge names the concrete model and provider, never Cortex.

Context window

/v1/models lists the largest window among Cortex’s chat models as its contextLimit, 1,048,576 tokens, and the largest output as maxOutputTokens, 65,536. A request too long for a candidate passes that candidate over; Katara Community models take less than Katara’s own models, so a long request goes to a model that fits it. A request longer than every candidate’s window is refused with 400 context_length_exceeded before anything is sent or charged.

Caching

Katara’s own models cache the start of each prompt. A later prompt that starts the same way, by at least 4,096 tokens, reads that part from the cache, and those tokens cost the model’s cached input rate: a tenth of the input rate on the Light and Standard models, a twentieth on Deep. Nothing needs to be turned on. To get the most from it, keep the start of a conversation fixed: send the same system prompt and tools in the same order, and add new turns at the end rather than editing earlier ones. The cached count is in usage.prompt_tokens_details.cached_tokens, and the katara block shows cached_tokens and what they saved, cache_saving_usdc (or cache_saving_usd on account credits).

For a long prompt start that many requests share, such as a large system prompt or a document asked about many times, the Standard and Light models can also keep an explicit cache. Ask for one in the katara block:

"katara": { "cache": { "messages": 1, "ttl_seconds": 600 } }

The tools and the first messages messages are cached; 0, the default, caches the leading system messages. The request that writes the cache pays to keep it for ttl_seconds (60 to 3,600, default 300), at the model’s storage price per million tokens per hour, and the reply names it as cache_written_tokens, cache_ttl_seconds and cache_storage_usdc. Later requests with the same start, from the same account, send only what follows it and read the rest at the cached rate. A start shorter than 4,096 tokens is not cached. The Deep model takes no explicit cache and uses the automatic one only. Requests paid with account credits use the automatic cache and ignore the field.

What it costs

You pay the price of the model that served you. Cortex has a published ceiling per million input and output tokens, shown as its pricing on /v1/models with basis: ceiling; a model priced above the ceiling is not a candidate. The ceiling is 2.40 USDC per million input tokens and 12 per million output tokens until 30 November 2026, and 4.80 and 24 from 1 December 2026, when the Deep model’s price rises (Models). Account-credit requests are charged the credit price of the model that served them and are not filtered by the ceiling. There is no extra charge for routing.

When it fails over

Only before anything was delivered. If the first model’s providers all fail before the first token, or none has started answering within its first-token limit, the next model is tried. If a provider fails after it has already sent part of a reply, the reply ends with an error chunk and nothing is charged; Cortex does not switch models in the middle of an answer. Send the message again.

An x402 request changes model the same way, under the payment it already carries, and is charged once at the price of the model that answered, never more than was signed. A next model that costs more than the signed amount is passed over and the models after it are tried. When none of those answers, the failure answers with a fresh 402 challenge for the first model that was passed over, and when the authorization is close to expiring, with one for the next model; the client signs it and retries, and the first authorization expires unused. Automated clients should bound the retry count and validate the network, token, recipient and amount on each challenge. A client that only handles one challenge will surface the second 402 instead of completing the fallback. When no provider can take the request, the challenge quotes a vendor: the amount is the vendor’s price over the request’s token bounds, and the settled charge is what the reply cost, never more than you signed. Pay per request with x402 shows a client that signs each new challenge.

Model names

Clients that ship with a default model work unchanged: every name is served by Cortex (Model names in requests), and no request with a key can pick the model that answers.

A request paid per call with x402 may also name katara/cortex-genius, always answered by the Deep model, or katara/cortex-smart, always answered by the Light model. Each moves to the Standard model only when its own model fails before answering, and each has its own minimum charge; see Choosing a model. Keys, account credits and the Katara apps are refused both names.

Marketplace only

A vendor sees the prompt it answers. If that is not acceptable, an API key can be marked marketplace-only: Cortex then serves it from providers or refuses it.