Review 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 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 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 you look at, which likewise never hides, filters or reorders a template. The fourth is one you configure: a decision-score evaluator 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); 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: 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 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, 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
• Keep metric series low-cardinality
• Explain LLM spend per customer
• Investigate agent runs