Skip to content

fix(open-interpreter): don't double-prefix provider-scoped EVAL_MODEL - #339

Closed
cdoron wants to merge 1 commit into
Exgentic:mainfrom
cdoron:fix/open-interpreter-model-prefix
Closed

fix(open-interpreter): don't double-prefix provider-scoped EVAL_MODEL#339
cdoron wants to merge 1 commit into
Exgentic:mainfrom
cdoron:fix/open-interpreter-model-prefix

Conversation

@cdoron

@cdoron cdoron commented Aug 10, 2026

Copy link
Copy Markdown
Collaborator

Summary

  • interpreter.llm.model unconditionally prepended openai/, so a provider-scoped EVAL_MODEL (e.g. gcp/gemini-3.5-flash-lite) became malformed (openai/gcp/gemini-3.5-flash-lite) and failed to route through the gateway.
  • Adds the same "/" in model guard already used by terminus-2 and openhands.

Checked against: .agents/gateways/RULES.md rule 23 (EVAL_MODEL is a bare, opaque handle that MAY already carry a provider/routing prefix; the gateway/agent MUST NOT assume it needs a prefix added).

Test plan

  • Confirmed via a real AppWorld/open-interpreter run: output/model/result.json now reports the correct, unprefixed gcp/gemini-3.5-flash-lite, and traces.jsonl's raw_gen_ai_request span shows llm.openai.model set correctly (previously double-prefixed).
  • Matches the existing guard pattern in containers/agents/terminus-2/run.py and containers/agents/openhands/run_openhands.py.

🤖 Generated with Claude Code

interpreter.llm.model unconditionally prepended "openai/", so an
EVAL_MODEL that already carries a routing prefix (e.g.
gcp/gemini-3.5-flash-lite) became malformed (openai/gcp/...). Guard
matches the pattern already used by terminus-2 and openhands.

Checked against: .agents/gateways/RULES.md rule 23 (EVAL_MODEL is a
bare, opaque handle that MAY already carry a provider prefix).

Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Signed-off-by: Doron Chen <cdoron@il.ibm.com>
@elronbandel

Copy link
Copy Markdown
Contributor

Superseded by #354 — same guard fix, plus a deeper issue found while reviewing it: run_oi.py reads $EVAL_MODEL directly, which never reaches the container (run-agent's scrub only forwards $MODEL — the same bug #320/#334 fixed in ten other agents). Your authorship is preserved on the guard-fix commit.

elronbandel added a commit that referenced this pull request Aug 12, 2026
…not $EVAL_MODEL

Two issues found while reviewing/verifying #339:

1. run-agent's env -i allow-list forwards only MODEL to the agent process —
   EVAL_MODEL is scrubbed away (same contract zerostack already follows,
   same bug #320/#334 fixed in ten other agents). run_oi.py read EVAL_MODEL
   directly with no Dockerfile-level shim, so it always fell back to the
   literal string "default" regardless of #339's guard fix.

2. #339's "/" guard (copied from openhands/terminus-2's old pattern) does
   not actually work for provider-scoped handles. Verified live: a handle
   like gcp/gemini-3.5-flash-lite skips the openai/ prefix (as intended)
   but then reaches litellm.completion() unmodified, and litellm tries to
   resolve "gcp" as a real provider name (it isn't — litellm's name for
   it is vertex_ai) and raises BadRequestError: LLM Provider NOT provided.
   Reproduced the exact crash #339 was supposed to prevent.

open-interpreter's Llm class has no field for litellm's custom_llm_provider
(unlike terminus-2/harbor's LiteLLM wrapper, see #348 — same underlying
issue, same fix approach). Fixed by wrapping llm.completions (a plain
function forwarding **params to litellm.completion(**params)) to inject
custom_llm_provider="openai" regardless of what the handle carries.

Verified live against a capturing mock: bare handle and provider-prefixed
handle (gcp/...) both now reach the wire unmodified, no crash, in both
cases before this fix would either mangle the model name (#339's original
bug) or crash outright (the case #339's own fix introduced).

Signed-off-by: Elron Bandel <elron.bandel@ibm.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants