Why I Stopped Asking LLMs to Read Log Files

Try giving a million-line log file to a modern AI assistant.

It won’t actually read the entire file into the model. Instead it will usually sample, chunk, grep, write Python, or otherwise build a traditional data-processing pipeline around the model.

That’s perfectly sensible, but it made me wonder: if we’re going to build a data-processing pipeline anyway, why not make that pipeline the primary product and let the LLM focus on explaining the results?

The Idea

Olorin is a local AI assistant built around a simple rule:

The model should not be the thing doing the analysis.

Instead, specialized SIMD kernels do the heavy lifting and the language model only explains the results.

If I want to understand a large log file, I don’t want a language model trying to read gigabytes of text token by token. I want a program that can scan the file at gigabytes per second, extract the information that matters, and then hand a small summary to the model.

In Olorin those specialized commands are called runes.

A rune is a deterministic SIMD pipeline for a specific data shape.

Some examples:

• eatime scans timestamps and builds activity histograms.
• ealog summarizes log severities.
• eajson analyzes JSONL files.
• eacrunch summarizes CSV datasets.
• eadiff compares structured outputs from previous runs.

The output is a stable schema called RuneOutput.

Only after the rune finishes does the language model get involved.

A Real Example

I recently added spike detection to eatime.

The command scans timestamps from log files and groups them into chronological buckets. A robust median/MAD baseline is calculated and unusual activity spikes are flagged automatically.

Running on a Raspberry Pi 5:

/rune eatime --bucket series /tmp/access_clf.log

timestamps:  1292
buckets:     72
scan:        0 ms
span:        2026-06-10T00:08:36 .. 2026-06-12T23:08:36
peak bucket: 2026-06-11T14:08:36 (342 timestamps)

anomalies:   2 spike(s) detected
  2026-06-11T13:08:36 count=79  (4.5× baseline 18)
  2026-06-11T14:08:36 count=342 (19.5× baseline 18)

The SIMD pass took about 700 microseconds.

Only then does the model see the result:

Significant spikes in activity were detected during this period, with
one time frame showing nearly twenty times the normal volume. The
busiest moment occurred during the afternoon of June 11th.

The model never saw the log file. It only saw the analysis.

Just Drop the File

The command line is nice, but I wanted to see how far the idea would stretch, so I wired runes into the web UI. Now you drop a file onto the chat and Olorin picks the right rune, runs it, and explains what it found.

To push it, I dropped a 1 GB access log on it — the classic NASA-HTTP log from 1995, scaled up to a gigabyte running on the same Raspberry Pi 5.

the classic NASA-HTTP log from 1995, scaled up to a gigabyte.”

9.5 million timestamps, scanned in 755 milliseconds. A real traffic spike flagged automatically, on July 13th. Then one sentence from the local model explaining it.

A gigabyte of logs, understood on a Pi in about the time it takes to blink. No cloud. The file never left the machine.

You can drop several files at once, too — a CSV, a log, a JSONL — and it runs eacrunch, eatime, and eajson on them, each rune picked automatically. Three different SIMD kernels in one drop. Asking the little model to tie all three together in a single sentence, though, turned out to be a step too far: it summarizes one analysis cleanly, but hand it three dense results at once and it starts reformatting tables instead of explaining. The kernels scale. The narration doesn’t, quite.

multiplexes the files to their respective SIMD kernels (eatime, eajson, eacrunch), summarizes close to half a million records across three different data layouts in a fraction of a second.

The Part I Didn’t Expect

Once the runes worked, the obvious next step was to let the model drive them itself — real tool-calling, where it decides a file needs analyzing, runs the command, and chooses what to do next. That’s the thing everyone is chasing right now.

On my x86 development machine, it worked every time. On the Raspberry Pi, it never worked.

Same model file, same prompt, same settings. The only difference was the CPU. It turns out x86 and the Pi’s ARM chip compute the same network with tiny last-bit differences in the math — each technically correct, but they pile up across the model’s layers into a small difference in the final answer. On my dev box that nudge was harmless. On the Pi it was just enough to tip the model’s “should I call a tool here?” decision the wrong way. I measured it: 16 of 16 tool calls worked on x86, 0 of 16 on the Pi.

The model itself was fine, it answered questions and explained rune output perfectly on the Pi. The one thing it couldn’t do reliably was decide.

And that turned out to be the strongest argument for this whole approach. On small local hardware you sometimes can’t make the model the decision-maker even when you want to. So I stopped trying. The user’s action decides instead, you drop a file, and that gesture is the instruction. The pipeline runs; the model explains.

Not because it’s elegant. Because it’s the part that actually works on a Pi.

Why This Matters

Modern LLMs are impressive, but they are not particularly efficient data-processing engines.

If you hand them a huge file, they either:

• Cannot fit it into context.
• Need an external tool.
• Need generated code.
• Need multiple passes over the data.

At that point the language model has become an expensive orchestrator around a traditional data-processing pipeline.

Olorin flips that relationship around.

The deterministic pipeline comes first.

The language model comes last.

The result is surprisingly practical on small hardware. The entire system runs locally on a Raspberry Pi 5, including the SIMD kernels, inference engine, storage, web UI, and the Gemma 4 model.

No cloud services.

No external agents.

No Python notebooks.

Just a pile of SIMD kernels and a language model that knows how to explain what they found.

Building the Extra Muscle

Originally Olorin already had several runes for logs and structured data.

Over time I found myself wanting more and more domain-specific capabilities because every time I gave Olorin a new SIMD primitive, the local model suddenly became useful on larger datasets.

Instead of asking:

Can the model understand this file?

The question became:

What kernel should understand this file?

That has turned out to be a much more productive way of thinking about AI systems, especially when the target machine is a Raspberry Pi rather than a rack full of GPUs.

Closing Thoughts

I don’t think LLMs are replacing traditional software.

I think they’re much more interesting when paired with traditional software.

The model is great at explanation, summarization, and interaction.

The computer is still much better at counting things.

Olorin is an experiment in taking that idea seriously.

And so far, it has been a lot more fun than watching an LLM install pandas for the thousandth time.

Olorin is open source and available on GitHub. If you’re interested in minimal-dependency architecture or high-performance local AI, I’d love for you to check it out

petlukk/Olorin