# Provider & model errors

When a harness can't produce output, AM classifies the reason and surfaces it on
the [Test button](/docs/verify-readiness) 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](/docs/teams-and-models) |
| **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](/docs/verify-readiness).

## After fixing a key

Restart the worker so it re‑probes and the chips/badge refresh:

```bash
systemctl --user restart am-cloud-worker   # or your service name
```

## Related

- [BYOK provider keys](/docs/byok-provider-keys) · [Verify readiness](/docs/verify-readiness)
- [My run made no changes](/docs/no-changes)