Glossary

Definitions for the Cruxy vocabulary: tiers, the cruxy block, request_id, device login, and the 429 codes.

Terms you meet across the guides and the API reference, defined once. Each entry links to where the term is used in full.

Models and tiers

Tier

A public model you address by a stable name rather than by the provider model behind it. You pass a tier as model, and the gateway resolves it to an upstream provider model on the server; you never send or receive that upstream id. Because the name is stable, your code keeps working when the backing model changes. See Models.

kavi, vaani, mira

The three public chat tiers. You pass one as model to Chat. To read the live catalog rather than hardcoding the strings, call Models.

cruxy-embed

The embeddings model. You pass it as model to Embeddings to turn text into vectors.

cruxy-rerank

The rerank model, and the only one the gateway offers for reranking. You pass it as model to Rerank, which orders candidate documents against a query.

cruxy-guard

The moderation model, and the only one for moderation. You pass it as model to Moderations, which classifies text against content-safety categories.

Requests and responses

OpenAI-compatible

Requests and responses keep the OpenAI shape, so an existing OpenAI client needs little more than a new base URL and key; see Migrate from OpenAI. Chat, Embeddings, and Moderations follow it; Rerank does not; it uses a Cohere-style contract whose results carry indices into your input.

The cruxy block

An additive, namespaced cruxy key on responses. It never alters the OpenAI-shaped fields, so a vanilla OpenAI client parses the response unchanged and ignores the extra key. Its contents vary by endpoint: on chat it carries request_id, routed_tier, and reasoning_effort (cost and tokens live in usage); on embeddings and rerank it carries request_id and a cost object. Moderations has no top-level block, though a flagged result carries its own cruxy.hazard_codes. See the cruxy block.

request_id

A UUID that identifies a single call, returned in the response's cruxy.request_id. You log it to identify the call in support requests, and you send it back to Feedback to attach an outcome to that call. Request IDs and metadata shows where it appears on each endpoint.

Rerank

Scoring a set of candidate documents against a query and returning them best-first, so you order a shortlist by relevance. Each result carries an index into the documents you sent, not the text itself. See Rerank.

flagged

The overall boolean in a Moderations result: true when any category matched. Check it first. The accompanying category_scores are binary (1.0 or 0.0), not calibrated probabilities, so you do not threshold them.

Authentication

An RFC 8628 device-authorization flow that mints a key: your client requests a code, a person approves it in a browser, and your client polls until a key is issued. The browser and the client can be different machines. See Get your API key.

user_code and device_code

The two codes in device login. device_code is the secret your client polls with and never shows the user; user_code is the short code the person confirms in the browser. See Get your API key.

Bearer key

A cxy_live_ API key you send in the Authorization: Bearer header on every authenticated request. Device login returns it exactly once, so you store it on issue and treat it like a password. See Authentication.

Limits and budgets

rate_limited

The 429 code that means requests are arriving too fast. It clears on its own once you ease off, then retry. See Rate limits and budgets.

budget_exhausted

The 429 code that means the account's budget is spent. A retry alone will not clear it until the budget resets or is raised, distinct from rate_limited, which eases on its own. See Rate limits and budgets.