Glossary
Every Cloud Score term that appears in the app, what it means in one or two sentences, and the page and tab where you meet it.
On this page
How to read this page
One row per term. Meaning is the short version; the concept pages carry the long one. Where you meet itnames the page, and the tab when the page has tabs, using the app's own labels.
Every row has a permanent anchor built from its term, so other pages can link straight at it. The row for Affinity lives at the anchor term-affinity.
Two words that change how you read every number
(est.) marks an estimate, and — means not recorded, never zero. Both have their own rows below. See Costs, savings, and estimates.
Terms A to Z
| Term | Meaning | Where you meet it |
|---|---|---|
| (est.) | Marks a figure as a priced estimate of avoided or counterfactual cost rather than a measurement. Only actual cost is measured; every savings number carries this marker or an Estimate chip, except on Overview, whose labels say Estimated savings or Est. savings instead. | Optimizations, the Optimization decision card and the Savings receipt |
| Action (AI Security) | What a security category does when it matches: Off (not scanned), Log (record an event only), Redact (replace the matched span), Block (refuse). Set separately for input and output. | Gateway › Guardrails, in the profile editor |
| Affinity | A small scoring nudge toward the model that answered the previous turn of the same conversation. decisive means the pin changed which model won. | Observability › the Request drawer and Playground, in Optimization decision |
| Alert channel | Where a notification is delivered: a signed webhook or an email address. Targets are stored masked, must be publicly reachable, and a webhook is auto-disabled after repeated failures. | Budgets › Alerts |
| Allow list and deny list | Two provider restrictions that behave differently. A later matching policy replaces the allow list, while deny lists from every matching policy add up and can never be undone by a later rule. | Policies › New policy, under Actions |
| Anomaly | A spending group whose last 24 hours stand out against the previous seven daily totals. Brand-new spenders are never flagged. | Budgets › Alerts (Recorded anomalies) |
| Attempts | The number of billed model calls a request made. Three is the ceiling; failovers and validation re-prompts share it, and setup failures are not counted. | Observability › the Request drawer, and the Attempt stations on the route board |
| Attribution | The five tags carried by every request: team, application, agent, environment, and end user. Request metadata wins over headers, which win over the API key's stored defaults. On Usage & cost they are reported tags; its Team, User and Agent dimensions are the key's assignment and the registered agent. | Usage & cost (Reported application, Reported environment, Reported end user) and Admin › API keys (Edit tags) |
| Billable cost | What the provider is likely to charge, with cached reads at the cached rate and cache writes at the write premium, shown as Estimated invoice. AI spend beside it is the same tokens at list price, and that is what the budget gate uses. | Estimated invoice on Usage & cost; Total spend on Overview; Billable (cached reads at cached rate) in a request's evidence in Observability |
| Block (policy action) | Refuses the request before any provider is called and stops policy evaluation there. Because policies run in ascending priority, the lowest priority number that blocks wins. | Policies › New policy (Block request) |
| Budget | A cap on model spend, tokens or requests for a day, week or month at one scope: the workspace, an API key, a team, a user, an application, an agent, an environment or a provider. Every request is checked against all budgets that apply before it runs. | Budgets |
| Cache hit rate | Cache hits divided by cache-eligible requests. Requests that were never eligible stay out of the denominator, so the rate measures the tunable population only. | Optimizations › Recommendations (Cache-eligible traffic rarely hits) |
| Cache scope | Who may be served a cached answer. The default keeps entries private to the API key that produced them; the shared setting lets every key in the workspace read them. | Policies › New policy (Cache scope) |
| Cache TTL | How many seconds a cached answer stays servable. A TTL of 0 means never write the entry at all, not write it and expire it immediately. | Policies › New policy (Cache TTL (seconds)) |
| Cache verdict | The single recorded reason a request was or was not served from the response cache. A miss means it was eligible and nothing usable existed; any other reason means it was never eligible. | Observability (the request's Cache section) and Playground |
| Candidate | An enabled model that survived the capability and context-window filter for one request, carrying its estimated cost. Scores are relative to the candidates that showed up. | Observability › the Request drawer, in the Candidates table |
| Capability | A model feature a request may need: vision, tools, json_mode, or streaming. A request only competes among models holding every capability it needs. | Models (Capabilities column) |
| Classifier source | Where a request's classification came from: llm (a real classifier call), cache (a stored earlier result), or heuristic (deterministic keyword rules). | The Classify station on the route board, and Observability › the Request drawer |
| Complexity | How hard the classifier judged the prompt to be, from 1 to 5. The heuristic path never returns 2 and only reaches 5 through a reasoning-keyword bump. | Policies › New policy (Complexity min (1–5) and Complexity max (1–5)) |
| Confidential keywords | A literal, case-insensitive word list for the confidential category, up to 500 entries. It matches whole words only and accepts no regular expressions. | Gateway › Guardrails, in the profile editor |
| Prompt Optimization | Preparing a shorter prompt before answer routing, at any input length. The optimizer shows a complete rewrite, diff and estimated savings in Playground before an original-or-optimized run choice. Live token counting makes no model call; explicit rewriting has separately recorded expense. Requests without a prepared proposal retain deterministic rules. Conversation history is not trimmed; structural checks do not guarantee meaning. | Playground, Optimization settings › Settings (Prompt Optimization), and the Prompt Optimization tab of Optimizations |
| Context window | The largest request a model accepts, counting estimated input plus expected output. A model is dropped from a request's candidates when the request would not fit. | Models (Context column) |
| Cooldown | A circuit breaker that keeps a repeatedly failing model or provider out of selection for a growing, capped window, and only while Routing adjustments is in auto. The badge reads cooling with the scope and an expiry. | Optimization settings › Routing signals |
| Decision trace | The append-only list of one event per pipeline stage, with each stage's own duration. It is what the route board draws, live during a request and again afterwards. | The Route board in Playground › Details › Routing and in Observability › the Request drawer |
| Discover | The sync that pulls a provider's catalogue into the registry. New models arrive disabled; prices, context windows, and capabilities are refreshed on every run; models the source no longer lists are disabled, never deleted. | Models (Discover OpenAI models and its siblings) |
| Duplicate miss | Money spent on completed requests whose prompt had already been seen in the window and that were not served from cache. It is an upper bound on what caching has not claimed yet. | Optimizations › Recommendations (Exact repeats are being re-executed) |
| Embedder | The connected provider that turns prompts into 1536-dimension vectors for semantic matching. Without one, semantic requests fall back to exact matching. | The Settings tab of Optimization settings: the Response cache workspace default and the Response cache section |
| Enabled (model) | The per-model kill switch. Routing only ever chooses an enabled model, and every enable, disable, or price edit purges that model's cached answers. | Models (Enabled column) |
| Estimate accuracy | How close the winning model's pre-flight estimate came to the billed actual. A positive difference means the request cost more than estimated. Cache and dedup rows never executed, so they have no estimate. | Optimization settings › Routing signals (Estimate accuracy) |
| Fail mode | What a security profile does when a scan cannot run or cannot finish: a detector error, or more than 512,000 characters of text. Fail open lets the request through with that category not run; fail closed blocks when the degraded category was set to block or, for text past the limit, to redact or block. | Gateway › Guardrails (Fail mode) |
| Failover | After a hard provider error, Cloud Score drops the failed model and re-scores the survivors. It is bounded by the three-attempt cap. | The route board: a failed Attempt below the rail, then a new Select |
| Forecast | A linear projection of the organization budget's period end: spend so far divided by the days elapsed, times the days in the period. It appears once enough of the period has passed. | Budgets (the Forecast end of period tile above Organization Budget Utilization) |
| Force model | A policy action that pins routing to one model key and skips scoring. It leaves a single candidate, so there is no failover left. | Policies › New policy (Force model (model_key)) |
| Guard in and Guard out | The two AI Security scans, one on the prompt and one on the answer, run under the security profile attached to the calling key. | The Guard in and Guard out stations on the route board |
| Health state | What a background check every minute concluded about a provider: up, degraded, down, or unknown. Only degraded and down cost a model any score, and unknown is never penalised. | Optimization settings › Routing signals (Health column) and the Measured tooltip on Models |
| In-flight dedup | Coalescing identical simultaneous requests on one API key so only the leader is billed. Followers receive the leader's answer and pay zero; it is neither a cache hit nor a miss. | Optimization settings › Settings (In-flight dedup), and its row in By mechanism on Optimizations |
| Intent | The request text you send to the native endpoint, and the one-line description stored with the row. It is only stored when the key retains bodies. | Playground, and the request and response previews in Observability |
| Learning | A model with too few completed requests in the stats window to be judged. A learning model is exempt from penalties, which is not the same as being unhealthy. | The Measured column on Models, and Optimization settings › Routing signals |
| List price | Measured tokens multiplied by the model's price card at execution time, with cached tokens charged at the full input rate. It is the only measured money figure and the basis every budget gates on. | AI spend on Usage & cost and Observability; Total (list — budget gate basis) in a request's evidence |
| Mechanism | One optimization lever the engine can pull for a request, such as a response cache, dedup, an output budget, or compression. Each has its own mode and its own row in the ledger. | Optimization settings › Settings, and By mechanism on Optimizations |
| Min confidence | The bar a mechanism's decision must clear before it is applied, between 0.5 and 1. Below the bar the request behaves as if the mechanism were only observing. | Optimization settings › Settings (Min confidence) |
| Mode ladder | off runs nothing, observe computes and records the decision without applying it, and auto applies it when confidence clears the bar. Observe never changes what a caller sees. | Optimization settings › Settings, and the Mode column of By mechanism on Optimizations |
| model_key | The provider-facing identifier for a model, unique per provider. It is what a caller pins with a model name and what a force-model policy matches on. | Models, in mono under each display name in the Model column |
| Recommendation | An opportunity the optimization engine found in the selected range, with its confidence, a recommended action and, where it can estimate one, a monthly effect. The estimate is never added to savings; it is not a promise. | Optimizations › Recommendations |
| Optimization plan | The per-request record of which mechanisms ran, in which mode, and what each decided. It holds no prompt text. | Observability › the Request drawer, in Optimization decision |
| Output budget | A predicted cap on how many tokens a reply may use, taken from recent same-task outputs plus headroom and never below the floor. A capped call that truncates is re-run once. | Optimization settings › Settings (Output budget, and the Output budget, last 30 days (UTC) line) |
| Output enforcement | When a profile redacts or blocks on the output side, answers on its keys are buffered in full before delivery, so live token streaming stops. Log-only categories keep streaming. | Gateway › Guardrails, warned in the profile editor |
| Pipeline | The fixed sequence of stages every gateway request runs, from the input guard to the recorded row. Errors travel with the request rather than stopping it, and every path ends at the record stage. | Drawn as the Route board in Playground › Details › Routing and Observability › the Request drawer |
| Platform API key | The credential your application sends to Cloud Score. It decides the workspace, the security profile, the budget, and whether bodies are stored. The full value is shown once, at creation. | Admin › API keys, and the Platform API key field on Playground |
| Platform overhead | Cloud Score's own spend inside a request, such as the classifier call. It is priced separately, never folded into the request's cost, and budgets do not count it. Its known part is subtracted once from gross savings to give net savings. | Saved (net) on Optimizations; − Cloud Score overhead (known) on the Savings receipt; Platform overhead in a request's evidence in Observability |
| Policy | A rule of the form conditions, all of which must match, then actions. Enabled policies run in priority order and every match applies, with later matches overwriting earlier values field by field. | Policies |
| Prefer tier | A policy action naming one dimension to bias scoring toward: cost, latency, or quality. It maps to a full weight split, and a caller's explicit strategy overrides it. | Policies › New policy (Prefer tier) |
| Priority | The integer that orders policies. Lower numbers are evaluated first, so a higher number wins on conflicting single-value actions, while the lowest matching block wins outright. | Policies › New policy (Priority) |
| Provider prompt cache | The upstream provider's own caching of repeated prompt prefixes. Cloud Score measures the cached token count and estimates its value, and always shows it on its own line rather than merging it into cache savings. | Token composition on Usage & cost, and the Provider cache-read tokens tile and the Provider cache (est.) step on Optimizations |
| Provider type | One of the vendors Cloud Score can call. Types billed per resource, project, or region may be connected more than once; the rest have a single connection. | Providers, one card per connection (Add another Azure AI Foundry and its siblings where several are allowed) |
| Quality tier and latency tier | Two grades from 1 to 5 that say what Cloud Score assumes about a model before it has seen it work. They are priors, not measurements, and editing either one makes your value permanent. | Models (Quality (prior) and Latency (prior)) |
| Reference model | The declared comparison point for what routing saved: the caller's requested model when it was a candidate, else the workspace setting, else the strongest candidate. A pinned client model saves nothing by construction. Savings name the state: the configured workspace reference, a labelled fallback when none is configured, or none. | Optimization settings › Settings (Reference model) |
| Required capability | A capability the request insists on. Cloud Score unions what you send with what the classifier infers, and models lacking any of them are excluded before scoring. | Playground › Advanced options (Required capabilities) |
| Response cache | Cloud Score's own store of validated answers. A hit costs nothing and credits the entry's original measured cost as savings. It has to be switched on explicitly, by a policy or by the workspace default. | Optimization settings › Settings › Response cache, switched on in Policies or under Workspace defaults on the same tab; its savings in By mechanism on Optimizations |
| Routing adjustments | Measured penalties for health, reliability, and latency that shade near-ties in selection. They only ever subtract, are capped in total, and never change a tier. | Optimization settings › Routing signals and Optimization settings › Settings (Routing adjustments) |
| Routing strategy | A per-request name for a weight preset: auto, balanced, cost, intelligence, latency. Only auto defers to your policies; the rest pin their split. Strategies change scoring only. | Playground › Routing and Admin › Developer |
| Sandbox key | A key flagged so the Playground may hand-pick which enabled policies apply to a single request. It is a testing affordance, not a bypass: the budget gate still runs. | Admin › API keys (Sandbox key — may hand-pick policies per request (playground)) |
| Savings waterfall | The chart that walks from the reference model's cost down through routing, compression, and cache plus dedup to what you actually spent. Routing is the residual and can be negative when Cloud Score escalated. | Optimizations › Overview (Savings waterfall) |
| Scan rules | A dry run of the real detectors against text you paste, using the editor's unsaved state. It stores nothing and is the sanctioned way to test a profile before you save it. | Gateway › Guardrails (Scan rules) |
| Scoring weights | The split between cost, latency, and quality applied to each candidate's normalised axes. The weights always sum to one, and the winner is the highest total after adjustments and affinity. | Admin › Developer strategy cards, and the Select station in Observability › the Request drawer |
| Security profile | A named, versioned rulebook of categories, actions, locales, keywords, and a fail mode, bound to zero or more API keys. It is pattern-based rather than an AI judgement. | Gateway › Guardrails, chosen per key on Admin › API keys |
| Similarity bar | The floor a semantic cache match must clear to be served. A policy can raise the workspace's bar but never lower it. | Policies › New policy and Optimization settings › Settings |
| Soft threshold | The percentage of a budget at which the breach starts being reported to your application while the request is still served. | Budgets, Soft threshold (%) in the limits editor |
| Status (request) | completed when nothing went wrong, blocked when a policy, a budget, or AI Security refused it, and failed for everything else. | Observability (Gateway status), and the Record station on the route board |
| Store request/response bodies | A per-key switch. With it off, prompts and answers are not kept, previews stay empty, and those requests can never be cached. Classification, trace, tokens, and cost are still recorded. | Admin › API keys (Store request/response bodies) |
| Task type | The classifier's label for what the prompt is asking for, one of nine values such as code, summarization, or generation. Policies match on it and analytics group by it. | Policies › New policy (Task type), and the Classify station |
| Threshold rule | One metric, optionally scoped, evaluated on a schedule over a sliding window. It fires at most once per window and then waits out its cooldown. | Budgets › Alerts (Metric, Window, Cooldown) |
| Utilization | Spend plus in-flight reservations measured against a budget's amount, for its current period. It is what a budget alert watches. | Budgets (Organization Budget Utilization) and Budget utilization on Budgets › Alerts |
| Version | An immutable snapshot taken every time you save a security profile. History is appended, never rewritten, and recorded events point back at the version that fired. | Gateway › Guardrails |
| Workspace default cache mode | What a request gets when no routing policy sets a cache mode. A policy's own setting always wins, and any caller can opt out of the cache for a single request. | Optimization settings › Settings (Workspace defaults › Response cache) |
| Zero rule | A recorded zero is stored as zero; something never recorded is stored as nothing and shown as —. Cloud Score never forges a zero, so a dash is always an invitation to hover and read the cause. | Every money and savings figure across Overview, Usage & cost, Optimizations and Observability |
Wiring badges tell you whether a mechanism acts
Observe only means a mechanism records its decision and changes nothing, even when its mode reads auto; the control stays editable. Not wired means no backend code reads that field at all, and the control is disabled. Context caching carries Observe only; what actually attaches a provider prompt-cache breakpoint is the separate Legacy Anthropic prompt-cache hint (pre-engine baseline) checkbox.
Where the long versions live
The pipeline stages in order: How Cloud Score routes a request. Weights and presets: Routing strategies. Task type and complexity: Classification. Tiers, scores, and measured signals: Models, tiers, and scoring. Cache eligibility and dedup: Caching and deduplication.
Related
- Statuses and badgesEvery status word and badge Cloud Score shows, what each one means, and the page it appears on.
- TroubleshootingThe messages Cloud Score puts in front of you, grouped by the page that shows them, with what caused each one and what to do next.
- ObservabilityThe per-request audit trail and the gateway's health: filter the request list, open a request for its route, attempts, cost and savings receipt, and read latency, outcomes and retries on Gateway health.
- Optimization settingsSet the reference model, the workspace-default response cache, and each mechanism's mode and confidence floor, confirm promotions and check a decision before traffic feels it, and read the routing signals.
- How Cloud Score routes a requestThe fixed sixteen-stage pipeline every gateway request runs, what each stage decides, the three outcomes, how failover works, and which admin page configures which stage.
- Finding your way aroundThe grouped sidebar, the header, which pages have tabs, and the conventions every number and badge in Cloud Score follows.