[FEATURE] Bedrock modelconfig allow to configure Claude settings

[marcofranssen]

📋 Prerequisites

• I have searched the existing issues to avoid creating a duplicate
• By submitting this issue, you agree to follow our Code of Conduct

📝 Feature Summary

Allow for Bedrock models to configure specific settings

❓ Problem Statement / Motivation

When running kagent with Claude 4.6 on Bedrock token consumption is massive compared to using claude code. It would be great if we can configure settings like effort and such.

💡 Proposed Solution

It would be great if following could be configured.

~/.claude/settings.json

{
  "awsAuthRefresh": "aws sso login --profile eks-testing-admin",
  "env": {
    "AWS_PROFILE": "bedrock",
    "AWS_REGION": "us-east-1",
    "CLAUDE_CODE_USE_BEDROCK": "true",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "us.anthropic.claude-opus-4-6-v1",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "us.anthropic.claude-sonnet-4-6",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "us.anthropic.claude-haiku-4-5-20251001-v1:0"
  },
  "model": "sonnet",
  "enabledPlugins": {
    "gopls-lsp@claude-plugins-official": true,
    "example-skills@anthropic-agent-skills": true
  },
  "effortLevel": "medium",
  "thinking": {
    "type": "adaptive",
    "display": "summarized"
  }
}

So users can define the model, effort and thinking parameters.

🔄 Alternatives Considered

N.A.

🎯 Affected Service(s)

Not Sure

📚 Additional Context

Normally my sonnet 4.6 cost is averaging at 15-20$ a day when doing all kind of development tasks.

With kagent this cost 🚀 went to 80-195$ a day for similar prompts like:

Figure out the root cause for crashing pods in namespace-x

In kagent I prompted way less then I do in my local claude-code.

🙋 Are you willing to contribute?

• I am willing to submit a PR for this feature

[mesutoezdil]

I had the same issue with Bedrock/Claude token costs being 4-5x higher than claude-code. Current workarounds:
i- ResourceQuotas on agent namespaces to limit compute/token usage
ii- Tool pruning -> remove unused tools so the agent doesn't call them
iii - system prompt engineering -> explicit "be concise, no thinking aloud" instructions
vi- haiku model for simple tasks, sonnet only for complex ones..
For your feature request -> yes, this would be great. ModelConfig with effortLevel, thinking.display, and model selection per agent would solve this cleanly. I would vote for it. I use namespace quotas + selective tool enablement to keep costs ~20% of what they were.

[dobesv]

Maybe context caching is not setup and working in your bedrock setup? You might want to setup agentgateway or LiteLLM in between kagent and bedrock, I think you can use it to tweak the requests to enable context caching.

[marcofranssen]

Maybe context caching is not setup and working in your bedrock setup? You might want to setup agentgateway or LiteLLM in between kagent and bedrock, I think you can use it to tweak the requests to enable context caching.

Interesting, any pointers to articles or repository that does such thing?

[marcofranssen]

What about doing something like a AnthropicModel CR that allows to configure Anthropic specific settings so e.g. Haiku and Sonnet and Opus can be combined in a agent. E.g. using Haiku for tool invocation, and Sonnet/Opus for interpreting and such?

I struggle to wrap my head around doing something useful with just Haiku at the moment. E.g. a K8s Agent with Haiku at the moment doesn't work for pretty basic questions like.

Give me all the crashing pods in the last 8 hours and the root cause.

It will simply run out of tokens.

But if we can combine Haiku and Sonnet in the same pod we might have it use Haiku for tools and Sonnet to do the reasoning. That might be a massive cost saver.

Not deep enough in the project yet, so above might be just a unfeasible brainfart.

[mesutoezdil]

What about doing something like a AnthropicModel CR that allows to configure Anthropic specific settings so e.g. Haiku and Sonnet and Opus can be combined in a agent. E.g. using Haiku for tool invocation, and Sonnet/Opus for interpreting and such?

I struggle to wrap my head around doing something useful with just Haiku at the moment. E.g. a K8s Agent with Haiku at the moment doesn't work for pretty basic questions like.

Give me all the crashing pods in the last 8 hours and the root cause.

It will simply run out of tokens.

But if we can combine Haiku and Sonnet in the same pod we might have it use Haiku for tools and Sonnet to do the reasoning. That might be a massive cost saver.

Not deep enough in the project yet, so above might be just a unfeasible brainfart.

This ties together nicely with what we're all seeing here. The workarounds we mentioned earlier (quotas, tool pruning, using simpler models for simpler tasks) do help control costs, but they don’t really address the root cause. The suggestions here go more in that direction:

nr1. context caching → avoids re-paying for repeated context

nr2. multi-model setup (Haiku for tools, Sonnet/Opus for reasoning) → better fit per task type

That basically formalizes what we’re all trying to approximate manually today. +1 to both ideas, and I think the original ModelConfig proposal (effort/thinking/model per agent) would fit very nicely on top to make this actually controllable in practice.

[dobesv]

Here's what CoPilot has to say about it:

Current State

The Bedrock integration in kagent uses the Bedrock Converse API (via boto3), which provides a unified interface across all Bedrock-supported models. However, the implementation does not include any support for prompt caching, which is an Anthropic API feature.

The relevant code shows that:

• The Bedrock client only passes standard Converse API parameters like temperature, maxTokens, topP, and stopSequences
• There is no handling for cache-related parameters or headers
• The extra_headers field in the Bedrock configuration explicitly notes it's not supported and logs a warning

Why This Matters for Your Issue

Related to issue #1721 you referenced, this is actually a compounding factor in the token consumption problem:

• No prompt caching - Context caching for Claude models (which can save 10-25% of tokens) isn't available
• Converse API limitations - Unlike the native Anthropic API, Bedrock's Converse API doesn't expose all Claude-specific features
• No effort/thinking configuration - As mentioned in your issue, model settings like effort level and extended thinking also aren't configurable

[dobesv]

Very unfortunate because context caching is a huge cost saver. Probably makes bedrock a very unattractive LLM provider option if it doesn't easily support it.