Automatic function invocation hides a loop:

model response -> tool execution -> tool result -> next model response

If the model keeps requesting tools, that loop can keep spending time, tokens, and money. It may also repeat side effects when the model requests the same non-idempotent operation more than once.

Set a hard limit where the function-invocation client is composed:

builder.Services
    .AddChatClient(providerClient)
    .UseOpenTelemetry(
        sourceName: builder.Environment.ApplicationName)
    .UseFunctionInvocation(configure: client =>
        client.MaximumIterationsPerRequest = 6);

MaximumIterationsPerRequest defaults to 40. The value includes the initial model request, so 6 does not mean “allow six tool calls”. One model response can request several tools, and those calls may run concurrently when concurrent invocation is enabled.

Choose the limit from the work the feature is supposed to do. A support lookup that should need one or two tools has little reason to allow dozens of model round trips. Put a larger limit behind a use case that can explain why it needs one.

The cap is a stop condition. In the current implementation, reaching the cap is logged and followed by a final model request without function declarations.

That last response might be useful, but the application should not quietly report it as an ordinary success. The awkward part is detection: ChatResponse has no first-class flag that says the cap was reached.

When an exhausted budget must change the result, own the invocation loop in a component that can return an explicit outcome such as ToolLoopLimitReached. Do not infer it from the wording of the model’s final response.

Do not use this setting as a timeout. It counts iterations, not elapsed time, and it does not replace cancellation.

The wider runtime budget still needs its own controls for tokens, cost, retries, parallel tool calls, and side effects.

Test the failure path with a scripted client that keeps returning tool requests. Assert that execution stops according to the configured budget and that the caller handles the exhausted budget through the policy you chose instead of accepting a partial response as an ordinary success.