Service limits

Lumen inspects every AI interaction a collector sees and applies your policy to every one of them. None of that is limited. What is limited is how much of the text of routine, clean agent traffic the console keeps, and for how long. In one sentence:

Unlimited inspection; only the stored detail of clean agent traffic is bounded.

This page gives the exact numbers. They are the figures in force during the closed beta, like the prices on Plans and pricing. The console's Billing page shows the workspace's pool and every endpoint that is borrowing, over its allowance or unusual today; the Endpoints page shows each endpoint's events today.

What is unlimited

• Inspection. Every prompt and response a collector sees is inspected by every detector the policy references, however many there are.
• Enforcement. Log, Redact and Block apply to every interaction, on the endpoint, before anything is uploaded. No limit on this page ever changes a verdict.
• Findings. Findings have no daily allowance, and every one of them is counted. See Every finding is counted.
• Counting. Every event is counted, whether its text is stored or not, so the figures on Overview, Endpoints and Billing reflect what your endpoints actually saw.
• The price. Volume never changes what you pay. Pro is charged per endpoint-day, and there is no overage.
• The endpoint's own copy. The findings file on each machine (when it is configured, as the installers do) keeps every record with up to 64 KB of text, whatever the console stores, until the file rotates. See Reading findings on the endpoint.

What each endpoint stores per day

Lumen counts events. An event is one prompt or one response, which is one row on the Interactions page and what the console already counts. Allowances are per endpoint and per UTC day, and they reset at 00:00 UTC. 1 KB is 1,024 bytes of text.

	Free	Pro	Past the allowance
Findings	Unlimited	Unlimited	Always counted. Stored, with a 16 KB text window, up to a capacity ceiling far above expected use
Prompts a person wrote	200 with text	500 with text	The rest count as agent activity
Clean agent activity	400 with text	2,000 with text	Kept as a row without text: the time, the tool, the model, a short command and the destination
Text kept per clean event	8 KB	8 KB	Cut, and the console says so
Retention: findings and prompts	30 days	1 year
Retention: agent activity	30 days	90 days	Rows without text included

Which of the three kinds an event is gets decided once, by Lumen's control plane, when the record arrives. It is worked out from what the endpoint's engine found and did, never from a label a collector attaches.

Findings

• Every Block is a finding.
• A new detection is a finding, whatever the action: a match in the text being sent or received now, which was not already reported earlier in the same conversation. A language identification counts only when a language rule in your policy decided the action.
• A Redact, or a would have blocked or would have redacted, that no detection explains is a finding too. That covers an access rule denying an application, and a policy whose default action blocks, including on an endpoint in Monitoring.

Some matches are deliberately not findings, and count as agent activity instead:

• a match on text already reported earlier in the same conversation (a repeat);
• a match in an earlier turn that an AI coding tool re-sends with every request;
• the removal of content that was already blocked earlier in the conversation. After a block, the agent's proxy keeps removing that fragment from every later request of the conversation, and each removal is not a new finding.

On records from agents older than v2.8, a match in an earlier turn still counts as a finding, because those agents could not reliably tell the current turn from the history. That errs toward keeping more.

Matches that are not findings still appear on the Findings page. Hide repeats, on by default there, hides them. See Interactions and findings.

The Findings list and what Lumen counts as a finding (Findings today on Overview, Billing, this page) therefore differ in two ways. The list shows every record where a detection matched, so it also holds the matches above that are not counted. And a Block or Redact, or a would have blocked or would have redacted, that no detection explains is counted as a finding but matched nothing, so it is on the Interactions page, with the action it took, and not on the Findings list.

An example: one secret in a 40-request session

A developer pastes an AWS access key into the first prompt of a Claude Code session and keeps working. Claude Code re-sends the whole conversation with every request, so the key travels in all 40 requests of the session, and the detector matches it in every one of them. Counting each request would report 40 findings for a single incident.

	What Lumen records
The first prompt	1 finding. It is counted, and its text is kept in a 16 KB window around the match: 1 year on Pro, 30 days on Free
The other 39 requests	Agent activity. The key matched again, but it was already reported in this conversation, so each one is a repeat. The rows are counted against the daily agent activity allowance, and their text is cut to 8 KB and kept 90 days on Pro
On the Findings list	1 row with Hide repeats on (the default), and all 40 with it off
If the policy blocks the key	1 finding: the Block. From then on the agent's proxy removes the key from every later request of the conversation, and each removal is recorded as agent activity, on Interactions with the action it took, not as a new finding

Findings today on Overview and Billing reads 1 for this session, which is the number of incidents to look at.

Prompts a person wrote

A prompt is text a person typed and submitted: a Claude Code prompt from an interactive session, a prompt submitted on an AI site in the browser, or the user's turn in a request the agent's proxy captured when no agent wrote it. Token-count requests and the short utility calls a client makes on its own (asking the model for a conversation title, for example) are not prompts, even when they carry the same text.

