Patakbuhin ang Open Interpreter sa isang custom OpenAI-compatible endpoint.

Mabilisang sagot: api_base kasama ang openai/ model prefix.

Nagdo-document ang Open Interpreter ng custom-endpoint path sa parehong interface. Sa CLI, ipasa ang --api_base kasama ang endpoint at --model na may openai/ prefix sa id. Sa Python, itakda ang interpreter.llm.api_base, interpreter.llm.api_key, at interpreter.llm.model bago tawagin ang chat(). Hindi palamuti lang ang prefix. Tumatakbo ang Open Interpreter sa LiteLLM, at nire-resolve ng LiteLLM kung aling provider client ang gagamitin batay sa model string. Ang ibig sabihin ng openai/claude-sonnet-4-6 ay "magsalita ng OpenAI chat-completions protocol sa kahit anong sinasabi ng api_base, gamit ang claude-sonnet-4-6 bilang model field." Kung tinanggal ang prefix, ini-infer ng LiteLLM ang provider mula sa bare na pangalan, na iniruruta ang isang claude-* id patungo sa client ng Anthropic at binabalewala ang endpoint na na-configure mo.

export OPENAI_API_KEY=sk-APIsRouter-...

interpreter \
  --api_base https://api.apisrouter.com/v1 \
  --model openai/claude-sonnet-4-6

Ano ang ginagawa ng Open Interpreter sa model nito.

Binibigyan ng Open Interpreter (openinterpreter sa GitHub, humigit-kumulang 66K stars) ang isang language model ng code interpreter sa makina mo: sinasabi mo ang isang goal gamit ang natural language, sinusulat ng model ang Python o shell, isinasagawa ito ng Open Interpreter nang lokal, at bumabalik ang output sa usapan para sa susunod na hakbang. Ang loop na iyon ang gumagawa sa kanya na iba talaga kumpara sa isang chat client. Hindi prosa ang ginagawa ng model; gumagawa ito ng code na tumatakbo gamit ang permissions ng user mo, at umuulit ito laban sa mga totoong error mula sa totoo mong sistema. May dalawang epekto ito sa routing. Una, direktang isang safety at correctness property ang kalidad ng model: ang isang model na nag-hahallucinate ng flags o mali ang pagbasa sa isang traceback ay gumagawa ng isa pang bigong round trip, at sa auto-run mode ay gumagawa ito ng isa na hindi mo na-review. Pangalawa, token-hungry ang loop sa isang tiyak na paraan: ipinapadala ulit ng bawat turn ang lumalaking usapan, code, at nakuhang output, kaya mabilis na nagdaragdag ng context ang mahahabang debugging session. Inililipat ng api_base setting ang buong loop na ito sa isang endpoint. Dahil dumadaan ang model field bilang isang plain string pagkatapos ng openai/ prefix, ang isang Claude id, isang GPT id, at isang DeepSeek id ay pinagpapalit-palit na one-flag na pagpipilian sa halip na hiwalay na setup per provider.

Buong setup: Python API at isang profile.

Itinatakda ng Python path ang parehong tatlong value sa interpreter.llm at idinaragdag ang dalawang setting na hindi matutuklasan ng LiteLLM para sa isang custom id: ang context_window at max_tokens. Ginagamit ng Open Interpreter ang context_window para magpasya kung gaano karaming conversation history ang itatago bago mag-trim, kaya ang pag-iwan nito na walang laman o naka-default sa isang 200k na model ay nagti-trim nang mas maaga kaysa kinakailangan; ideklara kung ano talaga ang suportado ng model. Para sa isang persistent na setup, nasa isang profile YAML sa ilalim ng isang llm: block ang parehong mga key (buksan ang profiles directory gamit ang interpreter --profiles). Pinapanatili ng isang profile ang endpoint, model, at window settings sa labas ng shell history mo at ginagawang mai-share ang configuration sa iba't ibang makina, habang ang key ay galing pa rin sa environment.

import os
from interpreter import interpreter

interpreter.llm.api_base = "https://api.apisrouter.com/v1"
interpreter.llm.api_key = os.environ["APISROUTER_API_KEY"]
interpreter.llm.model = "openai/claude-sonnet-4-6"

# LiteLLM cannot infer these for a custom id; declare them:
interpreter.llm.context_window = 200000
interpreter.llm.max_tokens = 8192
interpreter.llm.supports_functions = True

interpreter.chat("Profile data.csv and plot the top 10 rows by revenue.")

Pagpili ng model na susulat ng code mo.

Hindi karaniwang konkreto ang paghahambing ng model dito: bigyan ang dalawang model ng parehong task at bilangin ang round trips papunta sa isang gumaganang resulta. Idinaragdag ng per-key usage view ang token cost per session, na kasama ang bilang ng round-trip ang buong comparison. Sa likod ng isang endpoint, isang flag lang ang bawat kandidato.

