BerriAI/litellm · error · BedrockError

CountTokens processing error: {e}

Error message

CountTokens processing error: {e}

What it means

The generic fallback exception handler in the async CountTokens handler: any exception that is neither BedrockError nor httpx.HTTPStatusError is wrapped into BedrockError(status_code=500, message='CountTokens processing error: {e}'). The original exception text is preserved in the message, so the root cause is readable there.

Source

Thrown at litellm/llms/bedrock/count_tokens/handler.py:130

            final_response: Final = self.transform_bedrock_response_to_anthropic(bedrock_response)

            verbose_logger.debug("Final response: %s", final_response)

            return final_response

        except BedrockError:
            # Re-raise Bedrock 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 BedrockError(
                status_code=e.response.status_code,
                message=e.response.text,
            )
        except Exception as e:
            verbose_logger.error("Error in CountTokens handler: %s", e)
            raise BedrockError(
                status_code=500,
                message=f"CountTokens processing error: {e}",
            )

View on GitHub (pinned to 6c2dcb801b)

Solutions

  1. Read the wrapped message — it contains the original exception repr, which names the real fault
  2. Enable litellm verbose logging (litellm.set_verbose=True or LITELLM_LOG=DEBUG) to see the logged root cause
  3. Fix the underlying issue: retry on network errors, simplify the message payload if transformation fails
Defensive patterns

Strategy: try-catch

Try / catch

try:
    result = await count_tokens_handler(...)
except BedrockError as e:
    if e.status_code == 500 and e.message.startswith("CountTokens processing error"):
        # unwrap root cause text and retry on transient network causes
        if "timeout" in e.message.lower() or "connect" in e.message.lower():
            await asyncio.sleep(1); retry()
        else:
            raise

Prevention

When it happens

Trigger: Response JSON parsing failures (invalid JSON body), errors inside request transformation (transform_bedrock_request_to_anthropic), network errors other than HTTPStatusError (ConnectError, ReadTimeout after the 30s httpx timeout), or None values in litellm_params breaking string handling.

Common situations: Transient network breakage, an AWS endpoint returning HTML error pages (proxy interference), passing unsupported input shapes (e.g. tool blocks) the transformer does not expect.

Related errors


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