Device and model support | Arcane OS Docs

Arcane OS is building an active physical-validation program for commercial off-the-shelf (COTS) devices, from Android phones and everyday laptops through high-memory workstations and servers. This page is the public support ledger and test plan. It does not turn an untested model or device into a supported product.

Development-only boundary: A model is validated only for the exact device, operating system, runtime, model digest, quantization, context length, and concurrency that were tested. Parameter count, download size, advertised RAM, an AI-PC label, or catalog availability does not prove that a model fits or performs acceptably.

Runtime admission does not use this page's representative device names. An app-scoped Core evaluates actual installed model bytes and metadata, requested context and K/V-cache cost, current free system/GPU memory, loaded-model residency, safety reserves, and pull storage when applicable. Missing evidence fails closed. The renderer displays Core's admitted catalog without its own device, model-size, or GPU-name filter.

How to read the status

Managed variant means the platform or an application package has a checked-in Modelfile, exact alias, selector mapping, provisioning contract, and focused tests.
Live development evidence means a bounded pull, create, lineage, or inference exercise ran on a development host. It is not a COTS device-class acceptance result unless the evidence binds the complete device and runtime configuration.
Validation target means Arcane intends to test that model class or device class, but it is not an installable managed variant or accepted configuration yet.
Not available means the current platform bridge or application package does not expose that local-model path.

Arcane uses edge through large open-weight models for this program. The word “frontier” is not inferred from parameter count alone.

Managed model matrix

The active validation scope covers 3B, 8B, 12B, 16B, 20B, 26B, 30B, and 120B classes. Application-owned variants remain in their owning package policies rather than this OS-level support ledger.

Model class	Platform status	Current evidence
3B	Managed platform variant; application packages may declare additional variants.	A bounded Microsoft NT development-host pull/create/inference exercise passed, but no COTS class has an accepted receipt yet.
8B	Managed platform variant; application packages may declare additional variants.	A declaration or saved preference is only a candidate until Core admits the exact installed model. No public exact-device acceptance receipt.
12B	Managed platform variant; application packages may declare additional variants.	No public exact-device acceptance receipt.
16B	Validation target only.	There is no platform Modelfile, alias, selector, or provisioning contract.
20B	Managed platform variant; application packages may declare additional variants.	Historical development-host evidence does not establish a COTS device class.
26B	Application-owned variants may exist; there is no platform variant.	Historical development-host evidence does not establish a COTS device class.
30B	Validation target only.	There is no platform Modelfile, alias, selector, or provisioning contract.
120B	Managed platform variant; application packages may declare additional variants.	Selection requires current Core admission from the exact working set and available resources. No public 120B inference acceptance receipt exists.

Platform integration

Platform	Local-model integration	Current public status
Microsoft NT / Windows kernel platforms	Arcane can install and repair the machine-wide `ArcaneOllama` service, protect its shared model store, provision the managed catalog, and expose local inference through Core.	Primary development host. Managed 3B aliases have live development evidence, but no laptop, desktop, workstation, or server class is accepted yet. Ollama documents Windows 10 22H2 or newer Home or Pro; Windows Server remains an Arcane validation target rather than a documented Ollama host claim.
Linux	Arcane Core contains the same managed model contracts. An administrator must separately install and enable a compatible Ollama service; Arcane does not install Ollama or rewrite its systemd configuration on Linux.	Experimental developer host. Linux Shell and application-host work exists, but there is no public Linux model/device acceptance receipt.
Android	The current Android host has no `ai.` or `ollama.` native capability and does not run the managed Ollama catalog. Android on-device inference requires a separate mobile runtime and mobile-format model artifact.	Experimental launcher/application-host foundation only. Pixel phones are planned physical-validation targets, not active Arcane local-model support.

Ollama publishes native Windows, Linux, and GPU hardware guidance. Its documented platforms do not include Android. Google’s current mobile route is LiteRT-LM for Android; that is a separate integration boundary Arcane has not implemented.

COTS validation ladder

These are representative test targets, not minimum requirements or purchase recommendations. Exact retail stock-keeping units (SKUs) will be added to the validated ledger only after the complete receipt passes.

