fix(litellm): pass api_base and set enable_thinking for bool THINKING

[planetf1]

LiteLLMBackend silently ignored custom endpoints and THINKING had no effect. This PR fixes both.

Any backend constructed with a base_url (e.g. pointing at a vLLM server) was broken: _base_url was stored but never forwarded to litellm.acompletion(), so all requests routed to LiteLLM's default provider inference instead. Separately, THINKING=True/False never set chat_template_kwargs.enable_thinking, so vLLM models requiring an explicit opt-in (e.g. Gemma 4) never got thinking. THINKING=False also incorrectly sent reasoning_effort=False, which is an invalid value.

Issue	Before	After
Custom base_url	Stored, never used — requests misrouted	Forwarded as api_base to both call sites
THINKING=True	reasoning_effort="medium" only — Gemma 4 ignored it	reasoning_effort="medium" + enable_thinking=True
THINKING=False	reasoning_effort=False — invalid value	enable_thinking=False only; no reasoning_effort
User extra_body + THINKING	TypeError on merge	Deep-merged correctly

Scope: LiteLLMBackend only (mellea/backends/litellm.py). Sibling PR #1204 covers OpenAIBackend. Both are part of #1201.

Closes #1206. Relates to #1201, #1204.

Test plan

• uv run pytest test/backends/test_litellm_thinking.py -v — all 17 tests pass
• uv run pytest -m "not qualitative" — full fast suite passes
• Live via scratchpad/smoke_litellm_vllm.py and scratchpad/smoke_litellm_ollama.py:
  • Qwen3.6-27B (vLLM): reasoning_effort='medium' → thinking engaged ✅
  • Gemma-4-31B-it (vLLM): reasoning_effort='medium' alone → no thinking ❌; with enable_thinking=True → thinking ✅
  • LiteLLM → Ollama (qwen3.6:35b): THINKING=True → mot._thinking populated ✅; THINKING=False → clean ✅

Technical detail — why two mechanisms

vLLM models control thinking via chat_template_kwargs.enable_thinking (a Jinja template variable). LiteLLM-compatible providers (Ollama, cloud) use reasoning_effort. Sending both means each server picks up whichever it understands. THINKING=True sets reasoning_effort="medium" (for LiteLLM's translation layer, e.g. Ollama → think=True) and enable_thinking=True (for vLLM). THINKING=False sends only enable_thinking=False — omitting reasoning_effort rather than sending an invalid False.

String values ("low", "medium", "high") still route to reasoning_effort only; they are OpenAI-compatible values and don't set enable_thinking. For vLLM users wanting string-level control, True/False is the correct API.

[psschwei]

LGTM
a couple of non-blocking items below

[psschwei]

nit:

Suggested change

	if type(thinking) is bool:
	if isinstance(thinking, bool):

though ok if we leave as is too

[psschwei]

I guess this is technically a breaking change, but if I understand the flow right the typically ollama call will handle this anyway so there's minimal user impact right?

[planetf1]

The old code accepted a base_url parameter but never forwarded it to LiteLLM. Looking at the pre-PR acompletion() call:

litellm.acompletion(
    model=self._model_id,
    messages=conversation,
    tools=formatted_tools,
    reasoning_effort=thinking,
    drop_params=True,
    **extra_params,
    **model_specific_options,
)

No api_base= anywhere. The value was stored in self._base_url but never used. LiteLLM always inferred the endpoint from the model prefix — ollama_chat/ → localhost:11434, anthropic/ → Anthropic's API, and so on.

That means the three cases worth considering are all safe:

• Default construction LiteLLMBackend() — old: _base_url set to localhost:11434 but ignored; new: _explicit_base_url=False, api_base not forwarded. LiteLLM infers the same endpoint either way.
• Explicit non-default Ollama LiteLLMBackend(base_url="http://myserver:11434") — old: stored but silently ignored, so this was already broken; new: forwarded correctly for the first time. Fixed, not broken.
• Cloud provider LiteLLMBackend(model_id="anthropic/...") — old: LiteLLM inferred Anthropic's endpoint; new: _explicit_base_url=False, same outcome.

The default changes from "http://localhost:11434" to None because keeping a non-None default would cause the new forwarding logic to send api_base=localhost:11434 to cloud providers constructed without arguments — which would be wrong. None preserves the pre-PR behaviour: let LiteLLM infer.