Review usage and AI settings

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

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.

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.

Configure automatic quality checks

Open Settings → AI → Automatic Quality Checks to control sampled LLM-as-judge evaluation of agent runs. Start with a small sample, choose only criteria the recorded run contains enough evidence to judge, and review results before increasing coverage. Automated scores are investigation signals, not proof of correctness.

The per-cycle limit counts paid metric judgments, not runs: one run selected for three enabled metrics can consume three judgments. The limit is shared by all projects in the organization. Retrying delivery of an already-saved judgment does not consume it. Metric identifiers are trimmed and lowercased when saved; duplicate names after normalization are rejected.

Anectico leases each (organization, project, run, metric) evaluation before calling the judge. It persists a successful verdict before submitting the score, so ordinary provider errors, score delivery failures, service retries, and ledger-completion failures cannot create another judge call. Failed or unparseable judge responses retry with an exponential cooldown capped at one hour instead of hot-looping. A process crash in the narrow interval after an external provider accepts a request but before Anectico can persist its response is the unavoidable distributed-systems uncertainty; after the verdict is persisted, recovery retries only score delivery.

Viewing these settings requires evals:read (or evals:write). Editing, pausing, or resuming them requires evals:write; the dashboard remains read-only without it. Setting the sampling rate to zero stops new evaluation work.