Review usage, model prices and decision scoring

In the Console, open Billing and usage (/billing) for the current plan and usage period, on the Plan & Usage card. See the Console guide. Anectico shows pooled admitted events with a product and technical breakdown, plus control, critical-error, critical-error-overage and metric-point counts. It also shows active metric series, replay sessions and the organization's plan-based replay retention window. Product and technical history use the separate Product and technical policy choices below; the replay window does not describe those histories. Replay and content policies can impose shorter lifetimes on their own data.

For subscriptions, invoices and payment recovery, use the Billing card on the same page. See manage billing. Allowances follow UTC calendar months even when payment renews annually.

Ask your agent

"How much of this month's event allowance have I used? Split it into product and technical events."

"Which models cost the most this month? Is there a price override for any of them?"

Job	MCP tool or action	CLI command
Read the usage meters for a month	get_org_usage	anectico usage --period <YYYY-MM>
Read the product and technical policy	get_family_policy	anectico usage policy get
Read measured product and technical usage	get_family_usage	anectico usage families --period <YYYY-MM>
Change the product and technical policy (preview, then confirm)	update_family_policy	anectico usage policy update
List, set or remove a model price override	list_llm_pricing, upsert_llm_pricing, delete_llm_pricing	anectico llm pricing list, anectico llm pricing set <model>, anectico llm pricing delete <model> --yes
Read model spend	llm_cost_summary, llm_cost_series	anectico llm summary, anectico llm series

Usage reads need usage:read. Changing the policy also needs settings:write. Reading price overrides needs settings:read; setting one needs settings:write and removing one needs settings:delete. Spend reads need llm:read. The usage tools are read actions, so MCP reaches them through execute_read_action; the MCP write tools preview first and apply on a second call with a confirm_token. See MCP tools.

What your agent gets back

Usage reads return the meters, the allocation of each family, revisions as decimal strings and the time the counts were measured. They do not return any telemetry. These reads have no proof page; the Billing and usage page in the Console shows the same numbers.

The main usage response separates three retention facts:

• usage.plan_retention_days_max: the nominal plan ceiling when the monthly snapshot was computed.
• usage.replay_retention_days: replay's plan or approved override window at that computation time.
• retention_policy: the current product and technical choices, state, granted ceilings and permanent expiry floors. It is read now, even for an older billing month or before a snapshot exists.

Only FAMILY_POLICY_STATE_CONFIGURED grants the returned family windows. If current policy is absent or needs configuration, history is unavailable; do not substitute a plan ceiling or zero days. For example, a Free organization choosing 7 days that upgrades to Solo can have a nominal 30-day ceiling and still retain 7 days for each family. Upgrading preserves a shorter choice. A later policy increase cannot recover history that has already expired.

Interpret usage states

The Console 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.

Product events and technical events (logs and spans) are each limited by their own allocation inside the pool. Each meter has independent notices at 80% (warning) and 100% (allocation limit), even if another meter already warns or the pooled total is lower. Product events are admitted whole below 125% of their allocation and refused whole (quota_exceeded) at or above 125%; they are never sampled. That refusal threshold produces a separate stop notice. Technical logs keep 50% at 100%, 25% at 110%, 10% at 125%, and none at 200%; spans keep 100%, 50%, 25%, and none at those thresholds. Technical usage at 200% produces a stop notice. Critical errors bypass allocation sampling, while other intake checks still apply. Reduced input can limit alert evidence; a notice does not guarantee alerts will fire. Rebalance the product and technical policies or upgrade. The usage response reports both allocations as events_breakdown.product_allocation and events_breakdown.technical_allocation. 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.

The billing email contact receives a notice for each observed crossing and recovery below 80%. Without a billing email, the crossing is still recorded. usage.threshold_events in anectico usage --period <YYYY-MM> --json, GET /api/v1/usage?period=<YYYY-MM>, and the MCP get_org_usage read action lists the latest 50 observations for that month. Each includes its meter, previous and current threshold, used, limit, or percent, observation time, event ID, snapshot generation, admission rules and alert evidence caveat. Newest generations come first, with a fixed meter order within each generation. threshold_events_truncated is true if older events have fallen out of the journal. Events reflect background observations, not exact crossing times, email delivery, or a count of refused records. Earlier history is not reconstructed when this journal is introduced. Missing policy observations do not count as recovery. The pooled meter is a reporting total; family allocation gates decide event admission independently.

Your agent 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.

