input_json_delta Does Not Match Expected Tags: 6 Fixes

Anthropic's streaming docs publish the exact events for a tool call. Trimmed to one block:

event: content_block_start
data: {"type":"content_block_start","index":1,"content_block":{"type":"tool_use","id":"toolu_01T1x1fJ34qAmk2tNTrN7Up6","name":"get_weather","input":{}}}

event: content_block_delta
data: {"type":"content_block_delta","index":1,"delta":{"type":"input_json_delta","partial_json":""}}

event: content_block_delta
data: {"type":"content_block_delta","index":1,"delta":{"type":"input_json_delta","partial_json":"{\"location\":"}}

event: content_block_delta
data: {"type":"content_block_delta","index":1,"delta":{"type":"input_json_delta","partial_json":" \"San"}}

event: content_block_delta
data: {"type":"content_block_delta","index":1,"delta":{"type":"input_json_delta","partial_json":" Francisc"}}

event: content_block_delta
data: {"type":"content_block_delta","index":1,"delta":{"type":"input_json_delta","partial_json":"o,"}}

event: content_block_delta
data: {"type":"content_block_delta","index":1,"delta":{"type":"input_json_delta","partial_json":" CA\"}"}}

event: content_block_stop
data: {"type":"content_block_stop","index":1}

event: message_delta
data: {"type":"message_delta","delta":{"stop_reason":"tool_use","stop_sequence":null},"usage":{"output_tokens":89}}

Three details decide whether your translator works. The input on content_block_start is literally {}, a placeholder marking the slot in the content array while the delta strings build the real value. The first partial_json is an empty string. And the boundaries are arbitrary, splitting Francisco across two events, so no fragment parses alone. The deltas are strings, the final tool_use.input is always an object, and the object you send back in messages never exists on the wire. You construct it.

Each block's index matches its position in the final Message content array, and server_tool_use blocks stream input_json_delta fragments the same way. A translator switching only on type == "tool_use" drops server-side tool blocks.

The report behind that error came from MaxKB, reproduced on v2.10.4-lts and v2.10.2-lts with claude-sonnet-5. Reading apps/application/flow/tools.py at tag v2.10.4-lts confirms the cause first-hand: the tool-streaming path carries tool_call_chunks, tool_calls and invalid_tool_calls, and no occurrence of input_json_delta, partial_json or content_block. It understands OpenAI-shaped deltas only. The same agent and prompt on an OpenAI-shaped provider with gpt-4o-mini returns the tool's value.

Two things make it worse than a loud 400. The product returns the BadRequestError text as HTTP 200 with that text as the answer body, so end users read the exception as the assistant's reply. And tools on that path require stream true, so no non-streaming workaround exists. The one maintainer comment, dated 2026-08-12, says they have no Anthropic account and cannot reproduce it.

The shape that produced it:

"messages": [
  {"role": "user", "content": "How much is the DJI Neo?"},
  {"role": "assistant", "content": [
    {"type": "text", "text": "Let me check the price."},
    {"type": "input_json_delta", "partial_json": "{\"query\": \"DJI Neo\"}"}
  ]}
]

messages.1.content.1 is the second message and its second content block: the raw delta sitting where an assembled block belongs. The corrected turn keeps both blocks in order, so you can diff them:

{
  "role": "assistant",
  "content": [
    {"type": "text", "text": "Let me check the price."},
    {
      "type": "tool_use",
      "id": "toolu_01T1x1fJ34qAmk2tNTrN7Up6",
      "name": "live_price",
      "input": {"query": "DJI Neo"}
    }
  ]
}

The id is the one content_block_start carried, not a fresh one. A request-side tool_use block requires id matching ^[a-zA-Z0-9_-]+$, name of 1 to 200 characters, and input typed as an object. input_json_delta is not among the tags accepted inside messages[].content:

That union grows as beta tool families ship, so validate against membership rather than a frozen list. No delta type name belongs in it: input_json_delta carries partial_json for tool_use and server_tool_use, text_delta carries text, and thinking_delta and signature_delta carry the two halves of a thinking block. Each names a stream event, not a block.

The same MaxKB defect throws a second, different 400: messages: text content blocks must be non-empty. The report treats it as the other variant of one failure, and the single OpenAI-shaped code path above explains both: the unassembled delta goes out verbatim and the text block beside it is empty.

The Messages API declares text on a text content block as a string with minLength 1, so an empty text block is rejected rather than ignored. A translator that opens a block at index 0 for streamed prose, gets none because the turn was a tool call, and serializes it anyway fails validation even when the tool_use block beside it is perfect. The LiteLLM report in Failure 3 shows that block on the wire, {"type": "text", "text": ""} at index 0 followed immediately by content_block_stop.

