# Review usage and AI settings

> Understand plan consumption, retention, LLM pricing, and automatic agent-run checks.

Canonical page: https://anectico.com/docs/manage/usage-and-ai-settings/


Open **Settings → Account** for the current plan and usage period. Anectico shows pooled events with a
logs, spans, product-events, and errors breakdown; active metric series; replay sessions; and the
organization's retention window.

## Interpret usage states

The dashboard warns at 80% of a limit. Pooled events and replay sessions can show a degraded state
at 100%; active metric series remain a warning because the cap rejects only new series rather than
degrading existing ones. The meter may take a few minutes to appear for a new organization. It is an
organization-wide monthly view, so changing the selected project does not make the total
project-only.

Automation can read the same organization-wide snapshot with `anectico usage`, `GET /api/v1/usage`, or
the MCP `get_org_usage` read action, reached through `execute_read_action`. MCP access requires both
`mcp:read` and `usage:read`; the action accepts only an optional exact `YYYY-MM` period and never
accepts a caller-supplied organization ID.

The active metric-series limit preserves continuity for series Anectico already knows. At the limit,
datapoints for existing metric series continue to ingest, while a new metric name or label
combination is rejected. That rejection is non-retryable: retrying the same unseen series does not
make capacity available. Remove accidental high-cardinality labels or arrange a higher limit before
introducing more series. The usage snapshot is computed in the background and may lag ingestion by
a few minutes.

Deleting a metric frees its active-series capacity: the series meter counts what you are currently
tracking, so a deleted metric leaves the count at the next background snapshot, and new series are
admitted against the freed capacity from that same snapshot. Pooled events and
replay sessions work the other way — they count what was ingested during the period, so deleting
telemetry does not return any of that month's consumption.

When approaching a limit, first remove accidental high-cardinality metrics, noisy debug logs, or
unnecessary replay capture. Do not reduce error capture before low-value volume.

The active agreement and **Plan & Usage** card are authoritative for an organization. Public pricing
tables describe planned self-serve tiers and may differ during early access.

## Set LLM pricing overrides

Open **Settings → AI → LLM Pricing Overrides** when a model's organization-specific input, output,
or cache token price differs from Anectico's built-in catalog. Rates are stored as USD per token.

The table lists stored organization and global overrides only; it does not list every built-in
catalog rate. People with `settings:read` can view the table without mutation controls.
`settings:write` is required to add or edit an organization override, and `settings:delete` is
required to delete one. Global overrides are shown read-only in the organization dashboard.

Use the exact model identifier emitted by instrumentation. Overrides refresh in the background on an
interval, so an upsert, update, or deletion can take up to one refresh interval to take effect
everywhere. The active precedence is organization override, then global override, then Anectico's
built-in catalog; an explicit cost or per-token price sent with the span remains authoritative over
all three.

Cost is materialized once, during background span processing. Anectico never recalculates already
persisted rows, so historical costs stay stable. This also means a span queued before an override
change but processed afterward uses the rate active at processing time. After saving an override,
send and inspect a newly processed model call in **Agent Runs** or **Traces → LLM Costs**.

If the pricing-override snapshot has not loaded yet, span processing uses the built-in catalog and
keeps retrying with a bounded request timeout. If a refresh fails after that, span processing
retains its last-known-good customer rates and reports their stale age rather than silently
changing to built-in rates. Span processing never makes a pricing network request.

Input and output totals follow OpenTelemetry's inclusive token semantics:
cache-read/cache-write counts are detail subsets of input tokens, and reasoning
counts are a detail subset of output tokens. Anectico separates those subsets before
applying cache rates, so cached or reasoning tokens are not charged twice. Anectico's
Anthropic SDK wrappers add Anthropic's separately reported uncached, cache-read,
and cache-creation input counts before exporting that inclusive total.

## Decision scoring