A prompt past the prompt allowance is charged to the agent activity allowance. It keeps its text if that allowance still has room, and it is kept for as long as agent activity is.

Two cases count a typed prompt differently:

• Agents older than v2.8 do not record who wrote a turn, so a prompt typed through the agent's proxy counts as agent activity, against the larger allowance. Hook and browser prompts from those agents are still prompts.
• Until an endpoint runs the agent release that ships with these limits, a prompt typed in a Claude Code session the proxy covers arrives twice, once from the hook and once from the proxy, and both count against the prompt allowance. The newer agent normally uploads only one of them.

Clean agent activity

Everything else: model responses, tool calls and their results, sub-agents, system text, and records that mark a gap in capture. For an AI coding tool, this is most of what it sends: the results of the tools it ran, re-sent to the model as the current turn.

How much text an event keeps

Event	Text stored
A blocked event	None, as always
Any other finding	Up to 16 KB. A longer text keeps a 16 KB window: around the match when the endpoint reports where it is, around the last masked value when the match left one, otherwise the last 16 KB
A prompt or an agent event, within the allowance	Up to 8 KB. A longer text keeps the newest 8 KB of a request the agent's proxy captured, where the current turn comes last, and the first 8 KB of anything else
A prompt or an agent event, past the allowance	None, or a short command excerpt. See Rows without text

8 KB is the agent's inline inspection budget, and 16 KB leaves room for the match and the text on both sides of it. Every cut falls on a character boundary and never splits a [MASKED…] or [REDACTED…] placeholder. A custom redaction placeholder that your policy defines is not protected: a cut can split it, and it does not place a finding's window. Everything else a record carries, such as its context and its detections, is bounded too, far above what a normal record holds. The console marks a record that was cut or shortened and says which cut it was. See What Lumen stores.

Copies the agent does not upload

The agent does not upload a clean copy of something Lumen normally receives another way:

• a clean Claude Code prompt or tool result in a session whose requests the agent's proxy is capturing, which the proxy's next request carries as its current turn;
• a token-count request, which repeats the request that follows it;
• a separate record for the part of a long request the bounded detectors did not read, which is now a field on the request's own record.

The agent decides the first case from the proxy having captured the session's earlier requests. If the proxy then fails to capture that one request, the clean prompt is counted, but its text is only in the findings file on the machine, and the next prompt in that session is uploaded again. A session's first prompt is always uploaded.

A short utility call, such as a title request, is uploaded as a row without its text. A Claude Code tool call is always uploaded, because it is the only copy of its command. None of this ever applies to a record that matched anything. Each copy is counted as seen, and Billing shows the total as Recognised as duplicates by the agent. The findings file on the machine still holds every prompt, tool result and token-count request the agent did not upload, until the file rotates.

Borrowing

Each endpoint is guaranteed its own allowance every day. That is a floor nobody else can use up: not another endpoint's heavy day, and not a program misbehaving on another machine.

When an endpoint needs more, it borrows from what the workspace's other endpoints left unused that day, up to 5 times its own allowance:

Most one endpoint can store with text, per day	Free	Pro
Prompts	1,000	2,500
Agent events	2,000	10,000

The workspace's pool for a day is the per-endpoint allowance times the number of endpoints that reported that day (on Pro, the endpoint-days you are billed for). An endpoint borrows only while the pool still has unused room when its events arrive. An endpoint that needs its own allowance later in the day still gets it, even after others borrowed, so a busy day can end above the pool, by at most what was borrowed while the pool still had room.

For example, a Pro workspace with 10 endpoints has the text of 5,000 prompts and 20,000 agent events to share for the day. One very busy endpoint can store the text of up to 10,000 agent events while the others leave that much unused, and each of the other nine keeps its own 2,000 whatever happens.

A suspended endpoint is not part of the pool. A day the fleet spent paused by the monthly spend limit has no reporting endpoints, so the records caught up from it get each endpoint's own allowance and nothing to borrow.

Billing shows the pool as two meters, and lists every endpoint that is borrowing, is over its allowance, or has unusual volume. On Endpoints, an endpoint past its allowance carries Text limited.

Every finding is counted

Findings have no daily allowance on either plan. Each one keeps its 16 KB window, and each endpoint stores up to 5,000 findings a day on Free, and 20,000 on Pro. That is far above what a person-driven endpoint is expected to produce.

Past that ceiling, findings are folded rather than dropped. Lumen keeps one finding per rule, action and hour as a representative, and counts every other one against it without storing it. The representative's detail panel says how many it stands for (+N similar findings this hour were counted but not stored), and every folded finding still counts toward Findings today on Overview and on Billing. Blocks fold like any other finding.

A finding the agent had to drop from its own disk queue, on a machine offline long enough for the queue to fill, is counted too, once the agent reports it.

Rows without text and what they keep

Past its allowance, a clean prompt or agent event is stored as a row without its text. It stays on the Interactions page, it can be filtered and found by everything except its text, and it is counted everywhere. It keeps:

