Rungic

AgentOS in your hand.

A budget-friendly Android phone, a full Linux desktop computer, and an assistant that does the work for you.

_{“Make a little rocket in Blender and render it for me.” The whole task took about 2½ minutes; shown here sped up.}

Rungic turns a compatible Android phone into a real computer—a budget-friendly way to make more of the hardware you already own. It opens to the KDE Plasma desktop and runs desktop software such as Firefox, Blender, Krita and VS Code. Connect a TV and it becomes a desktop PC.

It also comes with an AI assistant that can see, speak and act. Tell it what you need, and it opens the apps and gets the job done while you watch.

Rungic is built for agents of your choice. The bundled assistant is a working demonstration and default implementation, currently powered by Codex. You can use another agent: the desktop, phone interfaces and system services are available independently of that choice. Integrating a replacement into the bundled assistant's voice, task and widget experience requires an adapter; there is no universal one-click switch yet.

Just say it

Hold the Home button and ask: “Make a little rocket in Blender and render it for me.” > “Install Krita for me.” > “Put your screen on the TV.” > “Send Mom a WeChat voice message: I'll be home for dinner.” The assistant lays out a plan first and tells you out loud how it is going. It opens apps, clicks buttons and types for you. When it is done, the pictures and files it made land right in the conversation, ready to open.

The assistant has its own screen

The assistant works on a desktop of its own, so your phone stays yours. Its screen floats in a small window you can resize, tuck against the edge, or send to the TV with one sentence. While it works in that workspace, its clicks and typing stay there. Keep using your phone meanwhile. When you have desktop mode on or are casting to a TV, it works right there on your desktop with you. You can also tell it where to work.