A complete monthly snapshot requires the events, active metric-series and replay-session meters. An absent meter is unknown, never measured zero. If a snapshot is incomplete, the read refuses to report healthy quota values until the missing measurements are restored. The current month refreshes in the background; an older snapshot may need repair. A new month with no snapshot yet remains an explicit empty state. Recorded zero usage is a valid measured value.

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 general usage snapshot is computed in the background and may lag admission by a few minutes. The Product and technical policy card shows the month's admission counts as of their last measurement; an absent measurement is unknown, not zero. Its "as of" time and revision show when the reported counts were measured.

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. Admitted events and replay sessions work the other way — they count what was admitted 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 the current self-serve catalog; effective limits can differ under that agreement.

Ordinary telemetry exports keep the source window they were created over. A file whose source history the current technical policy no longer retains stops being downloadable; increasing retention does not renew old files. New exports default to the last 24 hours when no range is supplied. See Save and export data.

Product and technical policies

On the Billing and usage page, the Product and technical policy card shows the saved choices, granted retention ceilings, shared allowance and current month's measured usage. Choose Edit policy, enter all four choices, then Review changes and Save policy. The review shows the previous and proposed values for every project. Organization members with usage access can read the card; changing it also requires organization-wide settings access.

If saving is not confirmed, Retry save sends the identical request and retry key. Load current policy reads current state so you can prepare a new change. A stale revision or denied permission prevents repeated confirmation until you reload. Switching organizations or sessions closes the previous editor.

GET /api/v1/family-policy reads the organization's current product and technical retention choices, allocation split, granted ceilings and revisions. Both families share the existing monthly events allowance. A project_id selector returns the same policy for that project; it does not create another allowance. Project-bound credentials must select their exact project. Reads require usage:read.

Read the policy and measured usage from the CLI:

anectico usage policy get
anectico usage families --period 2026-09

Both commands honor the configured project selector while showing the shared organization policy and counts. MCP provides get_family_policy and get_family_usage through execute_read_action with mcp:read and usage:read. Their counts and revisions are decimal strings so large values stay exact. The response also carries retention_version, a decimal-string storage operation sequence separate from the revision used to edit settings. Zero means no family retention operation has been assigned; a positive number does not confirm that cleanup has finished. product_expired_before and technical_expired_before, when present, are the points before which shortening retention permanently removed that family's history; a later increase never makes it readable again.

Every organization starts with a policy derived from its plan: both retention ceilings are the plan's retention (at most 365 days), the pool is the plan's monthly events allowance, and the default choice keeps full retention in both families with 20% of the pool for product events and the rest for technical telemetry. When your plan or allowance changes, the split is rescaled to the new pool, and a lower ceiling shortens a longer window to fit; a higher ceiling does not lengthen your chosen windows. To change the choice, use PUT /api/v1/family-policy with both current revisions, a unique idempotency key, and the complete choice. The first request returns a server preview and applies nothing. Review its complete before and proposed state, then send the identical body with confirm_token as a query parameter:

{
  "expected_revision": "1",
  "expected_entitlement_revision": "1",
  "idempotency_key": "family-policy-2026-09-23-1",
  "values": {
    "product_retention_days": 90,
    "technical_retention_days": 30,
    "product_allocation": "700000",
    "technical_allocation": "300000"
  }
}

The example assumes a 1,000,000-event pool and sufficient retention ceilings; substitute the limits and revisions returned for your organization. Each window must be at least seven days and at most its granted ceiling. Both allocations must be nonnegative and sum exactly to the pool. Updating requires all of mcp:read, mcp:write, usage:read and organization-wide settings:write; a project-bound key cannot change the shared policy. Customers cannot increase granted ceilings or the pool through this endpoint.

The Console, REST, CLI and MCP preview the same complete replacement before applying it. The preview names the existing policy, entitlement, revisions, expiry floors and proposed choices. Commit times and any new physical-retention version are assigned when the server commits; their assignment rules are stated in the proposal. The confirmed receipt includes the original complete committed policy snapshot, including on an identical retry. For the same example, run:

anectico usage policy update \
  --expected-revision 1 --expected-entitlement-revision 1 \
  --product-retention-days 90 --technical-retention-days 30 \
  --product-allocation 700000 --technical-allocation 300000 \
  --idempotency-key family-policy-2026-09-23-1

The first call reads current choices and returns a confirmation token without saving anything. Repeat the same command with --confirm-token set to that token to apply the previewed values. It uses the MCP update_family_policy internal action and requires mcp:write, usage:read and organization-wide settings:write. Both revisions are checked when saving. If another editor or an entitlement change intervenes, reconcile the latest policy and prepare a new preview. A project-bound credential cannot update the organization policy.

