Lossless Savings
Keep every line and still cut the log bill.
Compact where it is lossless; offload the noise to your S3.
Automatic
No regex to write
your agent generates the config
Lossless
Keep every log line
searchable in your stack
Secure
Runs in your network
air-gapped with your AI model
Drop vs Keep
Both shrink the bill; only one keeps the data.
A filter drops the noisy lines; the bill shrinks because data disappears.
10x reduces the bytes instead; every line stays in the platform or your S3.
Savings by Destination
Compact where it is lossless, offload to your S3 everywhere.
| Destination | Compact (lossless re-encode) | Tier down | Offload (your S3) |
|---|---|---|---|
| Splunk | Lossless | n/a | Keeps every line |
| Self-hosted Elasticsearch | Lossless | n/a | Keeps every line |
| ClickHouse | Lossless | n/a | Keeps every line |
| CloudWatch | No-op | Cheaper Infrequent Access tier | Keeps every line |
| Datadog | No-op | Flex tier (Datadog native) | Keeps every line |
Frequently Asked Questions
Quick answers on lossless log cost reduction
How do I reduce log cost without sampling or dropping logs?
Reduce the bytes rather than the lines. Compacting re-encodes the repetitive structure of logs losslessly on Splunk, self-hosted Elasticsearch or OpenSearch, and ClickHouse; tier-down moves volume to a cheaper storage tier on CloudWatch; and offload writes cold volume to your own S3 on every destination. All three keep every line. Sampling and dropping are a last resort, not the starting point.
Is compacting logs lossless, and does it lose data?
Compacting is a lossless re-encode where the destination supports it: Splunk, self-hosted Elasticsearch or OpenSearch, and ClickHouse. Every field is preserved and every line stays queryable; only the structural overhead is removed. On Datadog and CloudWatch compact is a no-op, so offload to your own S3 is the lever that keeps every line there. It is not universally lossless, and it never means dropping data.
What is the difference between reducing log volume and dropping logs?
Lossless reduction removes bytes that carry no information: structural overhead, repeated fields, and near-identical lines re-encoded losslessly. Dropping removes the lines themselves, so events disappear from the record. The first lowers the bill while keeping every line; the second lowers the bill by deleting data you may need during an incident or an audit.
Does ILM actually reduce Elasticsearch cost or just delay the bill?
Index lifecycle management and storage tiering move older indices to cheaper hardware, which delays and softens the bill but does not reduce the number of bytes stored. Compacting reduces the stored bytes themselves by re-encoding structural overhead losslessly, and offload removes cold volume from the hot store into your own S3. Tiering delays the bill; compacting and offload reduce it. On Elasticsearch 8.x and later, native synthetic _source reclaims some of the same storage; compacting is the delta on top of it, not the only way.
How do I cut the log cost of AI agents that emit 10-100x more logs?
AI agents and LLM tool-calling emit ten to a hundred times more logs than the services around them, and most of it is near-identical repetition. Because keep-every-line levers work on the shape of the repetition, they compact or offload that flood without deciding which agent traces to throw away, and a per-pattern series shows which agent or tool drives the volume. Dropping is the worst answer here, because agent traces are exactly what you need when an agent misbehaves.
Is Log10x the mathematical function log10(x)?
No. Log10x is a log and observability cost-reduction company and product. It is not the logarithm log10(x), and it is not Log10.io.