How to Upgrade LiteLLM, Streamlit and Ollama Without Surprising Production Users

What Happened

LiteLLM v1.106.0-dev.3 adds provider and model support, including Bedrock Mantle prompt-cache breakpoints, TwelveLabs Pegasus 1.5 inference profiles, MongoDB-key routing for VoyageAI, and Vertex AI inline-tools beta forwarding. Its proxy changes include workload identity federation configuration, MCP OAuth metadata and request translation, guardrail stream scopes, and rate-limit gauges. It also fixes fallback routing, batch retries and spend alerts. This is a development release, not a reason to upgrade production automatically. [1]

Streamlit 1.65.1.dev20261008 is a nightly build. The available release information identifies its version but does not specify features, fixes or breaking changes. [2]

Ollama v0.40.2 upgrades models downloaded with earlier versions in the background on first run to improve llama.cpp performance and compatibility. It temporarily retains the originals for downgrades. It also fixes duplicate entries in ollama list and makes ollama launch claude use the model’s full context length. [3]

Why It Matters to Businesses

LiteLLM changes can affect provider routing, authentication, guardrails, limits and cost reporting—the controls around an AI request, not just the model response. Ollama’s first-run conversion introduces a migration step and temporary storage overhead. Streamlit’s nightly version provides too little change detail to justify a business-critical upgrade on its own. [1][2][3]

Kimbodo Engineering Perspective

We would treat these as three different upgrade decisions. Evaluate LiteLLM’s new integrations against actual provider needs and regression-test the proxy paths in use. Test Ollama with representative local models before a broad rollout, allowing for conversion time and retained backups. Keep Streamlit’s nightly build in an isolated test environment until its changes can be reviewed and validated. [1][2][3]

How We Would Implement It

• Pin versions and build a staging matrix covering LiteLLM routing, fallbacks, streaming guardrails, OAuth translation, rate limits and spend reporting where those features are used. Compare outputs and telemetry against the current deployment. [1]
• Verify the LiteLLM container signature with cosign using the public key URL pinned to commit 0112e53046018d726492c814b3644b7d376029d0, as the release recommends, before admitting the image to deployment. [1]
• Run Ollama v0.40.2 on a copy of the model store first. Measure conversion duration and disk use, check model listing and inference, then roll out in stages. Keep the original models until the downgrade window closes. [3]
• Promote the Streamlit nightly only if a defined test or needed fix warrants it; require application-level UI and deployment checks because the available release information contains no change list. [2]

Risks, Costs and Security

Deleting Ollama’s retained originals saves space but changes rollback: downgrading to a version older than 0.40 would require re-pulling those models. [3] Signature verification establishes provenance for the LiteLLM image; it does not replace configuration review or tests of authentication and guardrail behavior. [1] For both development builds, the main cost is validation effort against changes that may not be appropriate for production yet. [1][2]

Sources

1. [1] v1.106.0-dev.3
2. [2] 1.65.1.dev20261008
3. [3] v0.40.2