• when it happened, whether it was a prompt or a response, the collector, the action and why, and the endpoint and user, as every row does;
• the application and the model;
• the destination: the scheme and host of the provider or the page, never the path or the query, which can carry content;
• the tool that was called and, where the agent reports it, its target: the file a write touched or the host a fetch went to;
• the session and the working directory;
• which detections matched, in short form, when a repeat or an earlier turn matched;
• for a Claude Code tool call and an MCP tool call, a command excerpt;
• a few technical fields, such as the client and session identifiers the collector reported.

The excerpt is the start and the end of the command, with whitespace collapsed first, so padding cannot push the command out of view. It is 128 bytes, or 512 bytes when the call can reach beyond the session's project: a shell command, a web fetch or search, an MCP tool, or a write to a file outside the session's working directory. Like all stored text, it was masked on the endpoint first.

Any other context the record carried is left out. The detail panel says Text not stored: over the day's allowance of prompts and agent events, or Command excerpt only: over the day's allowance for an excerpt, and the lists show Text not stored: over the daily allowance where the text would be. "The day" is the UTC day the event is counted against, which for a late record is not the day it arrived.

An event that arrives with no text at all, such as an empty tool result, is stored as it is and uses no allowance.

Capacity ceilings

Two ceilings per endpoint protect the service's shared database from a runaway program or a forged endpoint. The row ceiling sits above any day measured so far (the busiest endpoint stored about 33,500 events in a day), and the finding ceiling far above the findings a person-driven endpoint is expected to produce.

Ceiling, per endpoint per day	Free	Pro
Findings stored in full	5,000	20,000
Every other row stored, with text, without text or empty	50,000	200,000

Each ceiling counts both the events that belong to a day and the events that arrived on it, so a backlog cannot open more room by being spread across several days. Past either ceiling, events fold the way findings do: the first event of each hour for each rule or collector, and each action, is stored as a representative, the rest are counted against it, and an endpoint keeps at most 2,000 representatives a day. Past that, events keep counting against the representatives already stored, and one that would have started a new one is counted in a single total for its day instead. The upload still succeeds, and nothing is refused.

An endpoint that reaches a ceiling, uses its whole allowance far faster than a person-driven agent does, or has more than twenty times its allowance stored without text or folded in one day, is marked Unusual volume in the console, and Wazuh's operators are notified the same day. That can be a very busy agent. It can also be another program on the machine: the agent's local API accepts records from any program running there, by design. Such a program can only use up its own endpoint's allowance and ceilings, and borrow the workspace's unused room as any endpoint can. It cannot touch another endpoint's own allowance, and it cannot stop another endpoint's findings from being stored. If an endpoint's volume is not legitimate, remove it on the Endpoints page: its credential is revoked, and every later upload from it is refused.

The upload path is also rate-limited for the whole service, far above real traffic, and an agent paces its own uploads. An agent that meets a rate limit waits and retries, and loses nothing.

Retention

	Free	Pro
Findings	30 days	1 year
Prompts	30 days	1 year
Agent activity, rows without text included	30 days	90 days

• A prompt past the prompt allowance that was charged as agent activity is kept for as long as agent activity.
• Records stored before these limits came into force keep the retention they were stored under, which is a year on Pro.
• A folded count is kept as long as its representative.
• Deletion is permanent, as described in What Lumen stores.

Late records

An event is counted against the UTC day it happened, not the day it arrived. A laptop that was offline for a while, or a fleet that was paused by the spend limit, catches up against the days its events belong to rather than against today's allowance.

• Only the last seven days are kept apart. An event older than that is counted against the day seven days ago, so a backlog longer than a week competes with that day's allowance.
• Each day of a backlog keeps its own allowance in full. What a backlog can borrow is bounded by the day it arrives, not by the days it belongs to: events arriving on one day borrow at most what one day's borrowing allows, 2,400 events on Free and 10,000 on Pro (four times the endpoint's own allowance of prompts and agent events together), across all the days they catch up. Past that, a backlog's events beyond each day's own allowance are kept as rows without text, like any other event past the allowance.
• An event stamped in the future, by a clock running ahead, is stored at its arrival time plus five minutes at most. The record keeps the time it claimed.

What this never does

• It never refuses a record, an upload or an enrollment because of volume.
• It never pauses an endpoint or a fleet. The monthly spend limit remains the only thing that pauses reporting.
• It never charges for volume. The price is endpoint-days, and there is no overage.
• It never suspends an endpoint for volume, and never answers an upload with a quota refusal. When an agent is asked to slow down, by the service-wide rate limit or because two of its own uploads overlapped, it waits, retries and loses nothing.
• It never loses count of a finding. A finding past the ceiling is folded into a count, never discarded uncounted.
• It never limits inspection or enforcement on the endpoint. The agent, its proxy, the Claude Code hook, the browser collector and the MCP wrapper inspect and enforce exactly as they would without these limits. What changes is what the agent uploads, and the shape of a few records, as described above.