The fix is a filter at assembly time: drop any text block whose accumulated string has length zero, so it never enters the stored transcript.

An open report filed 2026-07-26 against LiteLLM v1.93.0 on the ollama_chat provider behind /v1/messages shows a turn where the tool block is correct and only the framing is wrong. The log carries content_block_start at index 2 with {"type": "tool_use", "id": "...", "name": "read", "input": {}}, one content_block_delta with {"type": "input_json_delta", "partial_json": "{\"path\": \"/tmp/ab/report.txt\"}"}, content_block_stop, then message_delta with {"stop_reason": "end_turn"}.

Anthropic-shaped tool runners key off stop_reason == "tool_use" to decide whether to execute the block. Under end_turn the turn reads as final assistant text and the tool never runs. The reported effect is payloads=0, tools=0 and an agent saying it could not generate a response. The identical request with stream false returns stop_reason tool_use with the full input, which puts the break in the streaming translation path, and it reproduces deterministically from a single-tool request of roughly 284 input tokens up to 40 tools and roughly 27,900 input tokens.

If you own the translator, set stop_reason to tool_use whenever the streamed message carries a tool_use block, whatever the upstream finish reason was called. If you own the client, this is one of the shapes that makes an agent look finished when it did nothing, the problem in detecting agents that report success without acting.

The mirror image is an open report filed 2026-05-29 against LiteLLM Proxy v1.85.0 in front of a vLLM v0.21.0 backend serving DeepSeek V4 Pro. No tool is involved: the response is plain text, and the symptom is an Anthropic-compatible client receiving no streamed text at all. On /v1/chat/completions the same stack streams correctly with delta.content; on /v1/messages it emits repeated {"type": "content_block_delta", "index": 0, "delta": {"type": "input_json_delta", "partial_json": ""}} until the message ends. Every one of those fragments is empty, so the answer's characters are dropped rather than misrouted.

The reporter's hypothesis is that the adapter treats the presence of a tool_calls key as a tool-use signal even when the array is empty; the upstream chunk shown is {"delta": {"content": "1\n", "tool_calls": []}}. That has not been confirmed against the adapter source, so treat it as a lead, not a root cause. The remedy is safe either way: branch on a non-empty tool_calls array, and route delta.content to text_delta. Why the array is empty at all is covered in why a vLLM backend returns an empty tool_calls array.

An open request filed 2026-07-28 against Dynamo asks for one guarantee: do not emit content_block_stop for a tool_use block until the accumulated input_json_delta fragments form complete JSON. Some Anthropic clients treat that event as the point where the tool input is final, so sending it early leads them to discard trailing fragments or observe {}.

Closing a block runs through a generic stop helper that emits content_block_stop unconditionally. That is the guarantee the Dynamo issue asks for, absent from the release read above.

That gap matters more inside a private perimeter than on a hosted endpoint. A regulated deployment running an Anthropic-shaped agent runtime against its own GPUs terminates /v1/messages on the inference server's entrypoint or on a translating proxy, and both are the code that gets this wrong. A hosted endpoint answers a malformed replay with a 400 you can log; a self-hosted path may accept the same array and run a tool with the wrong arguments, or none at all, which is an agent that quietly loses its tools rather than a loud rejection. Which product sits in that seat is covered in choosing the gateway in front of your models.

An open report filed 2026-07-28 in the copilot-cli repository measured the same request twice against an Anthropic-shaped /v1/messages endpoint with claude-opus-5, streaming, varying only max_tokens.

Time to first byte in the first run was 3.8 seconds, after which the connection sat open with zero bytes for 329.5 seconds and then delivered all 85,744 characters of tool arguments in about 3.3 seconds. Both output_tokens figures are totals for the response, not the size of the tool argument, and the per-token column is the reporter's own arithmetic.

The second run is the instructive one. Capping max_tokens at 8,000 did not make the tool call arrive sooner, it made it arrive never: the turn stopped at max_tokens with zero characters delivered. Anthropic's guidance is to retry with a higher max_tokens, because a partially streamed tool call cannot be resumed.

The mechanism is documented, and it is not a proxy. Anthropic's fine-grained tool streaming page states that without eager_input_streaming the API buffers and validates each parameter value before streaming it back, so nothing prints for a large parameter until the model has finished it. Current models also emit one complete key and value from input at a time, so gaps between events are expected. ping events are no heartbeat: the docs promise only that streams may include any number of them, and the measured run saw zero. The abort reported here is a threshold inside the caller, not an API timeout, surfaced by Claude Code as a stalled mid-stream response after 300 seconds without content events.

The fix is one field on the tool definition, and it is not a beta feature.