On every plan Anectico asks a small typed-decision model for judgments it can answer as a
probability rather than as text. Today it makes three on its own, and a fourth when you ask for it. It ranks
[anomaly findings](/docs/investigate/anomalies) by how likely each is to be a real fault, and it
never changes anything — a finding is never closed, hidden or called "noise" by it. When a
[Customer Detective](/docs/investigate/customer-detective) investigation gathers more evidence than
one answer can read, it asks which items bear on your question so the ones left out are the least
relevant rather than the last collected; every omission is still disclosed in the answer. And it
suggests a category and an attention marker for each repeated
[log template](/docs/investigate/search-telemetry) you look at, which likewise never hides, filters
or reorders a template. The fourth is one you configure: a
[decision-score evaluator](/docs/reference/evaluators) places a sampled agent run on an ordered
scale you write, under the same content policy, spend budget and calibration rules as every other
model judge. Each plan carries a daily decision-scoring cap (see
[plans and limits](/docs/reference/limits)); when it is reached, or when the model is unavailable,
findings are simply shown without a rank, investigations trim their evidence in the fixed order they
always did, log templates are shown without labels, decision-score evaluations wait and are retried
rather than scored, and everything else continues as before.

What is sent follows your [content policy](/docs/manage/content-policy): a class you deny at **Sent
to a model** is never sent for scoring either. Anomaly ranking sends none of those classes — it reads
the metric and service names, the observed value, the expected band and recent numeric history, and
no metric attributes. Evidence ordering sends exactly the evidence the investigation itself is about
to send, under the same policy, and nothing more. Log-template labeling sends none of those classes
either: it reads the normalized template — the one with the values already replaced by placeholders,
never a raw log line — together with that template's level and service name. A decision-score
evaluator sends exactly the evidence its `evidence` selectors declare, which is the same
`judge_transfer` transfer every model judge makes, and nothing more.

## Automatic quality checks

Sampled LLM-as-judge scoring of agent runs is configured per **project**, through the evaluation
control plane: you author an **evaluator** (a named, versioned rubric), attach a **sampling rule**
that says which runs it sees and at what rate, and set a **daily budget** that caps what judging may
spend. See [Quality evaluations](/docs/agents/quality-evaluations) for the whole surface, including
the API, the CLI and the MCP tools.

Reading that configuration needs `evals:read`; changing it needs `evals:write`. Recording a **human**
judgment on a run is a different permission — `scores:write` — which every member holds, because
rating a run is not an administrative act.

> The organization-wide "Automatic Quality Checks" settings card described here previously — a single
> list of built-in metric names, one judge model and one sampling rate for the whole organization —
> has been **withdrawn**. It could not say which version of a rubric produced a score, so its numbers
> could not be cited by a release gate or reproduced later. There is no automatic conversion from it:
> author an evaluator and a sampling rule for the projects you want scored.

The per-cycle budget counts paid **metric judgments**, not runs: one run evaluated against three
metrics can consume three judgments. Retrying delivery of a judgment that was already produced never
charges again. Evaluators that call no model — deterministic and reference-trajectory ones — consume
no budget at all and keep working after a paid budget is exhausted.

Anectico leases each evaluation before calling the judge and persists a successful verdict before
recording the result, so ordinary provider errors, delivery failures, service retries and
ledger-completion failures cannot cause a second judge call. Failed or unparseable judge responses
retry with an exponential cooldown capped at one hour instead of hot-looping.

### Your content policy decides what a judge may see

An LLM-as-judge reads the run's recorded prompt and response, and that is a transfer of your
recorded content to an evaluation model. It is governed by the project's
[content policy](/docs/manage/content-policy), at the `judge_transfer` boundary, and the policy is
consulted before anything is sent — not after.

- If `model_transcript` is **allowed** at `judge_transfer`, evaluation runs exactly as described
  above. Every project starts this way, so turning quality checks on changes nothing about what you
  had.
- If it is **denied**, or set to `allow_metadata`, the run is **not sent** and is recorded as
  **withheld by policy**: a terminal outcome that names the kind of content, the boundary and why —
  your policy said so, the project has no policy yet, or the policy could not be read. It is never
  scored 0, and it is never retried in a loop.

A withheld run is deliberately distinguishable from one that was never selected. "Nobody judged this"
and "nobody sampled this" are different facts, and a quality metric that cannot tell them apart is a
metric you cannot trust.

A policy change takes up to 30 seconds to apply.

Changing what a judge may see is a separate permission — `governance:write` — because it is a
disclosure decision rather than a spend one.

- [Plans, limits, and retention](/docs/reference/limits)
- [Keep metric series low-cardinality](/docs/instrument/metrics#keep-names-units-and-labels-stable)
- [Explain LLM spend per customer](/docs/investigate/llm-spend)
- [Investigate agent runs](/docs/investigate/agent-runs)