How is everyone else handling underlying model API capability drift?

[danteoh-toast]

We recently noticed that when we were migrating to responses API, we don't have any control over the strict param. It's becoming increasingly common for there to be API capabilities from the model providers where Koog gets in the way of us actually using them.

What is everyone else doing here? are you just intercepting the request and managing it directly?

[Govind yadav (GtechGovind)]

I checked this against the current develop sources. There is not a clean public switch for the function-tool strict field today.

OpenAIResponsesParams exposes request-level options (and additionalProperties), but no per-tool strictness option: OpenAIParams.kt. The Responses path then converts each ToolDescriptor to an internal Function using only name, parameters, and description: OpenAILLMClient.kt. The wire model itself already has strict, but it is internal and remains unset by that conversion: OpenAIResponsesAPI.kt.

That also means additionalProperties is not a good escape hatch for this particular field: it is flattened at the request root, whereas the desired value lives under each tools[] entry.

The least fragile choices I see are:

1. Add a small Koog extension such as OpenAIResponsesParams.toolStrict: Boolean? (or a per-tool equivalent) and pass it into Function(strict = ...) in both the streaming and non-streaming Responses paths.
2. Until that is exposed, wrap/intercept the outgoing HTTP JSON and set tools[*].strict. This keeps the rest of Koog's request/streaming machinery, but it is still a temporary compatibility shim.
3. If several provider-specific fields are missing, implement a custom LLMClient for that provider instead of accumulating JSON rewrites.

For a single field I would choose option 1 and upstream it; the underlying wire type is already present, so the patch should be small. Longer term, a provider-capability/escape-hatch API that preserves unknown nested fields would prevent Koog from becoming the lagging part whenever OpenAI-compatible APIs evolve.

[danteoh-toast]

Koog is already lagging quite a bit on the model management layer. I almost feel like splitting the repo into something more model-focused is inevitable. - strict field - native tool search - input cache tokens Are all things we've been blocked by lately. Dan

…

On Sat, Aug 8, 2026 at 2:37 PM Govind yadav ***@***.***> wrote: I checked this against the current develop sources. There is not a clean public switch for the function-tool strict field today. OpenAIResponsesParams exposes request-level options (and additionalProperties), but no per-tool strictness option: OpenAIParams.kt <https://github.com/JetBrains/koog/blob/10bba89b67929bab3617047a6a7c8d8cf3ff9185/prompt/prompt-executor/prompt-executor-clients/prompt-executor-openai-client/src/commonMain/kotlin/ai/koog/prompt/executor/clients/openai/OpenAIParams.kt#L334-L356>. The Responses path then converts each ToolDescriptor to an internal Function using only name, parameters, and description: OpenAILLMClient.kt <https://github.com/JetBrains/koog/blob/10bba89b67929bab3617047a6a7c8d8cf3ff9185/prompt/prompt-executor/prompt-executor-clients/prompt-executor-openai-client/src/commonMain/kotlin/ai/koog/prompt/executor/clients/openai/OpenAILLMClient.kt#L346-L360>. The wire model itself already has strict, but it is internal and remains unset by that conversion: OpenAIResponsesAPI.kt <https://github.com/JetBrains/koog/blob/10bba89b67929bab3617047a6a7c8d8cf3ff9185/prompt/prompt-executor/prompt-executor-clients/prompt-executor-openai-client/src/commonMain/kotlin/ai/koog/prompt/executor/clients/openai/models/OpenAIResponsesAPI.kt#L1135-L1153> . That also means additionalProperties is not a good escape hatch for this particular field: it is flattened at the request root, whereas the desired value lives under each tools[] entry. The least fragile choices I see are: 1. Add a small Koog extension such as OpenAIResponsesParams.toolStrict: Boolean? (or a per-tool equivalent) and pass it into Function(strict = ...) in both the streaming and non-streaming Responses paths. 2. Until that is exposed, wrap/intercept the outgoing HTTP JSON and set tools[*].strict. This keeps the rest of Koog's request/streaming machinery, but it is still a temporary compatibility shim. 3. If several provider-specific fields are missing, implement a custom LLMClient for that provider instead of accumulating JSON rewrites. For a single field I would choose option 1 and upstream it; the underlying wire type is already present, so the patch should be small. Longer term, a provider-capability/escape-hatch API that preserves unknown nested fields would prevent Koog from becoming the lagging part whenever OpenAI-compatible APIs evolve. — Reply to this email directly, view it on GitHub <#2199?email_source=notifications&email_token=BSJ3M3FQWNEHHE73C7NXEA35I5XQBA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZZGQ2TOMJSUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVRTG633UMVZF6Y3MNFRWW#discussioncomment-17945712>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/BSJ3M3FSV6QSEBFTXOVGX4T5I5XQBAVCNFSNUABIKJSXA33TNF2G64TZHM4TONRQHE2TCNJWHNCGS43DOVZXG2LPNY5TCMBVGU3TOOBQUF3AE> . Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS <https://github.com/notifications/mobile/ios/BSJ3M3DYWEOJESATDIN6ZYD5I5XQBA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZZGQ2TOMJSUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVJTG633UMVZF62LPOM> and Android <https://github.com/notifications/mobile/android/BSJ3M3FOL3NDS5AUWLLY4DL5I5XQBA5CNFSNUABIM5UWIORPF5TWS5BNNB2WEL2ENFZWG5LTONUW63SDN5WW2ZLOOQXTCNZZGQ2TOMJSUZZGKYLTN5XKMYLVORUG64VFMV3GK3TUVZTG633UMVZF6YLOMRZG62LE>. Download it today! You are receiving this because you authored the thread.Message ID: ***@***.***>

[Bob Lee (bobleer)]

yeah, I think that split is probably inevitable, but I'd draw the boundary around wire protocols rather than “model management.” Model metadata and request-shape drift move at different speeds; if they're coupled, every new field turns into a framework release.

In BitFun we ended up keeping endpoint/API-format and model-capability facts in a catalog, while OpenAI Chat/Responses, Anthropic, and Gemini each own their request conversion and stream normalization. The important bit is still having an escape hatch for unknown nested fields—a capability table alone won't unblock tools[*].strict. The code split is here: https://github.com/GCWing/BitFun/tree/main/src/crates/adapters/ai-adapters