Errors, retries and timeouts

The retry and timeout settings in Aimogen Pro, how provider errors are classified, and how retries interact with Reliability Mode.

Retry settings#

Settings › General Settings

Chat End of Conversation Retry Count deserves care. It exists because models sometimes produce a closing remark instead of answering. Retrying gets a real answer — at the cost of another paid request each time. Set it to 1 or 2, not higher.

Timeouts#

Three timeouts interact, and the smallest wins:

1. PHP max_execution_time — kills the whole request.
2. The plugin timeout (Timeout For API Requests, default 120s; large requests use AIMOGEN_DEFAULT_BIG_TIMEOUT, 160s).
3. The provider timeout — the provider gives up on its own side.

If a long generation dies at a consistent number of seconds, work out which of the three that number corresponds to.

Raise the plugin timeout for slow models — reasoning models, sonar-deep-research, large local Ollama models. Keep PHP max_execution_time comfortably above whatever you set.

Error classification#

Aimogen Pro matches provider error text against nine categories. The category decides whether the request is retried, whether the model is cooled down, and whether the key is held.

Cooldown and key behaviour only apply with Reliability Mode and key rotation enabled.

The matching is on substrings of the provider message, so it works across providers that use different error formats for the same underlying condition.

Interaction with Reliability Mode#

Without Reliability Mode:

• The retry count applies.
• A fallback model, if configured, is chosen at random.
• No cooldowns, no capability checking, no circuit breaker.

With Reliability Mode:

• The retry budget is raised for the current request to at least min(fallback_count, Maximum Fallback Attempts).
• Fallbacks are tried in order and filtered by capability.
• Failing models and providers are cooled down.

Your saved retry setting is never modified on disk.

Where to see errors#

System & Logs › Activity Logs is the primary log: one entry per rule execution, including the provider error text verbatim. This is what to read first and what to paste into a support ticket.

System & Logs › Usage Logs records every API request with model, tokens and price. A request that failed still appears, which is how you tell "no request was made" from "a request was made and failed".

System & Logs › Live AI Activity streams requests as they happen — useful while reproducing a problem.

The debug log. With enable_logging on under Settings › General Settings, the plugin also writes to its own log file, whose location is shown on the Maintenance tab.

Common patterns#

Every request fails immediately Credentials. Use Test API key.

Requests fail only during bulk runs Rate limits. Raise Delay Between API & Scraping Requests (ms), add keys, enable rotation.

Requests fail only for long content Timeout or context. Check the three timeouts, then the token budget.

Requests fail only for one model Model retired, or not enabled on your account.

Requests fail intermittently with no pattern Provider instability. This is exactly what Reliability Mode is for.

Chatbot works, scheduled rules do not Not an API problem. See Scheduled tasks do not run.

Related#

• Reliability Mode
• API and provider errors
• Usage logs and statistics