Every answer in DataMind Oda begins as a model call: Oda sends the request, the model service answers, and the reply comes back into your chat. This page shows how a call can end, the kinds of failures Oda reports, how it retries them, and what every call says about the app.
Every model call ends in exactly one of five ways:
Oda classifies every failure and shows its own message for that kind, never the raw text a service returned, so the same problem reads the same whichever service answered. The kinds you can meet:
| Kind | What it means |
|---|---|
| Nothing available to call | Oda found no way to reach the model. |
| A missing sign-in or key | The call needs a credential, and none is in place for it yet. |
| A refused sign-in | The model service turned the sign-in or key away. |
| Rate limiting | The service is taking too many requests and asked Oda to slow down. |
| A full context | The request was larger than the model's context window. |
| An unusable key | The stored key is blank, or holds characters Oda cannot send. Oda refuses the call before it goes out. |
| A spent quota | The account behind the service has no quota, credit or budget left. |
| An empty answer | The service finished the call with no content, so there was nothing to show. |
| Images that do not fit | The request carries more images than the model accepts. Oda sets the oldest images aside first and tries again; see Attach files and images to a message. |
A failure that fits none of these kinds is still reported as a failure.
Oda places the failure in one of the kinds above and shows its own message for it, not the raw text a service returned. Temporary kinds are retried for you first; the others need something fixed, such as a key on Settings > Models.
The temporary kinds: an empty answer, a rate limit, a server-side problem, a timeout, and a connection that dropped. Oda repeats the call a few times, with growing waits between the attempts. Problems that need a fix, such as a missing key or a refused sign-in, are not retried.
A few times, with growing waits between the attempts. Each route carries a Retry policy setting that decides the details; see Provider route settings reference.
Oda. The model service never repeats a request on its own.
Because the key was blank, or it held characters that cannot travel in a request. Oda checks the key before the call and refuses it, and the message names where the key is read from, so you know what to fix. Add or replace the key on Settings > Models.
No. A key's contents are never echoed anywhere: not in a chat, not in a message. When a key is refused, the message names only where Oda reads it from.
The request was larger than the model's context window, so the model could not read it, and Oda does not retry this kind. In a long chat Oda shortens the older part on its own; see System prompt, context and compaction. When a call still reports a full context, make the next request smaller.
The request carried more images, or more image bytes, than the model accepts. Oda sets the oldest images aside first and tries again; when even that is not enough, the failure says how many more images must be left out. Attachments in model requests follows what each request carries.
Hiding a model on Settings > Models changes what the model picker offers; it does not remove the model or block it. A call that names the hidden model still runs. Chat with Oda covers choosing a model.
Every call identifies the app and its version: DataMind Oda, with the version that sent it. That is a public fact about the product; it carries no secrets, no file paths, no chat identifiers, no prompt text and no personal identifiers.
Oda refuses it with a plain reason when the app starts.