Plans, limits, and retention

Anectico measures usage in units a developer can connect to application behavior. Seats are not a usage meter.

Anectico is in early access. The table below describes the planned self-serve tiers shown on the pricing page; an early-access agreement or dashboard may show different limits. Settings → Account is the source of truth for an active organization.

Planned self-serve limits

Plan	Pooled events / month	Active metric series	Replay sessions / month	Retention	Hosted investigations	Daily AI spend cap	Daily decision-scoring cap
Free	1 million	1,000	1,000	7 days	—	—	$0.10 / day
Solo	20 million	10,000	10,000	30 days	—	—	$0.50 / day
Pro	150 million	50,000	50,000	90 days	—	—	$2 / day
Scale	500 million	100,000	250,000	180 days	2,000 / month	$50 / day	$10 / day

The daily AI spend cap is a brake on runaway model spend, not the allowance: the monthly count is the allowance. When either is used up, an investigation is refused with 429 and a message that names the limit and when it resets.

The daily decision-scoring cap bounds the small typed judgments Anectico makes on your behalf on every plan. Today there are three made on your behalf — ranking anomaly findings, ordering the evidence a Customer Detective investigation reads when it has more than fits, and suggesting a category and an attention marker for the repeated log templates you look at — plus any decision-score evaluators you configure. One judgment costs a fraction of a cent, so your plan's event and series meters are the real allowance and this cap only stops a runaway. When it is reached nothing is refused: findings simply stay unranked, investigations trim evidence in their fixed order, log templates are listed without labels, and decision-score evaluations wait to be retried rather than being scored, until the cap resets at midnight UTC — everything else works exactly as before. The same holds whenever the scoring model is unavailable.

Current prices and included product capabilities are listed on the pricing page.

An agent-run investigation can make one sandboxed replay attempt. The limit is per saved investigation, including its follow-up turns, and does not reset when a client reconnects or the investigation moves between processes. Asking again produces an explicit replay-limit refusal in the answer. Agent-run investigations that do not request replay consume no replay attempt.

What counts as an event

One log line, trace span, error event, or diagnostic event counts as one pooled event. The event types share the same pool.

Metrics use active series because their cost depends on the number of distinct label combinations, not only the number of data points. At the active-series limit, existing series continue to ingest; only unseen metric names or label combinations are rejected. This rejection is non-retryable. The meter is organization-wide and its background snapshot may lag by a few minutes. Replays count recording sessions that started in the period.

Which month usage lands in

Usage is counted in the period we received it, not the timestamp on the data. If your SDK buffers events offline and sends them later — a mobile app reconnecting after a flight, say — those events are billed in the month they reach us, even though they keep their original timestamps everywhere you read them. Backdating a timestamp therefore does not move usage into an earlier period, and it never removes usage from the current one.

Projects

Each plan allows a fixed number of projects: 5 on Free, 10 on Solo, 50 on Pro and 1000 on Scale. Creating one beyond the limit is refused; upgrade to raise it.

Downgrading never deletes a project. If a downgrade leaves you above the new limit, everything keeps working and you simply cannot create another until you are back under it.

Deleting data changes one meter, not the other

Deleting a metric frees active-series capacity. Active series measures what you are currently tracking, so a metric you delete stops counting against the limit once the next background snapshot runs; that is why removing an accidental high-cardinality metric is the remedy when you are near the cap. The freed capacity is real capacity: new series are admitted against it from that same snapshot, not only at the start of the next monthly period. A series reserved immediately before a snapshot can be held through one additional snapshot interval so an in-flight data point from another project is not mistaken for deleted data.

A deleted metric that your application keeps sending stays deleted, and stays free. Its data points are still hidden from every query, dashboard, and alert, and they do not count toward your active series or take capacity from a new one — so you do not have to redeploy before the capacity comes back. Deletion suppression is project-scoped: the same series sent by a different project remains active and is admitted normally. If you want the deleted project's metric again, send it under a name you have not deleted.

