# LiteLLM 1.111.0-dev.4: Keep Spend-Log Token Redaction Enabled

The development release makes free-form secret scanning opt-in, so existing prompt-storage configurations need a separate privacy check.

By Paras Madan | 2026-11-15


LiteLLM 1.111.0-dev.4 makes token-shaped secret scanning in spend logs opt-in. If your deployment stores request and response content, set `general_settings.redact_tokens_in_spend_logs: true` to retain that scanning. This is a development release change, not evidence that every LiteLLM deployment has exposed credentials.

The [release's action-required notice](https://github.com/BerriAI/litellm/releases/tag/v1.111.0-dev.4), published November 15, flags the setting explicitly. The distinction matters because keeping a spending ledger and retaining the text that generated the spending are different decisions.

## What changes when the setting is absent

The [tagged configuration definition](https://github.com/BerriAI/litellm/blob/v1.111.0-dev.4/litellm/proxy/_types.py) defaults `redact_tokens_in_spend_logs` to false. The separate `store_prompts_in_spend_logs` setting controls storing request messages and responses; its documented default remains false.

For a deployment that has already chosen to store that content, the redaction setting should now be explicit:

```yaml
general_settings:
  redact_tokens_in_spend_logs: true
```

This snippet does not enable prompt storage. Keep that choice separate, and do not turn it on merely to follow a redaction tutorial. If your team does not need message content in its spending records, collecting less remains the simpler privacy boundary.

The [change description](https://github.com/BerriAI/litellm/pull/51729) says the previous implicit scanning added CPU and thread-offloading overhead. It also explicitly leaves full HTTP load comparison unfinished. Do not interpret the change as a quantified performance improvement for your traffic.

## Token scanning is not the same as masking credential fields

The same change preserves credential-field masking. It changes the additional scan of free-form stored text for token-shaped secrets. A tool result can contain such a string in ordinary output rather than in a field named for an API key, which is why the distinction affects agent workloads.

The [released spend-log implementation](https://github.com/BerriAI/litellm/blob/v1.111.0-dev.4/litellm/proxy/spend_tracking/spend_tracking_utils.py) checks for an explicit true value before running token redaction. Leaving the setting absent is not equivalent to opting in.

Nor does enabling it promise that every secret or piece of personal information will be removed. Pattern-based protection is useful, but it is not a reason to retain arbitrary tool output indefinitely. Access controls, retention and the decision to store content still need their own review.

## Check the upgrade without using real credentials

Treat this as an acceptance test for your candidate deployment, not a test I have executed. Use an isolated staging gateway and fake input. Never send a working credential through a model just to find out whether a log scanner catches it.

First record the exact package or image version and the effective values of both settings. Then send a harmless request with a synthetic token-shaped sentinel in a tool-result-like text field. Use a deliberately fake value matching a pattern the redactor supports, and compare the stored text with the expected masked result. A random string that matches no supported pattern cannot demonstrate whether scanning is enabled.

Repeat with redaction explicitly enabled, absent and false in the disposable environment. Also check the case where prompt storage is off. Inspect the persisted record, not just the gateway response: successful inference says nothing about what the logging path saved.

Keep the fixture and expected outcomes with the upgrade review. The important result is that the deployed configuration produces the intended records, not simply that a YAML file contains the flag.

## Existing logs need a separate decision

Do not assume changing this setting cleans up records already stored. Review the period in which content storage was enabled and determine whether sensitive tool output could have entered that path. Limit access to potentially affected logs while an authorized administrator investigates, without copying their contents into another AI service.

If a real credential was retained where it should not have been, follow the relevant credential-rotation and incident process. A redaction flag is prevention for the logging path, not a substitute for responding to an exposure that has already happened.

This prerelease makes an implicit protection an explicit operating choice. Before upgrading, decide what belongs in the spending ledger and verify that the deployed logger follows that decision.

I'm Paras. I work at the intersection of AI, engineering and distribution.

I help AI infrastructure teams turn configuration changes and operational risks into clear technical guides.

[Book a 30-minute call](https://cal.com/paras-madan/30min).