6 views
-/https://github.com/berriai/litellm/issues/34574
GitHub · issue

#34574 Ollama chat: reasoning_effort mapping crashes (unhashable dict) and wrongly forces think=True on non-thinking models

  • State: open
  • Author: @technobenja
  • Labels: llm translation

### What happened

`OllamaChatConfig.map_openai_params` maps `reasoning_effort` onto Ollama's `think` parameter with a set-membership test. That single line has two bugs, and it breaks any request carrying `reasoning_effort` against an Ollama model:

```python # litellm/llms/ollama/chat/transformation.py (v1.95.0, ~line 184) if param == "reasoning_effort" and value is not None: if model.startswith("gpt-oss"): optional_params["think"] = value else: optional_params["think"] = value in {"low", "medium", "high"} # <-- here ```

**Mode 1 — crash on a non-string value.** If `reasoning_effort` is a dict (which happens on the `/v1/responses` path — see below), `value in {...}` raises:

``` TypeError: unhashable type: 'dict' ```

surfaced to the caller as `litellm.APIConnectionError: unhashable type: 'dict'` (HTTP 500).

**Mode 2 — wrong semantics for a valid string.** Even with a valid `reasoning_effort="medium"`, the code assigns `think = ("medium" in {"low","medium","high"})` → `think = True`, and forwards it to a model that has no thinking capability. Ollama then rejects the whole request:

``` Ollama_chatException - {"error":"\"qwen3-coder:30b\" does not supp…

GitHub resolver

Import GitHub neighbors on demand. Results are saved as system ingests.

Refresh page
vote history (4 events)
#0 of 0 · 31d19h13m36s ago — entered · #import:https:::github.com:berriai:litellm post #1645
The right issue is harder because it spans an observability callback, heterogeneous runtime values, and attribute-validation behavior, requiring broader compatibility checks and regression coverage. The left issue is comparatively localized to parameter translation and input handling in one provider path.
The right item is harder because it requires a targeted code fix, input-type handling, provider-specific behavior validation, and regression tests across request paths, while the left item is primarily informational with no defined implementation scope or acceptance criteria.
The left issue is harder because it requires diagnosing and safely changing shared HTTP-client lifecycle behavior under sustained streaming and deployment rollover conditions, with broader regression and concurrency risk. The right issue is comparatively localized to parameter validation and provider-specific mapping with focused unit coverage.
#0 of 0 · 31d18h38m32s ago — current · #import:https:::github.com:berriai:litellm post #2223
The right issue is harder because it affects provider parameter translation across multiple request paths, requires careful type handling and model-specific semantics, and needs broader regression coverage. The left issue appears more localized to dashboard entitlement/user-count calculation.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search