A status can describe a real limit of the host, model, plugin, or account policy. Start with the status shown in the SoAI WebUI, then use the checks below to separate an unsupported capability from a recoverable failure.
Product and platform limits
The Hardware page requires Hardware read access (HARDWARE_READ). GPU power, clock, and fan
controls appear only when the account has GPU tuning (HW_GPU_TUNING) and the detected device reports an actionable
control capability. The process panel separately requires Process viewing (HW_PROCESS_VIEW). A visible GPU is
therefore not a promise that every hardware control will be available. See
GPU controls and tuning for the capability and permission checks.
SoAI Bench has an independent OpenCL preflight. A GPU can be listed for monitoring yet show Unsupported for a benchmark when OpenCL cannot match the device, allocate the workload, or finish its validation. That result does not by itself mean ordinary hardware monitoring has failed. Read the SoAI Bench overview before following the benchmark run procedure.
Platform and edition limits
The Install SoAI Core page describes supported Core installation paths. Compare Core with the appliance edition in SoAI products and editions, then use the SoAI OS overview for appliance installation and controls.
- Published Core Linux archives support x64 and ARM64 hosts.
- The published Windows installer and automatic Core update path support x64. There is no Windows ARM64 installer.
- The published macOS (experimental) archive and automatic update path support Intel and Apple silicon. SoAI GPU telemetry and tuning remain unavailable on macOS.
- SoAI OS is not yet available and is not currently distributed. The appliance edition will support amd64 and arm64 hosts. Contact info@soai.to to join the waitlist; joining does not grant a license or promise an availability date.
Core and SoAI OS use separate launchers, release payloads, and licenses. Updating one edition does not convert it into the other.
Plugin boundaries
SoAI loads plugins through dedicated worker processes and validates package boundaries before loading them. That process boundary is not a reason to trust an unknown archive. Review a third-party plugin and the terms of its managed backend before adding it to the host. Use Plugins overview to inspect the source and package boundary, and apply the Hardening checklist before installing third-party code.
Skill scope and model limits
Personal skills apply to ordinary chats and delegated work, rather than automations, messaging integrations,
external inference requests, or MCP clients. Automatic loading depends on model tool use; request a skill by
$name when its author permits explicit loading. If the instructions exceed the remaining context,
compact history, choose a larger-context model, or shorten the skill. See Skills.
Diagnose and report a problem
Open the notification bell and select Tasks to inspect
active downloads, installations, and maintenance work. Use
Logs for diagnostic detail when the account has
Log access (LOG_ACCESS).
If a local backend or provider fails, confirm the plugin state, model compatibility, available memory, host driver,
and provider credentials before retrying. Retrying does not repair an unsupported device, a missing dependency, or
exhausted memory.
Report a reproducible defect
Record the SoAI version, edition, platform, plugin and backend version, model identifier, visible status, task or run ID, and a small relevant log excerpt. Remove passwords, API keys, prompts, uploaded files, provider tokens, and personal data before sharing the report.