Add stopAfterToolCalls option for OpenAI-compatible workflows

[ajason]

• Introduce a provider-specific stopAfterToolCalls toggle in OpenAILanguageModel.CustomGenerationOptions.
• Document the new option and add tests to validate encoding behavior.

Motivation
In production environments, tool execution is often managed by an "external orchestrator" (e.g., dispatching calls to independent workers, invoking internal services, or implementing permission and auditing logic). The current default behavior automatically executes tools immediately after the model generates tool calls. This is unsuitable for systems that require:

• Permission, auditing, or routing checks prior to execution.
• Distribution of tool calls to different executors via an external system.
• Persistence of tool calls for asynchronous execution.

The stopAfterToolCalls flag allows the client to receive the tool calls without triggering automatic execution, handing control over the execution timing to the upper-level orchestrator.

Use Cases / Scenarios

• Sending tool calls to a queue or workflow system for processing.
• Implementing security audits (e.g., for sensitive APIs or enterprise resource access).
• Facilitating multi-agent or multi-service collaboration where execution is coordinated by external logic.
• Persisting tool calls for retry or playback mechanisms.

Behavior

• When stopAfterToolCalls == true and the model generates tool calls: the generation process halts, returning the tool calls to the caller without execution.

Testing

• swift test --filter OpenAICustomOptionsTests

[mattt]

Hi @ajason. Thanks for opening this PR!

I totally agree that the current approach to tool calling is insufficient.

As far as solutions, I think stopAfterToolCalls is a reasonable solution, but I'd like this to be generalized to all language models.

I just opened #109, which follows that approach, implementing a delegate pattern with hooks for observing generation and execution of tool calls, and controlling whether to allow execution (with option to provide result programmatically).

Please take a look at that and let me know if you have any concerns about that satisfying your use case.

[ajason]

Hi @mattt

thanks for the quick feedback

I agree the delegate approach is the right direction and better generalized across providers. The ability to stop execution and optionally inject tool outputs covers my original use case . I’ll close this PR and follow #109 instead.