Description
When using an Amazon Bedrock model through the Converse protocol, the topK generation option is silently dropped. fromRequest in packages/llm/src/protocols/bedrock-converse.ts builds inferenceConfig from maxTokens/temperature/topP/stop only, and never reads generation.topK. The Anthropic Messages protocol (anthropic-messages.ts) does map it (top_k: generation?.topK), so the two paths diverge.
Per the AWS Converse API reference, top_k is not part of inferenceConfig and must be passed via additionalModelRequestFields (e.g. { "top_k": 200 }). The Converse body schema already declares that field, it's just never populated.
Steps to reproduce
- Build a request for a Bedrock model with
generation: { topK: 40 }.
LLMClient.prepare(request).
prepared.body contains no top_k anywhere (neither inferenceConfig nor additionalModelRequestFields), so the value is dropped before the request is signed.
Description
When using an Amazon Bedrock model through the Converse protocol, the
topKgeneration option is silently dropped.fromRequestinpackages/llm/src/protocols/bedrock-converse.tsbuildsinferenceConfigfrommaxTokens/temperature/topP/stoponly, and never readsgeneration.topK. The Anthropic Messages protocol (anthropic-messages.ts) does map it (top_k: generation?.topK), so the two paths diverge.Per the AWS Converse API reference,
top_kis not part ofinferenceConfigand must be passed viaadditionalModelRequestFields(e.g.{ "top_k": 200 }). The Converse body schema already declares that field, it's just never populated.Steps to reproduce
generation: { topK: 40 }.LLMClient.prepare(request).prepared.bodycontains notop_kanywhere (neitherinferenceConfignoradditionalModelRequestFields), so the value is dropped before the request is signed.