Deleting logs, spans, errors, or product events does not refund pooled events. That meter counts what was ingested during the period, and the ingestion already happened, so a deletion cannot return it. Delete for privacy, correction, or hygiene — not to recover pooled-event capacity. Replay sessions behave the same way.

Retention

Retention is a rolling history window. Data outside the plan's window is no longer available to search, timelines, API reads, MCP tools, or Customer Detective.

The window is organization-wide. Every project inherits the organization's current plan or administrative override; projects cannot advertise or configure a separate retention period.

If the window is shortened, older history expires under the new limit. Increasing it later keeps the history that is still available for longer, but it does not bring back history that already expired under the earlier window.

Field limits

These apply to every plan and are not usage meters. They bound one payload rather than a month's volume, so a request that trips one is rejected immediately and is not retryable without a change.

Field	Limit
Metric name	255 characters
Span name	255 characters
Attribute key	512 bytes
Attribute value	32,768 bytes
Attribute value nesting depth	8 levels
distinct_id	200 bytes
Distinct IDs in one recording lookup	100
Matchers in one alert silence	32
Alert-silence matcher label name	512 bytes
Alert-silence matcher value	4,096 bytes
Stack frames symbolicated for one request or occurrence	256
Event name (product events)	200 characters
Attributes per span, span link, log record, data point, or exemplar	256
Total attribute bytes per span, log record, or data point	262,144 bytes
Spans, log records, or data points per export request	10,000

The attribute value limit is measured on the value's encoded size, whatever its type: a string, a byte string, an array, or a nested key-value list. An array of 1,000 strings is measured as the sum of those strings, not as one value.

Each distinct ID in a recording lookup is also subject to the 200-byte distinct_id limit above. Alert-silence regular expressions use the matcher-value limit and are validated when the silence is created or edited; a malformed expression is rejected instead of creating a silence that can never match.

The total attribute bytes limit is the sum for one item, because one item is stored as one record. For a span that is its own attributes plus every span link's and every span event's; for a log record it is the body plus the attributes; for a metric data point it is the point's attributes plus its exemplars'. Individually legal attributes can add up past this, and an item that does is rejected. It is set well above ordinary instrumentation — a span carrying eight maximum-size exception stack traces still fits — so reaching it usually means an application is attaching a whole request or response body to a span. Attach a reference instead, or truncate before the attribute is set.

Metric and span names follow the OpenTelemetry maximum instrument-name length of 255 characters. Names are otherwise accepted as your instrumentation emits them, including forms OpenTelemetry does not itself recommend — a leading digit, a colon (as Prometheus recording rules use), spaces, and non-ASCII letters all work.

What a name may not contain is characters a reader cannot see: control characters, bidirectional overrides, zero-width and invisible characters, and variation selectors. These have no legitimate use in a name, and a name carrying them would display as something other than what it is wherever it is read — in a dashboard, in a search result, or by an agent reading it through the API.

A rejected export names the field and the rule. It does not echo the value back, so if a name is rejected, compare it against the limits above rather than expecting it in the error text.

One invalid item rejects the whole export request. If a single metric in a batch carries an invalid name, the batch is refused rather than partially accepted, so nothing is silently dropped. Fix the name and resend.

Gauge, sum, explicit-histogram and summary metrics are accepted. Exponential histograms are rejected as unsupported metric data; configure the exporter to send explicit histograms before resending. Summary counts and quantile values are stored as measurements and do not replace exporter labels or create a new series whenever the observed values change.

Span start/end times, span-event times, metric observation times and exemplar times must be present and fit the storage timestamp range. A metric's optional start time cannot follow its observation time. Numeric observations must be present and finite; summary quantiles must be between zero and one. These checks happen before delivery is acknowledged. OTLP NoRecordedValue markers are accepted and count toward request limits; their timestamps and attributes are validated, while their unused measurement fields are ignored. They produce no measurement row or persistent staleness tombstone, so earlier measurements remain available in historical queries. Logs use their source timestamp when present and otherwise their observed timestamp; at least one valid time is required.

