Should model retry behavior be configurable?

[FredKSchott]

Flue currently retries clearly transient model-generation failures automatically using internal defaults: retries are enabled, with up to 3 retries and bounded jittered exponential backoff. Provider SDK retry settings remain separate.\n\nShould Flue expose configuration for this behavior? A possible shape could allow applications to disable Flue retries or tune retry count and delay, but we would like to understand real use cases before committing to a public API.\n\nFeedback that would help:\n\n- Do the current defaults cause a problem for your workload?\n- Do you need to disable retries, tune retry count, tune delays, or customize which errors retry?\n- Should configuration apply per agent profile, per operation, or globally?\n- How do you expect Flue retry behavior to interact with provider SDK retry configuration?\n\nIf you have a concrete example, please share the provider, failure mode, latency or cost constraint, and desired behavior.