Analytics  ·  AI & Log Data

The most expensive way to read a log file.

Feeding raw license logs straight into an LLM is both the wrong tool for the job and a fast way to set fire to your token budget. Here's the math — and why work like this belongs to a different kind of system.

qformative Team9 min readAI & Analytics
ONE 1 GB LICENSE LOG ≈ 250,000,000 tokens LARGEST CONTEXT WINDOW ≈ 1,000,000 tokens The log is about 250× too large to fit — not 250% over, 250 times over.

It has never been easier to say a dangerous sentence: "Let's just feed the logs to the AI." In the age of vibe coding it sounds almost reasonable — drop the file into a model, ask for the usage report, done. For license and engineering logs, it is one of the most expensive wrong turns a team can take. Not expensive as in slightly pricey. Expensive as in a five-figure annual bill for answers you cannot trust.

The appeal is understandable, so it's worth being precise about why it fails. It fails in three places at once: the data won't fit, the answers come back wrong, and the meter never stops running.

Watch · the 90-second version
Why LLMs fail at log analysis — a short explainer.

01 / A LOG IS NOT A DOCUMENTYou don't read it. You measure it.

Large language models are astonishing with language. Ask one to explain a regulation, draft a note, or summarize a contract and it shines. So the instinct to point one at a log feels natural — it's "just text," after all. But a license log is not prose. It's a machine-generated ledger of millions of near-identical events, and the questions you need answered from it — peak concurrent usage, denial counts, idle seats, utilization over time — are questions of exact arithmetic, not reading comprehension.

Answering "what was our true peak concurrency in Q2?" means counting overlapping events precisely, across the entire span, with no rounding. Models are built to find meaning and pattern, not to act as a calculator over ten million rows. Asked to tally at that scale, they approximate — and approximation is exactly what you cannot afford when the figure ends up in a renewal negotiation.

There's a deeper mismatch underneath. A model's great strength is generalization — smoothing thousands of examples into a plausible whole. Measurement demands the opposite discipline: every event counted once, exactly, with the outliers preserved rather than averaged away. The very instinct that makes an LLM fluent with language is what makes it unreliable at bookkeeping.

02 / IT DOESN'T EVEN FITThe context-window wall.

Start with the most basic obstacle: size. As a rough rule, a model sees about four characters of text per token, so a one-gigabyte log lands somewhere near 250 million tokens. The largest context windows on the market today top out around one million tokens. That log is roughly 250 times too big to fit — and this isn't a "buy a bigger window" problem, because no window remotely large enough exists.

The usual workaround is to slice the log into hundreds of fragments and feed them through one at a time. But that quietly destroys the very thing you were trying to measure: peak concurrency, session lengths, and trends all span the boundaries between fragments. Cut a log into 250 pieces and the cross-cutting questions become unanswerable by construction — each slice can only see its own little window of time.

03 / THE NUMBERS IT RETURNS ARE WRONGConfident, and quietly off.

Suppose you push through anyway, chunk by chunk. The numbers that come back will be confidently, subtly wrong — for three independent reasons.

RECALL ACROSS A LONG CONTEXT start of file end of file events missed here high recall
"Lost in the middle": a model can hold the whole log and still overlook what's buried in the bulk of it — with no error to warn you.

Models hallucinate: ask for an exact count over a massive input and you'll get a plausible figure that doesn't match reality. They suffer from "lost in the middle": recall is strong at the start and end of a long context and sags badly through the middle, so events buried in the heart of the file are simply overlooked — silently. And they're non-deterministic: run the same analysis twice and you can get two different answers.

A parser returns byte-identical results every time. A model returns a vibe. For an audit or a CFO slide, "a different number on Tuesday" is its own kind of failure.

04 / NOW, THE BILLSet accuracy aside and just watch the meter.

Feeding tokens to a frontier model costs roughly one to five dollars per million input tokens at mid-2026 published rates across Anthropic, OpenAI, and Google. Run that against a single analysis — input only, at a representative mid-tier rate of about three dollars per million tokens:

COST OF ONE ANALYSIS · input only · ~$3 / M tokens LOG SIZE ≈ TOKENS COST / RUN 100 MB25 M~$75 500 MB125 M~$375 1 GB 250 M ~$750 5 GB 1.25 B ~$3,750 …and that's per run, output not included, before re-runs.
And these are the gentle numbers — input only, single pass. The context limit forces hundreds of overlapping passes that re-send context and multiply the total.

Now remember that license monitoring isn't a one-time read — it's continuous. Analyze a single site's gigabyte of logs every working day and you're looking at roughly $190,000 a year in tokens alone. Even a weekly cadence runs near $40,000 a year — for one site, for numbers you've already established you can't trust. Choose the premium model and the figure climbs by half again; choose the cheapest and you've simply bought wrong answers at a discount.

05 / THIS IS STRUCTURAL, NOT A SETTINGYou can't prompt your way out.

The reflex is to assume a better prompt or a bigger model fixes all this. It doesn't. Finite context, weak exact-aggregation, lost-in-the-middle recall, non-determinism, and per-token billing are properties of how large language models work — not bugs to be tuned away. A larger context window simply raises the ceiling before the same failures reappear; it does not make a model reliable at counting ten million rows, and it makes the token bill bigger, not smaller. This holds across every major model — Anthropic's, OpenAI's, Google's alike. The right conclusion isn't "use a different LLM." It's that exact measurement over massive logs is the wrong job for an LLM, full stop.

What makes this genuinely hazardous is that every one of these failure modes hides at the surface. The output looks like a clean, confident report — so the errors never announce themselves. They simply wait until someone downstream acts on a number that was never real.

06 / WHERE ROIQ FITSThe math is solved before AI ever sees it.

None of this means AI has no place in license and engineering analytics. It means AI has the wrong job if you point it at the raw log. The distinction is the entire premise of how ROIQ is built.

Where ROIQ fits

A hybrid model, by design.

ROIQ runs on a hybrid approach: deterministic analysis reads the full log exactly — at any size, for a fixed and trivial cost — and owns every number behind both your usage analytics and your forecasts. The AI layer is reserved for what it's genuinely good at: explaining what those numbers mean. You get figures you can put your name on, predictability you can plan around, and a bill that doesn't move when your logs grow. The how, we'll keep to ourselves.

07 / THE BOTTOM LINEAI belongs in the system — not holding the calculator.

"Just feed it to the AI" is the most expensive way to read a log file yet invented: it doesn't fit, the answers are wrong, and the meter never stops. The questions a license log actually has to answer — how much did we use, where are we constrained, what should we renew, what comes next — deserve a system that measures rather than guesses.

AI has a real and valuable place in that system. It just doesn't belong holding the calculator.