Planned capability · not shipped
PenGuru is a roadmap target, not a finished autonomous repair feature. Nothing on this page installs, loads, or enables a model. It describes the intended system so the privacy, permission, and rollback boundaries are clear before implementation begins.
More than a chatbot
PenGuru is not meant to be another chatbot that simply answers questions. The idea is to connect a local language model to controlled access to Nuxel's own system interfaces—so it can inspect, explain, prepare, and act within boundaries the owner defines.
A local model running on a Linux phone is not unique by itself. What makes PenGuru different is the combination: an assistant that understands its own operating system, can operate it on the owner's behalf, and can prepare new functionality for approval.
Think of it as a personal operating-system engineer living inside the phone. It can suggest almost anything, but it should only change what its owner authorizes.
PenGuru is an installable, removable AI subsystem. It is off by default, and Nuxel should not even load the model or start its service until its owner enables it.
Local inference is the default path. No cloud account is required, and network access for AI features is a separate switch that starts off.
Chats, diagnostics, and approved actions remain on the device. PenGuru is designed around local models rather than a mandatory remote service.
PenGuru understands Nuxel itself: its services, settings, diagnostics, files, network state, and resource measurements. It is not a generic assistant bolted onto a phone.
The owner approves what PenGuru may do. Explicit scopes, per-action approval, audit logs, sandboxing, and rollback are part of the design—not afterthoughts.
The distinctive feature
Imagine telling your phone: “PenGuru, I wish Nuxel had a way to automatically switch to silent mode when I arrive at work.” Instead of merely explaining how to do it, PenGuru could take a controlled path from request to approved installation.
PenGuru finds the Nuxel location, audio, and scheduling interfaces that a proposed automation would need.
It explains the workflow it wants to create and the exact permissions that workflow requires.
The necessary service or extension is prepared in an isolated environment rather than dropped straight into the running system.
Unit tests and a review pass show what the change does, what it does not cover, and what it would touch.
Nothing is installed or activated until the owner reviews the proposed change and explicitly authorizes it.
After approval, PenGuru can enable the feature, watch its behaviour, and offer one-tap rollback if something is wrong.
The same model could support custom Quick Settings toggles, automated backups, battery optimizations, application shortcuts, and personalized workflows. Each one follows the same pattern: inspect, propose, prepare, test, approve, activate, monitor, and roll back.
Version one
The first useful PenGuru should prove that local intelligence can operate a real Linux phone safely. Version one would prioritize five operations that are valuable, auditable, and narrow enough to verify.
Read real CPU activity, memory pressure, running services, battery measurements, and wake behaviour instead of giving generic advice.
Adjust supported Nuxel settings through normal APIs, with a clear preview and an explicit scope for each change.
Find, inspect, organize, and operate on owner-approved files without handing over unrestricted system access.
Create private, on-device automations that run only within the permissions the owner grants them.
Inspect service state and logs, identify a failing step, and propose a repair that the owner can review first.
That would already be a compelling demonstration: ask the phone why something is not working, and let it inspect its own Linux services before suggesting a specific fix. The larger opportunity comes later—when the owner can describe a missing feature and PenGuru helps create it without taking control away from the owner.
PenGuru Control Center
Control is the defining principle. PenGuru is designed as an installable AI subsystem with visible switches, explicit scopes, and a separate privileged broker for sensitive actions. These are design targets for an interactive settings surface—not live controls on this website.
Installable and removable AI subsystem. Off until explicitly enabled.
Off by default. Local inference should not need a cloud round trip.
Runs only the workflows the owner explicitly approved.
Generates changes in an isolated environment before review.
Only within authorized scopes, with a visible change plan and rollback.
The critical design decision is that PenGuru never needs unrestricted root access to be useful. Normal operations go through APIs. Sensitive actions go through a separate privileged broker. Generated code is treated as untrusted until it is tested and approved.
Audit logs make actions reviewable after the fact. Rollback makes approval reversible. Neither replaces the owner's decision before a change is applied.
Guiding rule: “PenGuru may suggest anything, may prepare what it can verify, and may change only what its owner authorizes.”
Architecture
PenGuru is designed as a stack, so the model never talks directly to the kernel. Each layer has a narrower job and a clear permission boundary.
Chat, troubleshooting, automation requests, and a future dashboard.
llama.cpp with GGUF models, configurable small models, and no mandatory cloud API.
Explicit scopes, per-action approval, sandboxing, audit logs, and rollback.
Services, diagnostics, files, settings, network state, and resource metrics on Fedora ARM64, systemd, and Wayland.
A useful way to read the stack: the model proposes, the broker decides what is allowed, and Nuxel performs only the operation the owner approved. The OS is the platform—not a prompt the model is free to rewrite.
Can the phones run it?
The plan starts with small, quantized 1–2B parameter models running primarily on the Exynos 9820 CPU through llama.cpp. Larger models may be possible with trade-offs, but speed, power, and memory must be measured rather than assumed.
| Model class | Q4 weights | Practical use |
|---|---|---|
| 0.5–1B | 0.4–0.9 GB | Commands, classification, simple automation |
| 1.5–2B | 1–1.6 GB | Stronger instructions and tool calling |
| 3–4B | 2–3 GB | More capable assistant and basic coding |
| 7–8B | 4–6 GB | Heavy reasoning; likely uncomfortable on the S10+ |
These are approximate Q4 model-weight sizes, not total runtime RAM. KV cache, context, system processes, and runtime buffers add memory usage.
How far self-improvement goes
There is a meaningful difference between an AI customizing its environment and an AI safely upgrading its own operating system. PenGuru's roadmap should be explicit about that gap.
There is also an important distinction between improving Nuxel's functionality and training or modifying the language model's own weights. The former can be practical through code generation and tool use. The latter is resource-intensive and should not be something the phone does by default.
Rollout
PenGuru should earn additional authority as its boundaries are proven. Each stage is a target, not a delivery guarantee, and the next stage does not begin by assuming the previous one is safe.
A completely optional, local model runner. No mandatory cloud account, no autonomous actions.
Inspect health, change settings, manage files, schedule local actions, and diagnose service failures.
Generate changes with unit tests, sandboxing, permission review, and rollback before installation.
A Nuxel development assistant that may suggest anything and prepare what it can verify—but change only what the owner authorizes.
Why PenGuru belongs in Nuxel
PenGuru is one part of a larger Nuxel idea: an independent Linux userspace that controls real phone hardware, stays open to inspection, and keeps the owner in charge.
Nuxel began as an experiment in how far autonomous AI could go, with QonQrete generating the initial OS architecture and code.
Debug and update the running phone from a laptop without reflashing for every userspace change. The console starts before normal systemd startup.
Nuxel's application-store project, with signed-bundle verification, package staging, and a future Flatpak integration path.
Planned compatibility profiles for device-specific hardware and behaviour, so one Nuxel environment can support different phones honestly.
Direct Linux access, open-source design, userspace updates, backed-up files, hashes, and rollback instead of a full reflash for every UI fix.
The bigger opportunity
Nuxel could become a Linux phone where the owner is not stuck waiting for the OS developer to add every missing feature. The owner describes what they want, and PenGuru helps create it—while the owner retains control over what gets installed or executed. That is a stronger differentiator than simply bundling a small language model.
Questions
Straight answers about a planned capability. Nothing here is a promise that an autonomous repair feature exists today.
Suggest anything · prepare what it can verify · change what you authorize
PenGuru depends on the same release gates as the rest of Nuxel. Read the roadmap for the target order, or inspect the project and its open work on GitHub.