Extra 'caller' Field in Request Breaks computer-use Between v0.74.1 and v0.75.0

[paragchandra]

I observe the following with my computer-use application when I upgrade to v0.75.0 of the Anthropic Python SDK:

anthropic.BadRequestError: Error code: 400 - {'type': 'error', 'error': {'type': 'invalid_request_error', 'message': 'messages.1.content.1.tool_use.caller: Extra inputs are not permitted'}, 'request_id': 'req_011CWtR3e2Pnww7S8JnEs2DE'}

This error does not occur w/ v0.74.1 of the same SDK. I have attached some Python code which should enable you to reproduce the problem.

simple_demo.py

[paragchandra]

I'm running on macOS 15.7.2, w/ Python 3.12.12

[Ashutosh0x]

Root Cause Analysis

I investigated this issue and found that the caller field was added to BetaToolUseBlockParam in a recent commit (post-v0.74.1):

File: src/anthropic/types/beta/beta_tool_use_block_param.py

# Line 29 - Added in recent version
caller: Caller
"""Tool invocation directly from the model."""

When users pass tool_result content blocks from older code/patterns, the SDK now includes this caller field in the request, which the API rejects with Extra inputs are not permitted.

Note

This file is auto-generated from the OpenAPI spec (see file header: "File generated from our OpenAPI spec by Stainless"). Per CONTRIBUTING.md, external contributors cannot safely modify generated files - this likely needs to be addressed by the Anthropic team in the OpenAPI spec or backend.

Workaround

Users experiencing this issue may need to:

1. Pin to v0.74.1: pip install anthropic==0.74.1
2. Wait for Anthropic to release a fix

---

Analysis from @Ashutosh0x

[paragchandra]

Thanks for taking a look. Came here to post that the workaround (which Claude also suggested):

block.model_dump(exclude={"caller"})

works, so that enabled me to upgrade to v0.75

[Ashutosh0x]

Hey! I investigated this and found the root cause.

Root Cause

The caller field was added to BetaToolUseBlockParam (the request type) in commit 9843a8e (Nov 24, 2025), but the API only accepts caller as an output-only field in responses.

When you convert API response content blocks back to params for multi-turn conversations (e.g., passing message.content back), the caller field gets included in the request payload and the API rejects it with:

'messages.1.content.1.tool_use.caller: Extra inputs are not permitted'

Where the issue is

Looking at the type definitions:

• beta_tool_use_block.py - Response type has caller: Optional[Caller] = None
• beta_tool_use_block_param.py - Request type also has caller: Caller

The Param type shouldn't include caller since it's output-only.

Suggested Fix

Since these files are auto-generated from OpenAPI spec by Stainless, the fix would need to be in the OpenAPI spec to mark caller as readOnly: true (output-only), which would exclude it from the Param types.

Workaround for now: Strip the caller field from tool_use blocks before sending them back:

for msg in messages:
    if msg.get("content"):
        for block in msg["content"]:
            if isinstance(block, dict) and block.get("type") == "tool_use":
                block.pop("caller", None)

[felixfbecker]

@Ashutosh0x are you using the client.beta.messages.create() function or client.messages.create()? And what beta headers are you passing?

[Ashutosh0x]

@felixfbecker I'm using client.beta.messages.create() (specifically the sync version, though the async one is also affected) with the computer-use-2024-10-22 beta header passed via the betas parameter.

My investigation confirms this only affects the beta clients, as the standard ToolUseBlock response doesn't include the caller field. The issue occurs when taking a tool_use block from a previous API response (which now includes the caller field in v0.75.0) and passing it back into a subsequent request.

PR #1126 and #1135 provide both the type-level correction to remove it from input params and the runtime stripping logic to ensure it doesn't leak into the request payload.

[felixfbecker]

Okay thanks for those details! I think we've identified the issue on our end — the caller field has a default value which the SDK applies even when the beta header is not provided, resulting in the 400 validation error. We're fixing this by removing the default value from the schema which will propagate to the SDK.

[Ashutosh0x]

@felixfbecker Thanks for the update! That makes complete sense if the schema has a default value, the generated SDK will always include it in the request payload regardless of whether it was explicitly provided in the input.

Removing the default from the schema is definitely the right long-term fix. For the short term, PR #1135 (which strips it at runtime during transformation) and PR #1126 (which removes it from the input types) serve as a stopgap to unblock users who are seeing this on the current version.

Should I keep those PRs open for now as a safety net, or would you prefer I wait for the schema fix to roll out and propagate to the SDK? I'd be happy to close them if you expect the schema update to land soon.

[felixfbecker]

we'll do the SDK updates through the schema so you can close those PRs, I want to avoid conflicts with the codegen. We're also deploying a band aid fix in the API to fix it for affected users on current/older SDK versions.

[Ashutosh0x]

@felixfbecker Got it, thanks! Closing PR #1126 and #1135 now to avoid any conflicts. Glad to hear there's an API-side band-aid coming as well.

[localden]

Thank you for the report and the clear repro. This has since been addressed on main - you can see the current behavior at src/anthropic/types/beta/beta_tool_use_block.py:28 and src/anthropic/types/beta/beta_tool_use_block_param.py:30. Closing as resolved - if you're still hitting it on the latest release, please reopen with the SDK version and we'll take another look.