Shortening either retention window can permanently expire telemetry. Increasing it later cannot restore expired data, and restoring the old choices is not an undo operation. The preview and the Console confirmation show this warning before you save. The mutation is classified as destructive for agents even when a particular request only increases a window or changes the allocation split.

A successful write returns the original committed policy and an operation receipt. Queries, exports and new data follow the saved windows within about a minute; removing stored data that fell outside a shortened window happens in the background. A product analytics range that starts before retained history is refused, not shortened: the measurement fails with HISTORY_UNAVAILABLE, and a later start is needed. Retry the identical request with the same key after an uncertain response. The receipt is retained for seven days; reusing its key with changed input conflicts. MCP confirmation tokens expire after ten minutes. If a token expires while the outcome is uncertain, the REST endpoint can recover the original receipt with the identical body and key; starting a new MCP preview requires the current revisions. If either revision changed, read the policy again before choosing new values.

GET /api/v1/usage/families?period=YYYY-MM combines current policy with the organization's admission counts for that UTC month, as last measured. project_id has the same mirror semantics. allocation_enforcement is FAMILY_ALLOCATION_ENFORCEMENT_INDEPENDENT: product capture and technical OTLP use their own configured allocations. The measurement reports product and technical events, identity controls, critical errors (a subset of technical events), critical-error overage at admission, and metric points. observed_at (and updated_at) is the time the counts are as of — they refresh every few minutes — and revision identifies that measurement. A month without a measurement has none (unknown, not zero); a measured zero is present with zero counts. The general pooled usage view derives its event total from product plus technical admissions; corrections and active-series and replay meters remain separate. Counts do not prove queue delivery, storage or source coverage. Exact retries, retention expiry and project deletion do not refund them. The critical-error exception and overage thresholds mean allocations are not hard spending caps.

Set LLM pricing overrides

Use the LLM Pricing Overrides card on the Billing and usage page (/billing) when a model's organization-specific input, output, or cache token price differs from Anectico's built-in catalog. Your agent can set the same override with upsert_llm_pricing (CLI: anectico llm pricing set <model>). 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 Console.

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 a new model call, then ask your agent to read its cost with llm_cost_summary (CLI: anectico llm summary) or list_agent_runs.

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 and 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 four on its own, and a fifth 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. It suggests a category and an attention marker for each repeated log template your agent reads, which likewise never hides, filters or reorders a template. And when you compare a tracking plan with what was actually observed, it says which declared name an observed-but-undeclared event name or property key was most likely meant to be — an annotation beside the comparison, which never edits a plan, changes a drift status or hides a row. And it judges how serious each Issue is right now and which part of your application it comes from. Your agent reads this as an affirmative-only needs-attention marker and a suggested area on the Issue; it sets no priority, status, assignee or note, opens and closes nothing, and sends no notification. The fifth is one you configure: a decision-score evaluator places a sampled agent run on an ordered scale you write and returns a score and the name of a level, never prose. It runs under your content policy, the paid evaluation budget and the calibration bar a release gate applies. 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, log templates are shown without labels, tracking-plan suggestions stay pending until a later pass, Issues stay unmarked and unlabeled, 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. 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. Tracking-plan suggestions send only the observed name and the plan's declared names, never an event property value; a custom property key is considered only when the person asking already holds content access. An Issue judgment sends none of those classes either: the Issue's title — the truncated error message, with values such as email addresses and card numbers already replaced — its error type, service name, the level your code reported, its occurrence and affected-customer counts over the last day and week, an hourly occurrence series for the last day, its first- and last-seen releases, and how many times it has regressed; never a full message, a stack trace, a breadcrumb, a request header, custom data, or any customer identifier. A decision-score evaluator sends exactly the evidence its evidence selectors declare, which is a judge_transfer transfer, and nothing more.

Automatic quality checks

Sampled model scoring of agent runs is configured per project, through the evaluation control plane: you author a decision-score evaluator (a named, versioned scale of ordered levels), attach a sampling rule that says which runs it sees and at what rate, and set a daily budget that caps what scoring 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 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 model 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 model call. When the model cannot answer — its daily decision-scoring cap is reached, or it is unavailable — nothing is scored and the evaluation is retried later. Failed or unusable model responses retry with an exponential cooldown capped at one hour instead of hot-looping.

Your content policy decides what a judge may see

A decision-score evaluator that selects model_transcript evidence 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, it is never retried in a loop, and it costs nothing against your evaluation budget.

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 an evaluation model 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

