Provider & model errors
When a harness can't produce output, AM classifies the reason and surfaces it on the Test button and worker chips. Here's what each means and how to fix it.
| Reason | Cause | Fix |
|---|---|---|
| out of balance | The provider account has no credit | Top up, or switch model/provider in the team |
| no/invalid API key | Key missing, wrong, or expired | Set/rotate the key on the worker, then restart the worker |
| unknown model | Model id not recognised by the provider | Correct the model id (e.g. claude:claude-sonnet-4-6) |
| not installed | The CLI isn't on the worker | Install the harness on the worker host |
| rate limited | Provider throttling / out of overage | Wait, or use a different provider |
| timeout / unreachable | Network or provider outage | Check the worker's connectivity & provider status |
Which model the probe uses
The background "Say HI" probe tests one model per harness. By default that's the
harness's built‑in model, but you can override it per CLI under Workers →
Liveness probe models — useful when the default is a model you don't have quota
for. The probed model is shown in the failure chip, e.g. pi (rate limited · moonshot/kimi-k2), so you always know what was tested.
Why a green probe can still fail a run
The probe tests the configured/default model. Your team might use a different model that fails for a different reason (commonly an empty balance on that specific account). Always confirm with the Test button, which probes the exact cli/model — see Verify readiness.
After fixing a key
Restart the worker so it re‑probes and the chips/badge refresh:
systemctl --user restart am-cloud-worker # or your service name