BerriAI/litellm · error · ValueError

max_bytes_per_call must be >= 0 (0 disables the cap; positiv

Error message

max_bytes_per_call must be >= 0 (0 disables the cap; positive values enforce it)

What it means

ValueError raised in the Compresr guardrail constructor when max_bytes_per_call is negative. The parameter controls how many bytes of original prompt content the guardrail retains per call (0 disables the cap; the default is _DEFAULT_MAX_BYTES_PER_CALL); a negative value is meaningless, so config validation rejects it immediately at startup.

Source

Thrown at litellm/proxy/guardrails/guardrail_hooks/compresr/compresr.py:547

        self.compression_model = model or DEFAULT_COMPRESSION_MODEL
        self.target_compression_ratio = (
            DEFAULT_TARGET_COMPRESSION_RATIO if target_compression_ratio is None else target_compression_ratio
        )
        self.coarse = True if coarse is None else coarse
        self.min_chars_to_compress = (
            DEFAULT_MIN_CHARS_TO_COMPRESS if min_chars_to_compress is None else min_chars_to_compress
        )
        self.compress_tool_outputs = True if compress_tool_outputs is None else compress_tool_outputs
        self.compress_system = False if compress_system is None else compress_system
        self.compress_history = False if compress_history is None else compress_history
        self.compress_last_user = False if compress_last_user is None else compress_last_user
        self.enable_retrieval = True if enable_retrieval is None else enable_retrieval
        self.unreachable_fallback: Literal["fail_closed", "fail_open"] = (
            "fail_open" if unreachable_fallback == "fail_open" else "fail_closed"
        )
        self.max_bytes_per_call = _DEFAULT_MAX_BYTES_PER_CALL if max_bytes_per_call is None else max_bytes_per_call
        if self.max_bytes_per_call < 0:
            raise ValueError("max_bytes_per_call must be >= 0 (0 disables the cap; positive values enforce it)")
        self.allow_bypass_header = False if allow_bypass_header is None else allow_bypass_header
        # Dynamic (adaptive) compression — latte_v2 only, on by default: the server
        # picks the ratio per input instead of honoring target_compression_ratio.
        self.dynamic = True if dynamic is None else dynamic
        self.dynamic_min_ratio = dynamic_min_ratio
        self.dynamic_max_ratio = dynamic_max_ratio
        # Passthrough of extra compression params forwarded verbatim, so a new
        # Compresr feature works without changing this guardrail. Named fields win;
        # request-content fields are stripped.
        reserved_keys: Final = _RESERVED_COMPRESSION_PARAM_KEYS.intersection(compression_params or {})
        if reserved_keys:
            verbose_proxy_logger.warning(
                "Compresr: ignoring reserved compression_params keys %s", sorted(reserved_keys)
            )
        self.compression_params: dict[str, object] = {
            k: v for k, v in (compression_params or {}).items() if k not in _RESERVED_COMPRESSION_PARAM_KEYS
        }
        self.async_handler = get_async_httpx_client(

View on GitHub (pinned to 77b7c6c40c)

Solutions

  1. Use 0 to disable the cap or a positive byte count to enforce it.
  2. If the value comes from an env var or template, add a max(0, int(...)) guard before it reaches the config.
  3. Reload the proxy after correcting the value.

Example fix

# before
litellm_params:
  guardrail: compresr
  max_bytes_per_call: -1

# after — cap disabled explicitly
litellm_params:
  guardrail: compresr
  max_bytes_per_call: 0
Defensive patterns

Strategy: validation

Validate before calling

raw = litellm_params.get("max_bytes_per_call")
if raw is not None:
    v = int(raw)
    assert v >= 0, f"max_bytes_per_call must be >= 0 (0 disables cap); got {v}"

Type guard

from typing import Any
def is_non_negative_int_or_none(v: Any) -> bool:
    return v is None or (isinstance(v, int) and not isinstance(v, bool) and v >= 0)

Prevention

When it happens

Trigger: Passing max_bytes_per_call: -1 (or any negative number) in the guardrail litellm_params — often a typo, a mistaken '0 means unlimited, so -1 must mean something' assumption, or a templated/env-derived value computing to a negative.

Common situations: Operators copying example configs and changing the number; arithmetic in config generation (e.g., default - buffer) producing negatives; confusing '0 disables the cap' semantics with sentinel negative values.

Understand the failure class

Background: Config validation failed: what "invalid value for {key}" and settings-rejection errors mean across 19 open-source libraries — this error's family across 19 libraries.

Related errors

AI-assisted analysis of BerriAI/litellm@77b7c6c40c (2026-08-18). Data as JSON: /api/errors/d031446539cf6a91. Report an issue: GitHub.