Model calls and failures

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.

How a call can end

Every model call ends in exactly one of five ways:

• It finishes. The model completed its reply and the answer arrives in the chat.
• It asks for tools. The model asked for work to be done, such as reading a file or running a command; Oda does it and sends the result back.
• It reaches the reply limit. The answer reached the model's maximum reply length and ends there.
• You stop it. Pressing Stop during a turn ends the call in progress.
• It fails. The call did not complete. Oda reports it as one of the kinds below and retries the temporary ones for you first.

Kinds of failure

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:

A failure that fits none of these kinds is still reported as a failure.

What Oda retries, and what it does not

Retrying is decided per route: each provider route carries its own retry policy, in one of two modes, so two routes can retry differently. Provider route settings reference lists the setting with the route's other settings.

• Normal (the default). Oda retries the temporary problems: an empty answer, a rate limit, a server-side problem, a timeout, or a connection that dropped. It retries up to five times, and then gives up. Problems that need a fix, such as a missing key, a refused sign-in, a full context or a spent quota, are reported without repeating the call.
• Always. Oda retries the temporary problems and also those that waiting cannot fix: a refused sign-in or key, a spent quota, and a request the service will not accept. The attempts have no set limit: it keeps trying until the call succeeds or you stop the turn.

Worth knowing:

• A retry repeats the failed step. Only the step that failed goes out again, as it was; the failed attempt's partial output is not kept, and the work before it is not repeated.
• Oda does the retrying, not the service. The model service never repeats a request on its own, and nothing about a retry reaches the model.
• Oda waits between attempts. Each wait after the first is longer, up to a cap. When the service answers with a wait of its own, Oda waits that long instead, as long as it fits the policy's bounds.
• Every retry is recorded. In the chat, a retry row shows the wait and the attempt while they happen (Failures and recovery). The chat's log keeps the wait it scheduled first, then the attempt itself (Session logs on your computer shows where the log lives).

What retrying costs

Each attempt goes out as its own request to the model service, and it is billed like any other request.

• A retry can charge the input again. A repeated attempt sends the same input, and that input can be billed again each time it is sent.
• Normal mode bounds the cost. It stops after its allowed retries, so a failure costs a bounded number of extra requests.
• Always mode does not bound it. With no set limit, a problem that cannot pass, such as a spent quota or a refused key, keeps sending billed requests until the call succeeds or you stop the turn.

Change how a route retries

1. Open Settings > Models (Set up models and providers covers the page).
2. Open the route and change its retry policy.
3. Save. The change reaches the route in one step, with no moment where the route cannot serve; a call that is already running keeps the settings it started with, and the new policy applies from the next request.

• The policy belongs under each provider route. A retry policy placed anywhere else is refused, not silently ignored.
• An unknown setting is refused too. A retry setting the policy does not recognise fails the same way, so a misspelling cannot quietly change how a route retries.

Keys: refused early, never echoed

• Model keys are written on Settings > Models; Set up models and providers shows how a key is added and replaced.
• Oda checks a key before a call goes out. If it is blank, or holds characters that cannot travel in a request, the call is refused, and the message names where Oda reads the key from.
• A key's contents are never echoed anywhere. When something is wrong with a key, you see where it comes from, never the key itself.

What every call says about the app

• Every model request identifies the app: DataMind Oda, with the version that sent it, so the service can tell which app and which version called it.
• That identification is a public fact about the product. It carries no secrets, no file paths, no chat identifiers, no prompt text and no personal identifiers.

When a model is hidden or broken

• Hiding changes the model picker only. Hiding a model in Settings > Models changes what the model picker offers; a call that names the hidden model still runs.
• A saved model that is no longer offered. The message box stays blocked until you choose another model; Troubleshooting covers that message.
• A broken definition is refused plainly. If a model's definition is broken, Oda refuses it with a plain reason when the app starts.

Questions, answered

Why did my message fail while the model was working?

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.

Which failures does Oda retry by itself?

In the default Normal mode, the temporary kinds: an empty answer, a rate limit, a server-side problem, a timeout, and a connection that dropped. Oda repeats the call with growing waits between the attempts. Problems that need a fix, such as a missing key or a refused sign-in, are not retried.

How many times does Oda try again?

In Normal mode, up to five times by default, with growing waits between the attempts. In Always mode the attempts have no set limit, so the requests keep going out until the call succeeds or you stop the turn. Each route carries a Retry policy setting that decides the details; see Provider route settings reference.

What does Always mode do that Normal mode does not?

It keeps trying where Normal stops. Besides the temporary problems, Always also retries a refused sign-in or key, a spent quota, and a request the service will not accept, without a set limit.

Is a retry billed again?

Yes. Each attempt is a separate request to the model service, and it is billed like any other request; a repeated attempt can charge the same input again. In Always mode, a problem that cannot pass keeps sending billed requests until you stop the turn.

Does the model see that a call was retried?

No. The retry happens between Oda and the model service. The failed step is sent again as it was, the failed attempt's partial output is not kept, and the retried request reads to the model like any other request.

Where can I see that a retry happened?

In the chat, a retry row shows the wait and the attempt while they happen; Failures and recovery covers the rows. The chat's log also records each retry: the wait it scheduled first and the attempt that followed.

Why was my key refused before the call went out?

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, never the key itself, so you know what to fix. Add or replace the key on Settings > Models.

What does a full context mean?

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.

Why did my call fail over images?

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.

A model I hid still answered. Why?

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.

What does Oda tell the model service about the app?

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.