BerriAI/litellm · error · AnthropicError

CountTokens processing error: {e}

Error message

CountTokens processing error: {e}

What it means

This is the catch-all branch of the Azure Anthropic CountTokens passthrough handler: any exception that is not an AnthropicError and not an httpx.HTTPStatusError (those preserve the real status code) is wrapped in AnthropicError(500, 'CountTokens processing error: {e}'). It usually masks a bug or an unexpected client-side failure (JSON decode, connection, type error) rather than an Anthropic API rejection.

Source

Thrown at litellm/llms/azure_ai/anthropic/count_tokens/handler.py:124

            verbose_logger.debug("Azure AI Anthropic response: %s", azure_response)

            # Return Anthropic-compatible response directly - no transformation needed
            return azure_response

        except AnthropicError:
            # Re-raise Anthropic exceptions as-is
            raise
        except httpx.HTTPStatusError as e:
            # HTTP errors - preserve the actual status code
            verbose_logger.error("HTTP error in CountTokens handler: %s", e)
            raise AnthropicError(
                status_code=e.response.status_code,
                message=e.response.text,
            )
        except Exception as e:
            verbose_logger.error("Error in CountTokens handler: %s", e)
            raise AnthropicError(
                status_code=500,
                message=f"CountTokens processing error: {e}",
            )

View on GitHub (pinned to 6c2dcb801b)

Solutions

1. Read the text after 'CountTokens processing error:' — it is str(e) of the underlying exception and names the true fault.
2. Enable verbose logging (litellm.verbose = True / LITELLM_LOG=DEBUG) to see the full traceback logged just before the wrap.
3. If a gateway/WAF sits in front of Azure, whitelist the count_tokens path and check its logs for the same request.
4. Reproduce with a direct httpx call to the Azure anthropic endpoint to isolate whether litellm or the network is at fault; if litellm, upgrade — this path frequently fixes schema bugs.

def is_count_tokens_wrap(e: BaseException) -> bool:
    return type(e).__name__ == 'AnthropicError' and str(e).startswith('CountTokens processing error')

try:
    resp = count_tokens_via_azure(payload)
except Exception as e:
    if is_count_tokens_wrap(e):
        logger.exception('underlying cause: %s', e)  # real exception is embedded
        return None  # count-tokens is advisory; degrade gracefully
    raise

When it happens

Trigger: POST to the azure-anthropic count_tokens route where the upstream returns a non-JSON body, the connection resets mid-response, or a code bug (e.g. unexpected response shape) raises; the original exception's message is embedded after the colon.

Common situations: Proxy in front of Azure Foundry returning HTML error pages (WAF, auth gateway); intermittent network drops; mismatch between deployed litellm version and Anthropic response schema after an API update.

Related errors

• Azure api base not found
• Missing Azure API Base - Please set `api_base` or `AZURE_API
• AZURE_SENTINEL_DCR_IMMUTABLE_ID is required. Set it as an en
• AZURE_SENTINEL_ENDPOINT is required. Set it as an environmen
• AZURE_SENTINEL_TENANT_ID or AZURE_TENANT_ID is required. Set

AI-assisted analysis of BerriAI/litellm@6c2dcb801b (2026-08-15). Data as JSON: /api/errors/40af4d8b096b3a75. Report an issue: GitHub.