Crush stuck on Generating?

A reported Crush failure can detect a bad provider base URL, exhaust retries, and still leave the Generating spinner active. Treat the spinner as an unresolved request, not evidence that the agent is making progress.

Preserve first: Record the provider endpoint, model, terminal error, and retry outcome. Check for existing edits before changing configuration; a spinner alone cannot establish that a request is still productive.

Match the failure before retrying.

Provider base URL is wrong

A misconfigured provider endpoint can fail before useful model work begins.

Rate limit retries were exhausted

The interface may continue showing Generating even after the request has no productive retry path.

Local edits exist from an earlier step

Before restarting the session, inspect the repository because prior tools may already have changed files.

Safe recovery path.

Cancel the request and record the provider, model, base URL, and exact error details.

Check git status and git diff before changing configuration or restarting Crush.

Correct the provider endpoint or credentials and verify it with one minimal request.

Resume with the current goal, verified changes, failed provider attempt, and one next test.

What the next AI should receive.

Provide the provider/model configuration with secrets removed, response error, exhausted retries if shown, local diff, and result of one minimal request. Do not include API keys in the handoff.

How ShardStitch works with Crush.

ShardStitch converts the surviving repo state into a clean Crush pickup packet. The next attempt sees which files actually changed, which provider path failed, and which claims still require verification.

Separate connectivity from completion.

Record whether the failure is an HTTP response, connection error or only an unchanged interface. Wrong endpoints, rejected credentials and exhausted quota need different corrections. Retain the model and endpoint in your diagnostic note, but redact authorization headers.

Check revised configuration with a small non-editing request. Success establishes connectivity for that request, not completion of the interrupted coding task. Inspect modified files independently and run the relevant project check before resuming edits.

Source trail.

Crush provider configuration and its reported failure behavior are separate from saved repository state.

FAQ.

Does the Generating spinner prove Crush is still working?

No. Compare it with terminal or provider errors and retry state. The cited report describes an interface that can remain busy after provider failure.

Should I replay the full coding task after fixing the endpoint?

First verify the endpoint with one small request, then inspect prior edits. Continue the unfinished action instead of replaying changes that already reached disk.

Scope note: This page covers a documented provider-configuration retry failure. Other Crush hangs can have different causes.