KINGAI OS AI Workstation

What AI Workstation is for

AI Workstation is aimed at people who develop and run models locally, keeping compute and data on their own machine. It is still in planning, so this page describes direction, not a feature list.

Design direction

• GPU runtimes (NVIDIA, AMD, Intel) join the supported list only after passing on real hardware; nothing is promised up front
• Models are installed by the user, who manages their sources and licenses; nothing comes preinstalled
• Agents run in rootless, isolated environments with separately granted permissions
• Hardware and VRAM status views, plus offline-friendly workspaces (planned)

See the four-edition roadmap →　See the published Desktop preview →

Positioning: models run locally, decisions stay with the user

AI Workstation is being prepared for people who develop, debug and run large models on their own hardware — people who do not want their data leaving the machine, who would rather account for compute costs themselves, and who dislike having a workflow bound to one cloud platform's API. The official catalog describes the audience exactly that way: user-controlled local model development and GPU-enabled AI workflows.

One principle runs through this edition and deserves its own paragraph: AI is optional, not system authority. The system will not preinstall models, will not bundle a model provider, and will never let an agent component sit above the user's own permissions. Which model, downloaded from where, under what license, on which runtime — the user decides, and the user is responsible. The system's job is the three pieces of infrastructure underneath: environment, isolation, and visibility into what the hardware is doing.

The planned capabilities, unpacked

GPU runtimes: supported means tested

GPU runtimes for NVIDIA, AMD and Intel are all in the plan, under an only-when-tested rule: a card on a given kernel version earns its place on the compatibility list by passing on real hardware, and untested combinations are promised nothing. This is the hardest of the release gates, because GPU driver problems only ever surface on physical machines.

A driver compatibility matrix

Verified combinations — which card, which driver version, which kernel — collected into one lookup table, so you check the matrix before buying hardware instead of discovering a mismatch after installation. The table does not exist yet; it has to be earned from test data.

Models installed by the user, provenance recorded

Local models and cloud API providers are both connected by the user. Planned provenance records exist so you can later answer where a model file came from and what license it carries — not so the system can choose for you.

Rootless, isolated agent execution

Agents run in rootless, isolated environments, with permissions granted individually, and sandbox escape gets negative testing: testers actively try to break out, and the gate only passes when they cannot. Local execution power for AI tools is only acceptable inside a fence that holds.

Hardware and VRAM status views

GPU utilization, VRAM occupancy and temperature, visible at a glance. On a long inference job, seeing memory fill up beats finding the process silently killed at 3 a.m. Quota controls are planned too, to put real resource ceilings on long-running tasks; the exact shape waits for implementation.

Offline workspaces and privacy controls

Workspaces must keep working offline: code still edits, local inference still runs. The privacy direction is that users can see what each component is allowed to touch, rather than taking a statement on faith.

Release gates: five tests stand between this page and an ISO

• Compatibility verified per real GPU model and kernel version
• Model license and legal testing — redistribution and use boundaries for model files settled first
• Consent-boundary testing — no data leaves the machine without an explicit user consent action
• Thermal and VRAM stability — sustained full-load runs without throttling collapse or memory blowouts
• Sandbox-escape negative testing — the isolation has to withstand deliberate attack attempts

Current progress, stated plainly

Publicly: planned, with no version number and no ISO. The official catalog's words: GPU and driver support are not claimed, and preinstalled model runtimes are not claimed. The internal experimental line has an amd64 build record in the Debian 13 KDE developer-environment direction, explicitly without model or driver promises; the image was not retained and received no firmware boot validation. Between that record and a workstation that runs your models sits the entire gate list above, and this page is not celebrating early.

See the four-edition roadmap →　See the published Desktop preview →　Go to downloads →　Follow progress in Issues →