• Kailangan ng main loop ng isang model na sumusulat ng runnable code at mahusay magbasa ng tracebacks sa unang pagkakataon; ang claude-sonnet-4-6 at gpt-5.5 ang maaasahang gitna, at bawat bigong round trip na naiiwasan ng mas magaling na model ay tokens at oras na naipon.
• Malakas na kandidato ang deepseek-v4-pro para sa mga code-heavy session kung saan mahalaga ang volume; sa pamamagitan ng isang endpoint, ang pagsubok dito laban sa mga sarili mong task ay isa lamang --model change.
• Hindi kailangan ng frontier reasoning ang mabilisang utility session (file renames, one-off transforms, format conversions); pinapanatiling mabilis at mura ang mga ito ng claude-haiku-4-5-20251001 o glm-5.2.
• Tinatanggal ng auto-run mode (-y) ang human review step sa pagitan ng code generation at execution. Kung gagamitin mo man ito, gamitin ito kasama ang pinakamalakas na model na pinapatakbo mo, sa loob ng sandbox o container, huwag kailanman sa isang model na sinusubok mo pa lang.

Pay-as-you-go · mas mababa sa opisyal na presyo

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

Ang mga failure mode na specific sa Open Interpreter.

Ang isang bare na model id ay lumalampas sa endpoint mo. Kung walang openai/ prefix, nire-resolve ng LiteLLM ang provider mula sa pangalan: pumupunta ang mga claude-* id sa client ng Anthropic, at ang resulta ay isang auth o routing error laban sa host na hindi mo kailanman na-configure. Kung binabanggit ng errors ang isang vendor SDK sa halip na gateway mo, kulang ang prefix. Nagti-trim ang mga default na context assumption sa mga session mo. Para sa isang id na hindi kilala ng LiteLLM, walang pupuno sa context window; bumabalik ang Open Interpreter sa conservative na behavior at maagang nagti-trim ng history. Ideklara nang tahasan ang context_window, dahil ang isang code-debugging session na nawawalan ng mga naunang pagsubok ay uulitin ang parehong mga pagkakamali. Lumalaking session, lumalaking bill. Ipinapadala ulit ng bawat turn ang usapan kasama ang code at ang nakuhang output. Ang isang session na nagpasok ng malaking dataframe o mahabang log sa loop ay dinadala ito sa bawat susunod na request. Mas mainam na magpasulat ng code sa model na nag-i-inspect ng files kaysa i-paste ang laman ng file sa chat, at magsimula ng bagong session kapag nagbago ang task. Function-calling mismatch. Maaaring gumamit ang Open Interpreter ng structured function calls kung suportado; umiiral ang supports_functions flag para sa mga id kung saan mali ang hula ng detection. Kung dumarating na malformed ang code blocks sa isang model na alam mong may kakayahan, itakda ito sa True nang tahasan; kung tunay na walang tool support ang isang model, itakda sa False para gumana ang fallback path. Sa iyo ang panig ng execution. Inililipat ng api_base ang trapiko ng model; ang code ay tumatakbo pa rin nang lokal gamit ang mga permissions mo. Walang sina-sandbox ang isang gateway, kaya panatilihin ang auto-run sa loob lamang ng mga container at hayaan ang safety review na manatili sa loop sa lahat ng ibang pagkakataon.

Sino ang nagru-route ng Open Interpreter sa pamamagitan ng isang gateway.

• Mga developer na gumagamit ng Open Interpreter bilang pang-araw-araw na automation tool na gustong makakuha ng Claude-quality code generation, GPT variety, at mabibilis na utility id sa likod ng isang key.
• Mga taong data na nagpapatakbo ng exploratory analysis loop, kung saan puwedeng gumastos ang isang session ng kaka-gulat na context at ipinapakita ng per-key usage ang gastos per notebook-equivalent.
• Mga engineer na naghahambing ng mga code-writing model batay sa round-trips-to-working, ang pinaka-tapat na benchmark na available, isang --model flag per kandidato.
• Mga tinkerer na nagpapatakbo ng scheduled o containerized na interpreter jobs, kung saan mas maigi ang isang env-var na endpoint at isang secret kaysa sa isang per-vendor na credential set.
• Mga developer na walang access sa billing ng isang partikular na vendor. Inaalis ng top-up based na access na walang kailangang card ang sign-up dependency per provider.

I-verify ang endpoint at i-debug ang unang session.

Ilista muna ang mga model ng gateway; dapat eksaktong tumugma ang id pagkatapos ng openai/ sa isang si-serve na id, kasama ang version suffix. Sumusunod sa isang pattern ang mga kabiguan sa unang session. Ang mga error na binabanggit ang anthropic o ibang vendor SDK ay nangangahulugang kulang ang openai/ prefix at niruta ng LiteLLM batay sa pangalan. Ang ibig sabihin ng 401 ay hindi nakikita ang key sa shell na naglunsad ng interpreter, o itinakda ito para sa ibang variable kaysa sa ginagamit; kapag nasa lugar na ang prefix, gumagana pareho ang OPENAI_API_KEY o isang tahasang api_key. Ang isang model-not-found na error mula sa gateway ay isang typo sa id. Karaniwang nangangahulugan ang isang connection error na nawala ang /v1 suffix ng api_base; ini-append ng client ang /chat/completions sa anumang base na ibinigay mo. Kapag tumatakbo na ang loop, ipinapakita ng APIsRouter console ang per-request na model, token counts, at gastos. Ang mga interpreter session ang klasikong halimbawa ng isang workload na pakiramdam maliit pero ang bill ay katamtaman, at ang usage view ang paraan para makita kung aling mga session talaga ang nagdala ng mga token.

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $APISROUTER_API_KEY" | head -50

Mga madalas itanong