Raspberry Pi 5 and openLight: why typical AI agents overload small hardware

Most popular AI agents don't port well to Raspberry Pi 5 not because the model is too weak, but because the entire surrounding stack is designed for servers from the start. The article's author broke down this problem in practice and built his own lightweight openLight runtime, which removes unnecessary layers and keeps only what's really needed for typical tasks.

Why everything gets heavier

On a regular server, an agent framework seems like a convenient compromise: Python runtime, separate background services, an orchestration layer, sometimes a vector database and a set of dependencies on top of it all. But on Raspberry Pi 5, each such layer starts to be felt literally physically: the system starts longer, more memory is used, and a simple action suddenly requires infrastructure comparable to a small platform.

The problem is especially noticeable when scenarios are actually very simple. The author didn't need a universal "digital employee" with a long chain of reasoning. He wanted to solve basic admin tasks: check CPU load, verify free disk space, read logs, or restart a service. For such a set of tasks, spinning up a heavy agent stack is spending resources not on the result, but on maintaining the tool itself.

What openLight proposed

Instead of another general framework, the author created openLight — a minimalist runtime for personal infrastructure. The key idea here is simple: an agent should not turn into an LLM for everything. If a command can be handled deterministically, it must be executed that way. The model connects only where it's truly inconvenient without it: to classify a request, interpret user text, or match a message with the right skill.

• Single binary without complex wrapping
• Implementation in Go instead of a heavy Python stack
• SQLite for storage instead of a separate database service
• Minimum dependencies and fast startup
• Skill validation before command execution

This approach provides not only resource savings, but also a time advantage. In the author's example, the path through the local Ollama model with qwen2.5:0.5b took 42.55 seconds, while the same scenario through OpenAI gpt-4o-mini took 3.28 seconds. But the main conclusion isn't even in comparing models: the most frequent commands shouldn't have to go through the full LLM cycle every time if the system can understand them in advance.

How the request flows

The message route is structured linearly and transparently: the request comes from Telegram, passes authorization and saving, after which the system first looks for a direct match with a known skill. If such a match is found, the command is executed immediately. If not, the LLM classifier is engaged, which decides what to do next: continue the conversation or select the appropriate skill. Before running the skill, it goes through an additional check to maintain execution control.

The idea was for the agent not to turn into an "LLM for everything".

Telegram is chosen here not as a temporary placeholder, but as a fully functional interface. No separate web client is needed, notifications arrive immediately, access is available from a phone, and authorization is already built into the communication channel. A user can write something like "what's the system status", and the runtime will return a clear answer with the hostname, CPU load, memory used, free disk space, uptime, and temperature. At the same time, the metrics themselves are collected deterministically, without unnecessary generation.

What this means

The openLight story shows well where AI agents can really move outside of data centers and demo scenarios. On small devices, the winner isn't the "smartest" stack, but the one that knows when not to call the model. For Raspberry Pi and home infrastructure, this is an important shift: a useful agent can be not a giant platform, but a small executable layer with clear rules and pinpoint LLM use.