Device class	Representative target	Initial Arcane test scope	Status
Android phone	Pixel 8-class 8 GB phone and Pixel 10 Pro-class 16 GB phone	Establish the Android mobile runtime with a small baseline model, measure application-available memory and sustained thermals, then attempt the 3B class only if the baseline is safe.	Planned. No managed Android local AI today. Google describes Pixel 8 as a high-end target for its older mobile LLM API, but its quickstart uses a smaller model; that does not prove Arcane 3B support.
Low-end laptop	Supported Windows 11 or Linux laptop with CPU or integrated graphics and 16–32 GB system memory	3B first, followed by 8B only when measured memory, first-token latency, throughput, and sustained thermals remain acceptable.	Planned. CPU fallback may be functional but slow; no class-wide claim.
High-end laptop	Supported Windows 11 or Linux laptop with a discrete GPU, including the 24 GB RTX 5090 Laptop GPU class	Exercise managed 3B, 8B, and 12B first; evaluate 16B and 20B candidates only with an exact quantization and context contract.	Planned. GPU model name and VRAM alone are insufficient evidence.
Consumer desktop	Supported Windows 11 or Linux desktop, including the 32 GB RTX 5090 class	Exercise managed models through 26B and candidate 16B/30B artifacts where the exact working set permits.	Planned. A 32 GB card is not a blanket 30B fit guarantee.
High-memory workstation	Windows or Linux COTS workstation with up to 96 GB discrete VRAM or a high-memory unified architecture	Validate 20B, 26B, and 30B classes, then evaluate the exact managed 120B artifact only when the runtime reports sufficient usable memory.	Planned. Windows and Linux need separate receipts.
Server	Linux server with an officially supported accelerator, beginning with 80 GB H100-class and 141 GB H200-class devices	Validate the managed 120B path, long-context behavior, concurrency limits, recovery, and sustained service operation.	Planned. Windows Server is separately unvalidated.

Official specifications establish only hardware facts: Google lists current Pixel memory configurations; NVIDIA lists 24 GB for the RTX 5090 Laptop GPU class, 32 GB for the desktop RTX 5090, and the published memory configurations for H100 and H200. Those specifications are inputs to testing, not Arcane acceptance evidence.

Machine-wide models and per-user choices

A source pull, service installation, model creation, and user selection are four different states:

git pull updates the checkout only. It does not update an already installed Core, Shell, or application package.
On a fresh machine—or when the managed service needs repair—build the current development package and run the verified Provisioner. Provisioner establishes the ArcaneOllama service and its protected machine-wide model store.
When that managed service is already installed and healthy, a contributor can install the shared 3B base and create every eligible declared 3B alias without running a full provision:
```
npm run model:ensure -- --target=all --model=3b --smoke
```
The aliases in the managed service store are machine-wide, but use remains bound to each installed app's package policy and app/session Core admission. Model selection remains per user and application.

The command creates only eligible 3B targets already declared by platform or application policy; it does not invent a missing application variant. It also does not install or attest the service: if an unrelated user-owned Ollama process occupies the expected local endpoint, running the command does not convert that process or its model directory into Arcane's protected all-user service. Use Provisioner to establish or repair that boundary.

After a repository pull that adds a new selector or Core contract, update the installed Arcane development package as well as the model store. Running model:ensure alone can make the alias exist while an older installed UI still cannot select it.

What a validated result must record

Every accepted device/model row must bind:

exact device manufacturer, model, SKU, firmware, CPU, GPU/NPU, system RAM, VRAM or unified memory, and storage;
operating system edition/build or Linux distribution/kernel, Arcane commit/version, runtime, driver, and backend;
exact model name, immutable digest, family, parameter count, quantization, artifact bytes, context length, concurrency, and CPU/GPU split;
cold download, create, load, first-token latency, tokens per second, peak memory, disk use, and unload/reload behavior;
a sustained thermal and power run appropriate to the device, including battery impact for mobile systems;
pass/fail criteria, observed failures, evidence date, and the person or automation owner that produced the receipt.

Ollama exposes useful identity and residency evidence through its tags, model details, and running-models APIs. Download size is not runtime RAM or VRAM: quantization, context length, key-value cache, concurrency, and CPU/GPU offload all change the working set. See Ollama’s context guidance.

Current next steps

Publish repeatable physical-test tooling and a receipt schema before adding “Validated” badges.
Bind the existing 3B development run to an exact COTS device configuration and rerun its cold and sustained paths.
Establish the Android LiteRT-LM boundary and start with a small baseline before attempting 3B on Pixel hardware.
Add 16B and 30B managed variants only after selecting exact reviewed model families, licenses, quantizations, prompts, contexts, and product mappings.
Test Windows and Linux independently across the laptop, desktop, workstation, and server ladder.

For model definitions and service behavior, continue with Arcane Ollama models. For the broader platform boundary, read Capabilities and current status.

Repository and reviewed source access