Litellm fallback ollama error

[ruslanmv]

Make the reasoning wrapper something CrewAI will accept
Every query from the web app failed before a token was generated:

2 validation errors for Agent
llm.str      Input should be a valid string
llm.BaseLLM  Input should be a valid dictionary or instance of BaseLLM

Agent.llm is a validated pydantic field typed str | BaseLLM. The
normalizer wrapped reasoning models in a plain class, which is neither.

The wrapper's own docstring explains the original choice — CrewAI's LLM
class changes between versions, so composition looked safer than
subclassing — and it was, right up until that field started validating.
After which deepseek-r1, QwQ and every other reasoning model failed at
agent construction on every agent path.

BaseLLM turns out to be an ABC with exactly one abstract method, call,
which is the method this wrapper existed to intercept. So the subclass is
small and satisfies the validator by being what it claims to be. It is
built lazily, on first use: defining it at import would drag CrewAI and
LiteLLM into every process that imports the module, which is the startup
cost llm_provider goes out of its way to avoid.

Three details worth keeping. The inner model's name is carried across,
because CrewAI reads it for logging, token accounting and context-window
sizing. Capability questions are answered by the real client rather than
BaseLLM's defaults, which describe nothing in particular. And a reply that
is only reasoning returns the raw text rather than the empty string it
strips down to — CrewAI reads "" as a failed call.

Verified end to end against the reported setup, Ollama 0.12.9 with
deepseek-r1: agent builds, a real crew run returns, no leakage.
Non-reasoning models are still returned unwrapped and untouched, so the
common path gains neither overhead nor a new way to fail.

The module had no tests, which is how a wrapper incompatible with the
framework it wraps got released. It has 17 now, and three of them fail
against the previous behaviour.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
gitpilot	Ready	Preview	Aug 10, 2026 8:54am

[gitguardian]

⚠️ GitGuardian has uncovered 1 secret following the scan of your pull request.

Please consider investigating the findings and remediating the incidents. Failure to do so may lead to compromising the associated services or software components.

🔎 Detected hardcoded secret in your pull request

GitGuardian id	GitGuardian status	Secret	Commit	Filename
35874985	Triggered	Generic High Entropy Secret	22de2ab	extensions/vscode/test/settingsPanel.test.js	View secret

🛠 Guidelines to remediate hardcoded secrets

1. Understand the implications of revoking this secret by investigating where it is used in your code.
2. Replace and store your secret safely. Learn here the best practices.
3. Revoke and rotate this secret.
4. If possible, rewrite git history. Rewriting git history is not a trivial act. You might completely break other contributing developers' workflow and you risk accidentally deleting legitimate data.

To avoid such incidents in the future consider

• following these best practices for managing and storing secrets including API keys and other credentials
• install secret detection on pre-commit to catch secret before it leaves your machine and ease remediation.

---

^{🦉 GitGuardian detects secrets in your source code to help developers and security teams secure the modern development process. You are seeing this because you or someone else with access to this repository has authorized GitGuardian to scan your pull request.}