Runtime Diagnostics
Capability health checks and fast triage workflow.
Runtime Diagnostics is the first place to check when prompts fail, capabilities look missing, or UI behavior degrades.
Core Fields
Typical diagnostics include:
- workspace path
- session state and active mode
- selected model and agent
- connected providers and model counts
- permissions mode
- capability health states
Capability States
Each capability reports:
AVAILABLEPARTIALUNAVAILABLE
and a source (for example server, file, or hybrid).
Fast Triage Sequence
- refresh diagnostics
- verify
/runtime/health - verify
/runtime/capabilities - confirm provider auth and model visibility
- retry the prompt
CLI Health Checks
curl http://127.0.0.1:4096/runtime/healthcurl http://127.0.0.1:4096/runtime/capabilitiesStuck Or Looping Task Diagnostics
If a task appears stuck rather than failed outright, an operator can inspect
persistent-run state directly. This endpoint is protected when
ALPHABASE_PERSISTENT_RUNNER_TOKEN is configured; it is not a normal client
health check:
curl \ -H "Authorization: Bearer $ALPHABASE_PERSISTENT_RUNNER_TOKEN" \ http://127.0.0.1:4096/runtime/persistent-runs/diagnosticsIf no runner token is configured for a local runtime, the header can be omitted.
The endpoint reports aggregate liveness metrics for background execution. Use
/runtime/health and /runtime/capabilities for ordinary client triage.
Common Diagnosis Patterns
UNAVAILABLE + server
Usually runtime auth mismatch, server outage, or bad target host/port.
PARTIAL + hybrid
Fallback data path is active; live capability fetch is degraded.
Local AI unavailable
Local runtime (for example Ollama) is unreachable or not started.
Escalation Packet
When escalating:
- app surface (Desktop/VS Code/TUI/Web)
- exact prompt used
- diagnostics snapshot
- runtime logs in failure window
- screenshot of final UI state