A failed history measurement returns earliest_available_start and failure_message with the current readable source boundary. Check every query, comparison and audience source window against that boundary, then submit a new definition with a new execution key. The original window is never shortened. CLI commands that print a product result print it in full and exit 1 for every status other than ready, including pending and running.

The family-policy preview returns the complete current and proposed choices. It names usage:read, settings:write and mcp:write. Publication timestamps and a new retention version are explicitly assigned on commit; a shortened history floor states its rule instead of reusing an old timestamp. Increasing a window keeps the existing expiry floor and cannot make expired history readable again. Confirmation repeats identical arguments.

Pricing and onboarding-draft writes use the server's complete before and proposed preview. The native CLI's first call previews; repeating identical arguments with --confirm-token applies. All these flows need settings:read; saving also needs settings:write, and deleting a price needs settings:delete. Pricing aliases are resolved by the owner. Price changes affect future calls and preserve stored costs; deleting one organization's override preserves global and other organizations' prices. A setup save replaces all draft fields, including its test identifiers; it does not install anything or prove collection. A refused current-state read refuses the preview.

Account declarations and financial work

Declared account value owns declaration retention, financial read and export permissions, and privacy rules. Those declarations are separate from this workspace's subscription, model-price overrides and usage meters.

Agent plan headroom

The console shows Plan allowances on Agents and keys and Billing and usage. The card requires usage:read only; it does not grant approval inventory or budget-edit permissions. Use Refresh allowances after a revoke or a plan change. Held capacity remains used until its release is confirmed, and a failed read makes remaining headroom unknown.

Use anectico usage agents --period 2026-09 --json or the get_agent_plan_usage read action through execute_read_action. The REST read is GET /api/v1/usage/agents?period=2026-09. All require usage:read; MCP also requires mcp:read. Omit the period for the current UTC month. Malformed or future months are refused. The workspace always comes from your credential. Reading headroom consumes no work allowance.

connections measures current OAuth approval slots: active approvals, pending approvals and slots held until cleanup is confirmed. All consume capacity. It does not count sockets, runtimes, observed agents or management keys, and has no calendar reset. Other members' approval identities are not returned.

automation measures work admitted during the requested month: scheduled reports, scheduled warehouse exports, Live panel refreshes and sampled evaluations. The four kind counts sum to the admitted total. Work observations distinguish unknown, unstarted, started, completed and failed; a receipt alone proves no completion. Interactive work, configuration reads, delivery continuations, safety alerting and customer-run telemetry are excluded. Coverage names these accounting units. enforcement_qualified: false and qualification_reason explicitly report that approval and scheduled-work admission paths are not yet qualified.

The plan tier, revision and observation time describe the current plan, including when you request an older month. Monthly resets follow the exclusive UTC month end even for annual subscriptions. Check checked and the observation time before drawing a conclusion. An accounting outage returns plan_limits_unavailable, not zero usage. A checked empty month is zero.

These provisional catalog values may change after qualification. They are resource allowances, separate from prices, and add no query charge.

Tier	OAuth approval slots	Monthly admitted automated work units
Free	2	1,000
Solo	5	10,000
Pro	25	100,000
Scale	100	1,000,000

A checked result includes the current plan's exact limits and dated counts. Unavailable accounting returns a typed unavailable answer, preserving known observations. Do not turn missing headroom into zero. Existing admitted approvals and work survive a downgrade; new work at the cap must use the returned cleanup, upgrade or monthly-reset remedies. Headroom has no proof page.

A plan_refusal preserves the dimension, unit, known counts, current plan tier and revision, check state, upgrade availability and remedies. plan_limit_reached is 429; plan_limits_unavailable is 503. Monthly exhaustion can name the UTC reset. Do not automatically retry a capacity refusal.

Exhausted approval capacity calls for releasing an approval, waiting for confirmed cleanup or reviewing a higher plan. Exhausted monthly work calls for a higher plan or the stated UTC reset. Commercial allowances are not owner-editable (owner_can_change: false); a larger operation budget does not increase them. Accounting unavailability is a different refusal and asks you to check later. Alerts, watches, monitors, on-call, escalation and alert notifications are outside the monthly hard allowance, as are free polling, previews, manual work and already admitted delivery continuations.

Typed-decision expenditure

Use Manage agent budgets for the covered expenditure definition, exact nano-USD policy, current enforcement limits, commands and permissions. After a lost apply reply, use write recovery with the original intent and key. These controls are separate from the model-price observations and scoring brake above.

Intake accounting

Use anectico usage intake or get_intake_ledger to read submitted-position dispositions. Read coverage and intake completeness owns the receipt-time window, retention, counts, watermarks and completeness limits.