The main Roo Code API-request failure pattern is already covered in the recovery guide. This Radar note is narrower: Roo Code is using a local provider such as Ollama or LM Studio, and the request stalls, fails, or returns nothing while the project may already have partial edits on disk.

Radar read: local-provider failures are usually a stack problem, not just a Roo problem. Check the model server and preserve the project state before you retry the agent.

Why the local request fails.

With Ollama or LM Studio, Roo Code is only one part of the path. The request can fail because the local server is not running, the model is not loaded, the base URL or port is wrong, the context window is too large, the machine is out of VRAM, or the local provider is still starting the model.

That matters because a failed request can still leave useful evidence behind: changed files, terminal output, a partial plan, an error message, or a failed attempt that the next model should not repeat.

Fast diagnostic order.

  1. Stop the retry loop. Do not send the same Roo request five more times while the local server is already failing.
  2. Check the provider outside Roo. Send a tiny prompt directly to Ollama or LM Studio first. If that fails, Roo is not the first thing to fix.
  3. Verify the endpoint. Confirm the local server URL, port, selected model name, and OpenAI-compatible route where relevant.
  4. Try a tiny context. Ask for one small file or one diagnostic step. If the tiny request works, the original request was probably too large or too memory-heavy.
  5. Preserve the work. Capture git diff, changed files, logs, failed attempts, and the next smallest verification action before resetting the session.

Ollama-specific checks.

  • Confirm Ollama is installed and reachable before Roo sends the request.
  • Confirm the model exists locally and can answer a tiny prompt.
  • If the request dies during a large refactor, reduce files and context before retrying.
  • If the machine is memory-bound, switch to a smaller model or hand the task to another tool while keeping the recovery packet intact.

LM Studio-specific checks.

  • Confirm the LM Studio local server is enabled.
  • Confirm Roo is pointing to the right local base URL and model identifier.
  • If the failure appears after a long prompt, lower context size or ask Roo to continue from a smaller packet.
  • If the chat is already stale, start a fresh Roo session instead of making the old one interpret another failed attempt.

What ShardStitch does here.

ShardStitch does not fix Ollama, LM Studio, or Roo's provider adapter. It protects the work around the failure: the diff, changed files, project memory, failed attempts, verified facts, inferred claims, and next action. Then you can retry Roo, switch to a hosted model, or move the task to another AI coding tool without rebuilding context by hand.

Source trail

Related Roo pages