Skip to content

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:

  • AVAILABLE
  • PARTIAL
  • UNAVAILABLE

and a source (for example server, file, or hybrid).

Fast Triage Sequence

  1. refresh diagnostics
  2. verify /runtime/health
  3. verify /runtime/capabilities
  4. confirm provider auth and model visibility
  5. retry the prompt

CLI Health Checks

Terminal window
curl http://127.0.0.1:4096/runtime/health
curl http://127.0.0.1:4096/runtime/capabilities

Stuck 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:

Terminal window
curl \
-H "Authorization: Bearer $ALPHABASE_PERSISTENT_RUNNER_TOKEN" \
http://127.0.0.1:4096/runtime/persistent-runs/diagnostics

If 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:

  1. app surface (Desktop/VS Code/TUI/Web)
  2. exact prompt used
  3. diagnostics snapshot
  4. runtime logs in failure window
  5. screenshot of final UI state