# My run made no changes

A run that finishes in seconds as **`no_op`** almost always means an agent never
really did anything — and 9 times out of 10 it's a provider key or balance
problem, not a bug. (A run that worked for a while and *then* found nothing to
commit is **`success_no_changes`** instead — usually a focus/scope issue, not a
provider one.) If a repo keeps producing no‑progress runs, the scheduler backs it
off automatically and probes it less often. Work this decision tree top to bottom.

## Decision tree

**1. Did the run finish in just a few seconds?**
Yes → an agent failed to start or exited immediately. Continue.
No (it ran minutes) → the agent genuinely found nothing to do; tighten the
[focus](/docs/focus) or pick a [playbook](/docs/playbooks).

**2. Is the harness reachable for the EXACT model your team uses?**
Open the [team builder](/docs/teams-and-models) and click **Test** next to the
role. This is the single fastest check.

- `✗ out of balance` → top up the provider, or switch model/provider. *(Most
  common cause.)*
- `✗ no/invalid API key` → set/rotate the key on the worker, then **restart the
  worker** ([BYOK](/docs/byok-provider-keys)).
- `✗ unknown model` → fix the model id in the team.
- `✗ not installed` → install that harness on the worker.
- `✗ rate limited` / `timeout` → wait or switch provider.
- `✓ reachable` → the provider is fine; go to step 3.

**3. Check the run's activity / dev output.**
Open the run ([reading a run](/docs/reading-runs)) and look at the tool tally:

- `Bash×many, Write×0` with an early exit → the agent **over‑explored** and never
  committed. Use a **procedural** focus ("orient briefly, do one thing, commit by
  ~your 8th tool call") or a [playbook](/docs/playbooks).
- An error line in the dev output (e.g. *insufficient balance*, *permission*) →
  fix that specific issue (see [provider errors](/docs/provider-errors) /
  [worker not ready](/docs/worker-not-ready)).

**4. Is the worker actually ready?**
Check the [Workers tab](/docs/worker-health) for a **ready** badge and green
harness chips. No ready harness = silent no‑op by design.

## Most common root causes, ranked

1. **Provider out of balance / no key** — caught by the Test button.
2. **Vague focus → over‑exploration** — fix with a procedural focus / playbook.
3. **Worker not ready** — wrong/missing key, harness not installed, needs restart.
4. **Permissions as root** — see [worker not ready](/docs/worker-not-ready).

## Related

- [Verify readiness](/docs/verify-readiness) · [Provider & model errors](/docs/provider-errors)
- [Worker not ready](/docs/worker-not-ready) · [Focus](/docs/focus)