Preserve provider error context when converting stopReason errors

This branch always throws FailoverError("Provider finish_reason: error", { reason: "overloaded" }), which discards the original assistant/provider error details from runEmbeddedPiAgent. In single-candidate runs (or when all candidates fail), downstream handlers only see this synthetic overload error, so billing/rate-limit/role-ordering classification and user-facing recovery messaging regress to a generic failure instead of the real cause. Wrap using the underlying error text/reason (when present) rather than hardcoding overloaded.

Useful? React with 👍 / 👎.

Classify finish_reason errors before forcing overloaded retries

This branch converts every result.meta.stopReason === "error" into FailoverError(... reason: "overloaded"), which misclassifies non-overload failures as transient retryable overloads. For example, openai-transport-stream.ts maps finish_reason: "content_filter" to stopReason: "error"; with this change, that policy block now gets retried on fallback candidates instead of being surfaced, and downstream logic records the wrong failure reason. Please derive the failover reason from the provider error payload/message (or only map known transient reasons) before triggering fallback.

Useful? React with 👍 / 👎.

Derive failover reason from stopReason error payload

This branch converts every result.meta.stopReason === "error" into FailoverError(..., { reason: "overloaded" }), but stopReason: "error" is also used for non-transient failures (for example content_filter in src/agents/openai-transport-stream.ts:1304-1306). In cron isolated runs this misclassifies policy/validation errors as transient overloads, which can trigger inappropriate fallback retries and surfaces the wrong failure reason when candidates are exhausted. Please preserve the provider error context (or only map known transient cases) before forcing overloaded.

Useful? React with 👍 / 👎.

Skip fallback retry after streaming reply content

This unconditional stopReason === "error" conversion runs after the attempt may already have emitted user-visible output through earlier callbacks in this same run path (onPartialReply/onToolResult). When a provider streams partial text and then terminates with finish_reason:error (for example, a late content filter), this throw triggers runWithModelFallback to retry another candidate, so the user can receive mixed/duplicated replies from multiple attempts and repeated side effects. The retry should be gated on whether the failed attempt already produced outbound content/tool sends.

Useful? React with 👍 / 👎.

Treat unknown finish_reason errors as non-transient failures

This fallback reason default (classifyFailoverReason(errorText) ?? "overloaded") misclassifies unrecognized stopReason === "error" cases as transient overloads. For example, OpenAI finish_reason: "content_filter" is mapped to "Provider finish_reason: content_filter" in src/agents/openai-transport-stream.ts, which does not match current classifiers, so this path retries other candidates and reports an overload instead of surfacing a moderation/policy failure. That changes both retry behavior and user-facing error semantics for non-transient provider stops.

Useful? React with 👍 / 👎.

Prevent retry after side-effecting stopReason:error attempt

In the cron isolated-agent fallback path, this unconditional stopReason === "error" conversion throws before the caller can evaluate runResult side-effect flags. runEmbeddedPiAgent can complete tool actions (for example message sends or cron mutations) and still return with an error stop reason from the final assistant step; throwing here makes runWithModelFallback run another candidate after those effects already happened, so scheduled runs can emit duplicate outbound messages or duplicate cron changes. Please gate this retry on whether the failed attempt already produced side effects (for example didSendViaMessagingTool / cron-add metadata) before re-entering fallback.

Useful? React with 👍 / 👎.

Gate finish_reason retries after side-effecting runs

This unconditional stopReason === "error" conversion retries fallback even when the just-finished attempt may already have executed irreversible actions. runAgentAttempt can return results that include side-effect markers (for example didSendViaMessagingTool / successfulCronAdds from embedded runs), and throwing here re-enters runWithModelFallback, which can send duplicate outbound messages or repeat cron mutations on the next candidate. The retry should be skipped (or handled differently) once the failed attempt has already produced side effects.

Useful? React with 👍 / 👎.

Pass provider into failover reason classifier

classifyFailoverReason(errorText) is invoked without the candidate provider, which disables provider-specific classifiers (for example isOpenRouterKeyLimitExceededError in pi-embedded-helpers/errors.ts only matches when provider contains openrouter). In this path, those errors fall through to null and then get forced to "overloaded", so billing/auth-like failures are treated as transient overload retries and logged with the wrong reason. This regresses fallback behavior and cooldown handling for provider-specific error formats.

Useful? React with 👍 / 👎.

@codex review!!

Avoid turning terminal finish_reason errors into hard failures

Throwing here converts every stopReason === "error" result into an exception, but agentCommandInternal does not translate fallback exhaustion back into a reply payload. In single-candidate configs (or when all candidates fail), runWithModelFallback rethrows this FailoverError, and ingress paths that call agentCommandFromIngress (for example src/gateway/openai-http.ts and src/gateway/openresponses-http.ts) treat it as an internal failure and return generic 500s. Before this change, the same provider-side error surfaced as a structured error payload from the run result.

Useful? React with 👍 / 👎.

Pass provider context when classifying failover reason

classifyFailoverReason is called without the provider even though providerOverride is available, so provider-specific generic errors are misclassified (or fall back to "overloaded"). That changes recorded attempt reasons and downstream fallback policy/message behavior (cooldown probing and summary text), especially for provider patterns that only resolve with provider context.

Useful? React with 👍 / 👎.

Pass provider into finish_reason failover classification

classifyFailoverReason is called with only errorText, so provider-specific classifiers are skipped in the auto-reply fallback path. For errors whose detection depends on provider context (for example OpenRouter-specific key/credit patterns), this falls through to null and then gets coerced to "overloaded", which records the wrong failure reason and can drive incorrect retry/cooldown behavior when a run ends with stopReason === "error".

Useful? React with 👍 / 👎.