LiteLLM’s November 4, 2026 release, v1.106.7, removes the bundled workers that run Lens investigations. Teams relying on that analysis of recorded AI-agent activity need a deployment decision before upgrading: how to preserve the workflow, or whether to stop using it.
Lens is designed to review an agent’s recorded steps, identify patterns and connect findings to their supporting evidence, according to its launch announcement. The worker is the service doing those investigations. The removal notice concerns that bundled Lens setup—not every LiteLLM user or every request sent to an AI model.
Clearing the deployment error does not restore investigations
The first barrier is in Helm, the tool used to install the software on Kubernetes. The release-tagged chart refuses to render its deployment configuration when lensWorker.enabled is true. Removing or disabling that setting clears this particular guard; leaving it enabled blocks the deployment.
The second barrier is separate. In v1.106.7, the gateway’s worker-compatibility check still rejects a worker whose release identity or protocol version does not match the gateway. The maintainer’s change notice says subsequent 1.106.x patches stop shipping the matching worker, so investigations using that arrangement stop working.
The practical consequence is that a deployment which starts successfully may still lack working investigations. Reusing an older worker is not a demonstrated fix, and changing an image label does not establish compatibility.
Choose based on whether you still need Lens
First identify the installed gateway and worker versions, the chart in use, and any scheduled investigations that people depend on. Then make the workflow decision explicit:
You do not use bundled Lens. This particular removal is not, by itself, a reason to defer the upgrade. Review the other release changes and your normal deployment checks separately.
Investigations must continue. Qualify a replacement before upgrading, or consider a time-bounded deferral while assessing other fixes and support requirements. The maintainer says earlier releases retain their published workers; confirm the exact artifacts your installation needs rather than treating that statement as a guarantee for every registry or deployment.
You are retiring Lens. Agree that the investigation workflow will end, and decide what happens to its stored findings, tracing data and deployment resources before clearing the old setting. Removal from a chart is not proof of either automatic data deletion or safe retention.
Independent Lens needs its own compatibility decision
The current standalone quickstart describes building Lens from source. It can start and display traces without a LiteLLM gateway or a model-provider key; running investigations requires an analysis model to be configured.
On November 4, the public Lens GitHub releases API returned no release entries. That does not rule out source builds or artifacts elsewhere. The release guide also warns that a pipeline capable of producing paired artifacts is not evidence that those artifacts have been published.
Embedding independent Lens in LiteLLM requires a compatible gateway adapter and interface. Those instructions do not establish a qualified independent Lens replacement for v1.106.7. Updating the separate Lens service also does not update the interface built into the gateway.
The independent upgrade guide allows different Lens and gateway versions when their interfaces remain compatible. That describes a different architecture; it does not remove the exact-release check in the older worker endpoint. Treat independent Lens as a migration candidate, not a drop-in worker swap.
Preserve past findings and prove new work can complete
The Lens metadata migration guide makes the storage decision conditional. If investigation metadata is still in PostgreSQL, it describes an import into ClickHouse with old writers stopped until verification finishes. If that metadata is already in ClickHouse, preserve the existing database and its coordination state instead of running the importer over it.
Before changing a persistent deployment, retain its exact software artifacts, configuration and matching data backups. Inspect which resources the installed chart owns and what an upgrade would remove. The current Helm ownership-transfer instructions assume retention and external-mode settings; do not assume an older chart has them.
Use the documented upgrade checks to define a rehearsal’s acceptance criteria:
Open previously stored traces, datasets and findings, and confirm the intended users can still access them.
Send a new trace and complete a bounded investigation before resuming schedules. When connected to LiteLLM, also check an ordinary model request and existing user access scopes.
Confirm the recovery deployment can read the data it would receive. If the new system has already written records, returning to an older image alone is not a complete recovery plan.
The migration guide distinguishes returning to the old PostgreSQL-backed setup before new writes from recovery afterward, when new changes need preservation and reconciliation. For a related example of why code rollback and data recovery are separate decisions, see planning recovery for Cloudflare’s Pi agents.
Budget for operation as well as migration. LiteLLM lists its self-hosted open-source gateway at $0, but that is not an all-in Lens running cost. The investigation documentation says analysis-provider charges apply and lets operators choose a model and monthly spending limit.
For teams that need Lens investigations, the upgrade decision should rest on both preserved evidence and a working replacement—not just a deployment that no longer reports an error.