LiteLLM error: Anthropic doesn't support tool calling without tools= param specified

[jessevdp]

I'm running into some issues related to my provider: LiteLLM proxy. I realize this is a somewhat niche case, sorry 😬. See my config below.

Is this somehow something I can resolve client side?

AI_APICallError: litellm.UnsupportedParamsError: Anthropic doesn't support tool calling without tools= param specified. Pass tools= param OR set litellm.modify_params = True // litellm_settings::modify_params: True to add dummy tool to the request.

Dummy session with the error (error not shown in web UI for some reason?): https://opencode.ai/s/SWAsOXyz

My config

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "my-litellm-provider": {
      "name": "My LiteLLM Provider",
      "npm": "@ai-sdk/openai-compatible",
      "options": {
        "baseURL": "https://my-provider.com",
        "apiKey": "...",
        "includeUsage": true
      },
      "models": {
        "claude-4-5-sonnet": {
          "name": "Anthropic Claude 4.5 Sonnet",
          "release_date": "2025-09-29",
          "attachment": true,
          "reasoning": true,
          "temperature": true,
          "tool_call": true,
          "limit": {
            "context": 200000,
            "output": 64000
          },
          "options": {
            "thinking": {
              "type": "enabled",
              "budget_tokens": 16000,
            },
          }
        },
      }
    }
  }
}

[jessevdp]

It seems to only happen / error with the thinking options added.

[rekram1-node]

@jessevdp is your proxy dropping metadata? it seems like the issue is on your proxy rather than opencode.

If you turn on reasoning we need to keep the reasoning chunks otherwise anthropic with return error

[jessevdp]

Thanks for getting back to me!

I might have been too quick to come to conclusions. I turned off thinking mode because this LiteLLM proxy distributes between Google Vertex and AWS Bedrock and it seems when forwarding to Vertex thinking mode was giving an error.

(I left a comment on a closed, seemingly sorta related issue #2599 (comment))

After turning thinking mode off I was back to not getting those tools related error messages and continued work. But later in the day the error messages returned.

What might have happened is that earlier in the day the issue was still there, but LiteLLM was falling back / retrying on Vertex (Bedrock is our main provider) and since thinking was now disabled those requests would succeed. We might have simply run out of Vertex capacity later that day.

What’s interesting is that whenever I get this error and I just type “go” the agent seems fine to just carry on. But that might again just be related to capacity on Google Vertex I suppose…

---

Anyway, I probably need to do some more digging to figure out what’s happening.

Is there some way to enable a nice HTTP log? That way I can inspect the request that resulted in this issue. I’ve tried log level DEBUG but that doesn’t seem to be it.

[rekram1-node]

hm dont think we do any http logs now? I feel like we used to do it may still be possible id have to check

[mschenk42]

I am also encountering this issue. This appears to occur consistently when the session is compressed either manually or automatically upon reaching the context limit. Otherwise, the system functions flawlessly. Given that it appears to be triggered by compression, it does not appear to be related to using the Lite LLM Proxy.

I wanted to give you a heads up about the configuration. This is the main agent that uses subagents. I'm wondering if there's anything to do with the subagent sessions?

When running without subagents manual compaction works fine.

[rekram1-node]

would it be fixed if we just passed an empty tools array when we compact?

[mschenk42]

Yeah, based on the error message that seems like it would resolve the problem.

[rekram1-node]

ill try that

[rekram1-node]

Should be fixed by: 0af4505

Will release soon

[mschenk42]

Unfortunately that didn't work. I'm going to reach out to our team that manages our Lite LLM Proxy. Thanks for trying to resolve. I'll share here if I find a way to resolve this.