_{The assistant's screen at full size: Blender with the rocket it just built.}

Proactive intelligence: useful suggestions, at your pace

The first scope is system care: faults that need attention and known software compatibility or optimization opportunities. Rungic keeps a local record of the issue, its evidence, your decision and any investigation or repair task.

1. Notice what happened. Collect recent Linux crashes, failed services, incomplete package operations and low storage. Check installed software against the repository's compatibility knowledge base, using exact package versions and any recorded environment constraints. Intentional settings are preserved as policy rather than flagged for optimization.
2. Give it a useful place on the desktop. Suggestions appear in the assistant's Suggestions page and native Plasma home-screen widgets. The widgets leave the wallpaper, favorite apps and app drawer intact. Repeated evidence for the same issue is consolidated; related cards form a stack you can swipe up or down, with different groups shown separately. Tap a card to open that issue in the app.
3. Let you choose when to deal with it. Keep an issue for later, set a reminder or dismiss it. Notifications respect system inhibition and avoid repeating progress already shown to you; ordinary suggestions are throttled and wait for a suitable context. Results remain available to revisit.
4. Investigate before changing things. Hand a suggestion to the agent. Its result explains what happened, what the evidence supports, how certain the conclusion is and what to do next. Unknown causes remain unknown. Repairs require a proposed plan and your confirmation; approval is tied to the plan and evidence revision, so an outdated plan cannot silently be applied.
5. Verify and keep the history. Investigation, repair progress, issue status and reminder choices are tracked separately and survive service restarts. Completing an agent task does not by itself prove the underlying problem is fixed. Upstream feedback starts with a local facts bundle and a record of the issue or PR; external submission needs an explicit request, and an upstream merge does not establish that your installed version is repaired.

This is an implemented foundation with a deliberately bounded scope. It does not yet detect every Android fault or automatically determine whether every app is using hardware acceleration. Compatibility suggestions depend on reviewed knowledge entries, and automatic upstream PR submission and status synchronization are not implemented. The implementation and acceptance record separates device-tested behavior from remaining work.

You stay in control

• It asks first. Before it closes an app you are using, deletes or overwrites your files, or sends a message, it asks you.
• Your password stays yours. When something needs administrator rights, the system shows a password dialog on your screen. You type it; the assistant never sees it.
• No silent detours. If the plan hits a wall, it explains the options and what each one means, and you choose. It does not quietly settle for less.
• You set the rules. The assistant's guidelines and skills are plain text files in your home folder. Edit them and the change applies right away.

A real computer in your pocket

• A complete Linux desktop. Ubuntu 26.04 with KDE Plasma Mobile 6.6. Install software with apt, Flatpak or the Discover app store.
• GPU acceleration. The desktop, the browser and 3D software all run on the phone's GPU, including older X11 programs and Flatpak apps. Video decoding runs in hardware.
• Your phone's hardware. Speaker, microphone, front and rear cameras, a clipboard shared with Android, and Chinese input with Rime.
• Desktop mode and casting. Open the full desktop in a floating window, or cast it wirelessly to a TV and use the phone as its touchpad and keyboard.
• Smooth. Frames go straight to the display without copying, at up to 120 Hz while you touch the screen.
• System care. Home-screen suggestions surface faults and known compatibility issues for you to investigate and handle when convenient.

Desktop apps on the phone

Desktop mode in a floating window

_{The same desktop on a TV or in the floating window.}

Still your Android phone

Rungic opens as an Android app after the phone has been prepared. Device preparation starts with the manufacturer's original firmware for the exact model and version, with a matching GKI kernel rebuilt for LXC. Our delivery direction separates that preparation from installing RungicOS: once the Android base is compatible, Rungic can be built and updated independently. Android remains the phone's operating system, alongside the Linux desktop.

Once installation, account setup and device checks are complete, tap the Rungic icon to open the desktop, or return to Android to use your phone. Both environments run side by side, sharing the clipboard and your photos, videos and downloads. Bootloader unlocking or the required device-preparation procedure can erase user data. Separate Rungic installation is intended to preserve Android data; the new standalone installer still needs implementation and validation. Back up before starting; see Before you install for app and manufacturer restrictions.

How it works

flowchart TB
    subgraph container["Linux desktop (Ubuntu container)"]
        desktop["Plasma desktop and apps"]
        agent["AI assistant"]
        workspace["Assistant's screen"]
        agent -- operates apps --> workspace
        agent -. in desktop mode or when casting .-> desktop
    end
    app["Rungic Android app<br/>display · touch · sound · camera"]
    desktop --> app
    workspace --> app
    app --> phone["Phone screen"]
    app --> tv["Floating window and TV"]

Rungic does not replace the phone's operating system. Android keeps handling calls, networking, the camera and the rest of the hardware. The Linux desktop runs in a container, and the Rungic app ties together its picture, touch input, sound and camera.

The bundled assistant has two parts: a realtime voice model talks with you, and Codex runs tasks in the background. This is the reference integration; another agent can reuse the system capabilities described below.

Performance

Linux programs run at the phone's native CPU speed. The desktop is an LXC container on Android's own Linux kernel. There is no virtual machine, no emulator and no instruction translation: Ubuntu's ARM64 programs run directly on the phone's CPU cores, and the same kernel schedules them alongside Android's apps. The container only gives them their own namespaces (files, processes, users) and resource groups. What Rungic adds sits around the programs rather than under them: their picture, touch, sound and camera pass through the Rungic app, while their computation runs as on any ARM64 Linux machine.

Geekbench 7 on the same moto g100s, once as the Android app and once in Rungic's Linux desktop (comparison):

| Geekbench 7 CPU | Android (511001) | Rungic, Ubuntu 26.04 in the container (515585) | Rungic vs Android | |---|---:|---:|---:| | Single-core | 820 | 814 | 99% | | Multi-core | 2485 | 2563 | 103% |

• Same processor. Both runs report the same CPU (Snapdragon SM6435, 8 cores, processor ID part 3393) and 7.3 GB of memory. Geekbench names the phone "moto g57 power" on Android and "mumba", its codename, on Linux.
• Individual workloads.

• Limits of the comparison. One run each, with different Geekbench builds (7.1.0 on Android, 7.0.0 Preview on Linux) and different system libraries (Android's bionic, Ubuntu's glibc). Treat the overall result as parity, not a gain.

What makes it Agent Ready

Rungic gives an agent a place to work, tools to act, evidence to inspect and a way to deliver the result. These capabilities sit in the system and can be reused by different agents.

| What the system provides | What an agent can do | What you get | |---|---|---| | A real Linux environment | Run code and command-line tools, work with files, install desktop software through the package system | Finished documents, images, projects and installed apps | | Desktop control | Launch apps, inspect windows, take screenshots, click and type through desktop MCP tools | Work in existing graphical apps, including apps without an agent-specific integration | | An agent workspace | Work on a separate desktop, or use your desktop when requested | A visible work session that can run alongside your own | | Phone and desktop interfaces | Read device state, change brightness, use the shared clipboard and control casting through structured commands | Tasks that connect desktop software with the phone and its display | | Diagnostics and compatibility knowledge | Inspect available logs and crash evidence, check installed versions against known issues, propose a scoped fix | An explanation grounded in this device's evidence and software versions | | Persistent suggestions and task state | Pick up an issue, report investigation and repair progress, and record the outcome | Problems you can revisit and results you can review |

The bundled assistant shows how to connect these pieces: a request becomes a plan, visible actions, progress updates and files you can open from the conversation. The same foundations support development agents through diagnostic MCP tools and the repository's build and installation skills. Phone-side assistance and developer-side device management have different access requirements.

Agent choice and model choice are separate from these system capabilities. A replacement can use the Linux tools and supported MCP, command-line and D-Bus interfaces; its own execution, conversation and authorization behavior belongs to that integration. See the integration map for the reusable interfaces and the parts currently connected to Codex.

Interfaces an agent can use

Rungic exposes two MCP (Model Context Protocol) servers, alongside command-line tools, D-Bus services and standard Linux interfaces. MCP is one way to connect an agent; these capabilities do not require Codex.

| Interface | Entry point | What it exposes | |---|---|---| | Desktop MCP · on the phone | rungic-cua mcp | Screenshots, pointer/keyboard actions, app launch and window management, whole-task execution and voice messages. Workspace routing adds desktop_where; available tools depend on the selected execution mode. | | Development MCP · on the development computer | tools/rungic_agent_mcp.py, configured in .mcp.json | Device/renderer state, merged Android/Linux/kernel logs, crash reports and symbolization, integrity checks, screenshots, evidence bundles, UI inspection/actions, performance traces and build status. Requires separately configured device access. | | Phone control · CLI + JSON | rungic-platform --request '' | Device, network and display state; brightness, clipboard, orientation, vibration and Android settings panels. | | Workspaces and displays · CLI + JSON | rungic-workspace-env, rungic-user, rungic-agent-screen, rungic-desktop-mode, rungic-cast | Run in the selected desktop session, show the assistant's screen, control desktop mode, discover/connect TVs and inspect casting capabilities. | | Proactive system care · D-Bus + CLI | com.rungic.Suggestions, rungic-suggestions | Issue/evidence queries, compatibility knowledge, reminders, investigation results, repair plans and local upstream-feedback material. Task handoff currently targets the bundled assistant. | | Tasks, voice and usage · D-Bus | com.rungic.VoiceAgent; suggestion-service usage methods/signals | Conversations, task progress/stop, voice and call controls, observed tokens and provider-supplied quotas. Replacing the bundled agent requires adapting this bridge and its usage data. | | Files, packages and hardware · Linux interfaces | Shell/files, PackageKit/pkgcli, polkit, Wayland, desktop portals, AT-SPI, PipeWire/PulseAudio and Android-backed D-Bus services | Work with files, install software with system authorization, and use the same desktop/media/device interfaces as ordinary Linux apps. Android-backed services implement documented subsets. |

For MCP startup examples, the current tool inventory, D-Bus methods, session requirements and integration limits, see the Agent Ready interface reference. Low-level screenshot/action tools can use the connecting agent's own reasoning; the bundled desktop_goal helper has its own configured model backend. Display/input separation does not isolate the agent from files owned by the same Linux user.

Integrations

Bring your agent, keep your workflow. Rungic can provide the Linux desktop, apps, files and phone interfaces, while another project provides the conversations, agent runtime or collaboration space. You can use its Android or web client alongside Rungic, or connect its execution tools to the Rungic desktop.

These are integration paths to build on; the four combinations below have not yet been validated end to end on Rungic.

| Project | What it brings | How to combine it with Rungic | |---|---|---| | Lorca | Encrypted agent conversations, bot orchestration and paired devices | Use its Android client to talk to a paired runner. A further integration could run its Linux CLI inside Rungic and give bots access to the desktop tools; Lorca's phone client itself is not a runner. | | OpenMuse | A personal-agent app built with CopilotKit and AG-UI, with visible tasks, browser work and files | Use its Android or web UI alongside Rungic. A tool adapter could extend its agent workflows to Rungic's graphical apps and local files; its existing browser/terminal workspace is a separate backend. | | OpenClaw | A personal assistant reachable through messaging apps, with tools and skills | Connect its runtime to Rungic's desktop MCP and wrap phone commands in a skill or tool, so requests from your preferred chat can act on the phone's Linux desktop. See its MCP integration documentation. | | Raft | A shared workspace where people and persistent agents collaborate through channels, threads and tasks | Use its web client on Rungic. Integrating its machine daemon/computer runtime could make Rungic an execution machine for workspace agents, with access to local apps and project files. |

Running an agent locally requires checking its ARM64 dependencies and runtime requirements. Connecting one running elsewhere requires a bridge to Rungic's local tools; the desktop MCP currently uses stdio. Bringing its progress, suggestions and usage into Rungic's assistant and widgets requires a separate adapter. Start with the system interface reference and agent integration map.

Status

Rungic is under active development and in private preview. Still being polished:

• The interface follows the desktop's language (English and Chinese so far), and the assistant answers in the language you speak to it. Account setup and some technical documents are still in Chinese.
• Larger tasks, such as modelling in 3D, take the assistant about two minutes; work to speed this up is under way.
• The call agent, which makes and answers phone calls for you, is still being tested.
• Vulkan desktop rendering flickers on this GPU family, so the desktop uses OpenGL ES for now.

Supported devices

Rungic's architecture can be adapted to different phones. The Linux desktop runs in an LXC container sharing Android's kernel, and the Rungic app reaches the screen, touch, sound and cameras through Android interfaces.

For each device, we pin kernel sources and a build configuration matching its stock firmware, then enable the missing container capabilities, such as System V IPC, POSIX message queues, IPC/PID/user namespaces and devtmpfs. Keeping the manufacturer's drivers usable requires checking the rebuilt kernel's module ABI and signature trust, followed by testing on the device. Full flash packages also integrate root, the Rungic app and first-boot installation; their partition changes are recorded in the device's release manifest.

The current adaptation path requires:

• An unlockable bootloader and a supported root setup. Current device integrations use Magisk; eligibility and consequences depend on the manufacturer and device variant.
• A GKI kernel with matching sources and compatible vendor modules. Kernels built so far: android15-6.6 and android16-6.12. Other branches need their own adaptation and checks; the Android version alone does not establish compatibility.
• A Snapdragon chip with an Adreno GPU, for the hardware-accelerated desktop (Mesa's Turnip and freedreno on Adreno's KGSL driver). Phones with other GPUs need their own graphics work first.
• ARM64 and enough free storage for the Linux system.

Tested so far:

| Device | Kernel | Status | |---|---|---| | moto g100s (XT2537-4) | android15-6.6 | Main development device, most complete | | moto g100 (XT2533-4) | android15-6.6 | One-step flash package verified on a wiped phone | | moto X70 Air Pro | android16-6.12 | In progress |

Before you install

1. Make a complete backup off the phone. The previously validated full-flash path erases user data, and bootloader unlocking normally triggers a factory reset. Back up photos, files, contacts and messages, export app-specific data, and make sure you can restore access to your accounts. Device preparation and Rungic installation are separate operations; keeping the manufacturer's Android base does not make unlocking or a firmware reset preserve your data.
2. The goal is to retain normal Android functionality. Calls, messages, networking, cameras and other phone functions should remain available alongside RungicOS after adaptation and validation. This is a design goal, not a blanket guarantee for every phone or firmware. Check the device's acceptance record and release notes, including any selected preinstalled apps removed or disabled by its firmware profile.
3. Some apps may reject the modified device. Apps or their services can check root, bootloader state or device integrity and restrict access, even when Android itself works normally. For example, Play Integrity lets developers apply their own access policies. Such restrictions are imposed by the app or service; Rungic cannot guarantee that every app will accept the device. Other app failures still need diagnosis rather than being assumed to be security-policy restrictions.
4. Research the manufacturer's policies for your exact model and variant. Before unlocking or rooting, check eligibility, the required procedure, and whether protected features or update support will change. Some effects can persist after restoring stock firmware: Samsung's Knox documentation, for example, describes restrictions on Knox-dependent services after its Warranty Bit is tripped. This is a manufacturer-specific example, not a statement that Samsung devices are supported by Rungic.

Skills

Skills are reusable instructions that an agent reads to carry out a task. This repository includes two:

| Skill | Where to use it | What it does | |---|---|---| | rungic-three-stage-image | Codex working in this repository | Guides device/GKI preparation, independent RungicOS image builds, and separate Rungic installation or upgrades. Covers existing tools, implementation gaps and acceptance. | | rungic-phone-desktop | The assistant running on the phone | Operates desktop apps and windows, controls phone functions, casts to a TV and handles supported call workflows. |

The desktop skill ships with the bundled assistant. Its editable copy lives at ~/.codex/skills/rungic-phone-desktop/ on the phone; changes you make there are preserved when the package updates. These locations and invocation examples describe the current Codex integration. Other agents can reuse the instructions and underlying tools, adapting skill loading to their own format.

Choose what to build and install

Invoke $rungic-three-stage-image in Codex from the repository root, and specify the device/firmware spec, the work you want done and whether installation is included. The same skill supports the full workflow or a selected stage:

| Your goal | Build scope and output | Installation path | |---|---|---| | Prepare a phone for Rungic | CI1: the spec's pinned GKI/boot, required Android-base preparation and recovery artifacts, ABI/module-trust reports. | Use the device's verified preparation procedure. Reuse an already compatible base; repeat only when its requirements change. | | Build the Linux system image | CI2: install a selected package release in a clean ARM64 root tree; produce ext4 rootfs, compressed payload, package lock and report. | Deliver independently of Android firmware. The standalone first-install path is being defined; existing installations can use package updates below. | | Install or upgrade Rungic separately | CI3 target: combine verified rootfs, APK and required host runtime with version/protocol checks and an installer. No Android partition images in the normal Rungic payload. | Install on a compatible prepared phone. The unified standalone installer and full-rootfs replacement path are not yet implemented and accepted. | | Update desktop or Agent components on an installed phone | Build the changed packages and a versioned APT release; keep the compatible kernel and Android base. | Deploy through rungic_release.py, reload affected services/UI and run the relevant acceptance checks. |

Example requests for Codex — replace the placeholders with your chosen inputs:

Use $rungic-three-stage-image to run CI1 only for <device-spec>.
Build the kernel/boot candidate and check its OEM module compatibility.
Use $rungic-three-stage-image to run CI2 only for <device-spec>, using
<package-release>. Produce a clean RungicOS rootfs image and package lock.
Use $rungic-three-stage-image to assess CI3 for <device-spec> and
<verified-rootfs-artifacts>. Check the prepared Android base, identify
missing standalone-install tooling, and define first-install and upgrade acceptance.

For installation, name the exact artifact and target device/serial, and distinguish first install from upgrade. A build request produces artifacts; it does not flash the phone. Rungic installation should preserve the existing Android base and user data; any necessary bootloader or firmware work belongs to the separate device-preparation step. The Linux rootfs shares Android's kernel and is a container filesystem image, not an Android system.img.

For incremental work, a request such as “Build and deploy the updated suggestion widget to my existing Rungic installation on , then verify its desktop interactions” selects the package-update path. Project packages use rungic_package.py; modified upstream packages use build_on_device.py.

These skills guide the existing build tools; the complete process still involves several tools and device-specific inputs. In particular, build_rootfs_image.py packages an already prepared root tree and checks its package versions. See the tool map for stage entry points, new-device guide for adaptation, and first-boot guide for installation and recovery. The current delivery contract separates device preparation from Rungic installation. The G100 acceptance record documents the older full-flash path; it does not establish acceptance of the new standalone installer. Legacy full-flash tools remain for explicitly selected recovery or reproduction work. These detailed engineering guides are currently in Chinese.

Learn more

• Source layout: Android host, agents, desktop integration, system services, package definitions and upstream patches
• Developer guide and documentation index: repository layout, development entry points, and the design and acceptance documents for each capability
• Integrating another agent · Proactive system care · Compatibility knowledge
• Voice assistant · Computer use · Assistant's screen · Agent workspaces (in Chinese)
• Engineering conventions (in Chinese)