Span events on an agent span are separately indexed up to 4,096 per span. Agent span events — the evaluation, guardrail and context records carried on a model-call span — each become an individually addressable agent event you can filter, count and alert on. Past 4,096 on one span, the remaining events are still stored on the span and still readable there, but they are not separately indexed. Nothing is rejected and nothing is dropped from the span. The OpenTelemetry SDK default caps span events at 128, so reaching this needs a deliberately raised OTEL_SPAN_EVENT_COUNT_LIMIT; if you are, split the work across spans rather than raising it further, because one span carrying thousands of events is also slower to read.

Instrumentation attributes, service name, and exception types

Every instrumentation attribute map gets the same display-safety handling: resource, span, span-event, span-link, log-record, gauge, sum, histogram and summary data-point attributes, plus exemplar filtered attributes.

For item attributes, the count and byte limits in the table above are validation limits. Exceeding one rejects the export as described above. Attributes that pass those limits then receive a second, per-attribute character check. That check never rejects the export: a key or value containing undisplayable characters is replaced by a stable fingerprint.

Resource and span-event attributes are not subject to the per-attribute count and value limits in the table above. A span event's attribute bytes do count toward its span's total-attribute-bytes limit, because they are stored on that span. Their stored representation is bounded instead:

Field	Stored limit
Resource service.name, deployment.environment (and environment, env, service.environment)	255 characters
Any other resource or span-event attribute value	32,768 characters
Resource or span-event attribute key	512 characters
Resource attributes per resource	256
Span event name, exception type	255 characters

An undisplayable value is replaced by sha256:<digest>. A clean value that exceeds a stored character limit keeps a short readable prefix followed by …sha256:<digest>. The fingerprint is stable, so all telemetry from that source still groups together, and it is computed over exactly the bytes you sent, so you can identify which value it was:

printf '%s' "<the value you sent>" | shasum -a 256

Every attribute key is an identifier and may not contain newlines, carriage returns or tabs. Attribute values are prose and may contain all three — a multi-line exception stack trace, SQL statement, HTTP user agent or request body is stored intact. The resource identity values in the first row above are the exception: they are single-line identifiers because they appear as labels throughout the product.

If a resource carries more than 256 attributes, the excess is dropped in a stable order and the number dropped is recorded on the resource as anectico.resource.attributes_dropped. service.name and the environment attributes are never dropped.

The character-safety handling in this section is applied per attribute and never causes an export to be rejected. The item count and byte validation limits still apply before it.

Product analytics measurement limits

Trend, funnel and retention measurements run asynchronously and are bounded separately from the usage meters above:

Limit	Value
Measurements pending or running per project	4
Maximum wait for a synchronous answer (wait_millis)	25 seconds
Maximum time one measurement may run	120 seconds
How long a completed result stays readable	1 hour
Contributors per selection	1,000,000, read 1–100 per page

A measurement that exceeds its running time, memory or scan budget fails outright with a named reason rather than returning a smaller answer. See measure product events for the full definition, retry semantics, and how to poll past the wait_millis ceiling.

When a planned limit is reached

Anectico warns before a limit is exhausted. Under the planned policy, verbose logs degrade before spans, while errors continue to ingest and alerts continue to evaluate. New replay sessions can be paused. Clients should honor 429 responses and Retry-After; they should not retry in a tight loop.

The OTLP gRPC endpoint carries no HTTP status, so a throttled export is answered with RESOURCE_EXHAUSTED accompanied by a retry delay. Standard OpenTelemetry exporters read that delay and retry the batch automatically; no client change is needed. The delay matches the Retry-After value the HTTP endpoint returns for the same condition.

Use Settings → Account to view current plan and usage.

• Review usage and AI settings
• Keep metric series low-cardinality
• REST API errors and retries
• Measure product events