Skip to content

Understand error reports

Ollama Client error reports are designed to give users a direct recovery step and give maintainers enough technical context to reproduce a bug without collecting telemetry.

An error code identifies the failure category. For example, OLC-PROVIDER-DISABLED always means the selected provider is disabled. Maintainers can use the code to find the relevant recovery path and code branch.

An incident ID, such as INC-1F9F2263, is a short random correlation token created locally for one error. It is not an encoded error message, account ID, server log ID, or tracking identifier. There is no remote database where an incident ID can be looked up.

The incident ID is useful when a local diagnostic event was recorded with the same support code. It lets a maintainer match the failed chat message and issue draft to the corresponding event in a support bundle, and distinguish two otherwise identical failures. Local diagnostic events expire after seven days.

Read these fields in order:

  1. Error code identifies the stable failure category.
  2. Suggested recovery shows the action offered to the user.
  3. Provider, model, base URL, status, and failure phase locate the failing request stage. Credentials, query parameters, and URL fragments are removed.
  4. Automatic checks show whether the provider was enabled, reachable, and advertising the selected model when Open an issue was clicked.
  5. Incident ID can be matched to the supportCode in an attached support bundle.
  6. Extension, browser/version, and OS family help isolate release-specific and browser-specific behavior.

The support bundle is available under Help → Diagnostics & support. Users can select Preview support bundle, review its contents, then Download bundle and drag the JSON file into the GitHub issue. Attaching it is optional, but its safe event sequence often makes diagnosis faster. Nothing is uploaded automatically, and GitHub does not allow the extension to attach a local file silently. Chat errors run privacy-safe diagnostics locally and include a Copy diagnostics button beside Open an issue. Paste the copied support-bundle JSON into a new issue if you prefer to create it manually. The inline copy includes only privacy-safe events correlated with the current chat session; the prefilled issue contains a concise summary and matching event highlights. The full retained event history remains available from the Diagnostics & support settings card.

CodeMeaningFirst check
OLC-PROVIDER-DISABLEDSelected provider is disabledEnable it in Model behavior
OLC-PROVIDER-UNREACHABLEEndpoint could not be reachedProvider process and base URL
OLC-PROVIDER-HTTPProvider returned an unclassified HTTP errorStatus and provider logs
OLC-MODEL-NOT-FOUNDRequested model does not existSelected model name
OLC-RESOURCE-NOT-FOUNDProvider endpoint or resource is missingBase URL and API path
OLC-MODEL-NOT-LOADEDModel exists but is not loadedLoad the model in the provider
OLC-CORS-BLOCKEDBrowser origin was rejectedProvider CORS/origin settings
OLC-AUTH-FAILEDRemote provider rejected credentialsAPI key and endpoint
OLC-PAYMENT-REQUIREDHosted provider requires creditsProvider account balance
OLC-CONTEXT-TOO-LARGEInput exceeds the context windowReduce chat/context size
OLC-INPUT-UNSUPPORTEDModel cannot handle the input typeModel capabilities
OLC-OUT-OF-MEMORYProvider could not allocate enough memorySmaller model or more memory
OLC-MODEL-LOADINGModel is still loadingWait, then retry
OLC-RATE-LIMITEDProvider is throttling requestsRetry timing
OLC-PROVIDER-OVERLOADEDProvider is temporarily overloadedWait, then retry
OLC-PROVIDER-TIMEOUTRequest exceeded its time limitProvider health and model speed
OLC-STREAM-DROPPEDConnection ended during response streamingProvider logs and network
OLC-UNKNOWNFailure did not match a safe known categoryPhase, status, and reproduction

Issue drafts are generated locally and opened for review. They do not include prompts, responses, page or file content, file names, API keys, credentials, raw provider response bodies, or console logs. Browser detection is best effort because Chromium-based browsers may deliberately identify as Chrome; users should edit the browser field if it is wrong.