curl https://api.anthropic.com/v1/messages \
  -H "content-type: application/json" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-5",
    "max_tokens": 65536,
    "tools": [
      {
        "name": "make_file",
        "description": "Write text to a file",
        "eager_input_streaming": true,
        "input_schema": {
          "type": "object",
          "properties": {
            "filename": {"type": "string"},
            "lines_of_text": {"type": "array"}
          },
          "required": ["filename", "lines_of_text"]
        }
      }
    ],
    "messages": [{"role": "user", "content": "Write a long poem into a file called poem.txt"}],
    "stream": true
  }'

The field is tri-state, per the Python SDK's own type: true streams the parameters incrementally with types inferred on the fly, false keeps that tool buffered even when the fine-grained-tool-streaming beta is active, and null follows the default from beta headers. The legacy fine-grained-tool-streaming-2025-05-14 header still enables it for tools that leave the field unset, but the per-tool field replaces it, and that header cannot be combined with a computer use or browser use toolset entry.

Two consequences. With buffering off the accumulated string is no longer guaranteed to parse, so this fix and the accumulator below ship together. And a self-hosted endpoint has no equivalent knob: that trade-off is not yours to set, and latency work happens in the serving layer instead.

Before writing one, check whether you need to.

Four rules are specific to this protocol rather than to partial JSON in general. The generic version, including rendering half-built fields into a UI, is streaming partial JSON without breaking state.

Key the buffer on the content block index. Anthropic's index is the block's position in the final Message content array, which includes text and thinking blocks, not the position in an OpenAI tool_calls array. The two diverge the moment the turn opens a text or thinking block first, and keying on the wrong one merges two calls' arguments or scatters one across two buffers.

Tolerate an empty first fragment. The documented example opens with partial_json of "", and so do the traces above. Concatenation handles that for free; a guard treating the first fragment as the start of an object does not.

Treat a stream that ends without content_block_stop as a failed tool call. Anthropic's error recovery guidance states that tool use and extended thinking blocks cannot be partially recovered, and that streaming resumes only from the most recent text block.

Reject, do not repair. When the accumulation does not parse, return it to the model rather than completing it yourself.

import json
import anthropic

client = anthropic.Anthropic()
tool_inputs: dict[int, str] = {}  # content block index -> accumulated JSON string

with client.messages.stream(
    model="claude-opus-5",
    max_tokens=1024,
    tools=[
        {
            "name": "get_weather",
            "description": "Get current weather for a city",
            "eager_input_streaming": True,
            "input_schema": {
                "type": "object",
                "properties": {"city": {"type": "string"}},
                "required": ["city"],
            },
        }
    ],
    messages=[{"role": "user", "content": "Weather in Paris?"}],
) as stream:
    for event in stream:
        match event.type:
            case "content_block_start" if event.content_block.type == "tool_use":
                tool_inputs[event.index] = ""
            case "content_block_delta" if event.delta.type == "input_json_delta":
                tool_inputs[event.index] += event.delta.partial_json
            case "content_block_stop" if event.index in tool_inputs:
                raw_input = tool_inputs.pop(event.index)
                try:
                    parsed = json.loads(raw_input)
                except json.JSONDecodeError:
                    print(f"Invalid tool input: {raw_input}")
                else:
                    print(f"Tool input: {parsed}")

# Any index still left in tool_inputs never received content_block_stop.
for index, partial in tool_inputs.items():
    print(f"Block {index} never closed, do not execute: {partial}")

The final loop is rule three in code. Add an error branch beside it, because error events are in-band: the docs show event: error carrying an overloaded_error that would be an HTTP 529 outside streaming, and a parser switching only on content_block_* reads it as a stream that simply stopped.

For rule four, Anthropic publishes the remedy: hand the raw string back as a tool_result with is_error true, wrapped under a single key and built with a JSON library rather than by concatenating strings.

{
  "type": "tool_result",
  "tool_use_id": "toolu_01A09q90qw90lq917835lq9",
  "is_error": true,
  "content": "{\"INVALID_JSON\": \"<the unparseable input you received>\"}"
}

Brace balancing and repair libraries do the opposite: they invent arguments the model never emitted. When the truncation came from max_tokens, retry with a higher limit.

event: content_block_start
data: {"type":"content_block_start","index":1,"content_block":{"type":"tool_use","id":"toolu_test_truncated","name":"write_report","input":{}}}

event: content_block_delta
data: {"type":"content_block_delta","index":1,"delta":{"type":"input_json_delta","partial_json":""}}

event: content_block_delta
data: {"type":"content_block_delta","index":1,"delta":{"type":"input_json_delta","partial_json":"{\"path\": \"/tmp/report.txt\", \"body\": \"The quarter"}}

event: message_delta
data: {"type":"message_delta","delta":{"stop_reason":"max_tokens","stop_sequence":null},"usage":{"output_tokens":8000}}

event: message_stop
data: {"type":"message_stop"}