Open Interpreter को एक custom OpenAI-compatible endpoint पर चलाएं।

Quick answer: api_base plus openai/ model prefix।

Open Interpreter दोनों interfaces में एक custom-endpoint path document करता है। CLI पर, --api_base endpoint के साथ pass करें और --model id पर openai/ prefix के साथ। Python में, chat() call करने से पहले interpreter.llm.api_base, interpreter.llm.api_key, और interpreter.llm.model set करें। Prefix decoration नहीं है। Open Interpreter LiteLLM पर चलता है, और LiteLLM model string से तय करता है कौन सा provider client इस्तेमाल करना है। openai/claude-sonnet-4-6 का मतलब है "api_base जो भी कहे उसे OpenAI chat-completions protocol बोलो, claude-sonnet-4-6 को model field के तौर पर।" Prefix हटा दें और LiteLLM bare name से provider infer करता है, एक claude-* id को Anthropic के client की तरफ route करते हुए और आपके configured endpoint को ignore करते हुए।

export OPENAI_API_KEY=sk-APIsRouter-...

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

Open Interpreter अपने model से क्या करता है।

Open Interpreter (GitHub पर openinterpreter, लगभग 66K stars) एक language model को आपकी machine पर एक code interpreter देता है: आप natural language में एक goal बताते हैं, model Python या shell लिखता है, Open Interpreter इसे locally execute करता है, और output अगले step के लिए conversation में feed वापस होता है। वह loop इसे एक chat client से qualitatively अलग बनाता है। Model prose produce नहीं कर रहा; यह ऐसा code produce कर रहा है जो आपके user की permissions से चलता है, और यह आपके असली system से असली errors के against iterate करता है। Routing के लिए दो consequences हैं। पहला, model quality सीधे एक safety और correctness property है: एक model जो flags hallucinate करे या एक traceback को misread करे एक और failing round trip produce करता है, और auto-run mode में यह एक ऐसा produce करता है जिसे आपने review नहीं किया। दूसरा, loop एक specific तरीके से token-hungry है: हर turn growing conversation, code, और captured output दोबारा भेजता है, तो लंबे debugging sessions context को तेज़ी से compound करते हैं। api_base setting इस पूरे loop को एक endpoint पर move कर देती है। चूंकि model field openai/ prefix के बाद एक plain string के तौर पर pass through होता है, एक Claude id, एक GPT id, और एक DeepSeek id अलग provider setups की बजाय interchangeable one-flag choices हैं।

पूरा setup: Python API और एक profile।

Python path interpreter.llm पर same तीन values set करता है और वे दो settings add करता है जो LiteLLM एक custom id के लिए discover नहीं कर सकता: context_window और max_tokens। Open Interpreter context_window इस्तेमाल करता है यह तय करने के लिए कि trim करने से पहले कितनी conversation history रखनी है, तो इसे unset या defaulted छोड़ना एक 200k model पर ज़रूरत से कहीं पहले trim करता है; model असल में क्या support करता है वह declare करें। एक persistent setup के लिए, same keys एक profile YAML में llm: block के तहत रहती हैं (profiles directory खोलने के लिए interpreter --profiles)। एक profile endpoint, model, और window settings को आपके shell history से बाहर रखता है और configuration को machines के across shareable बनाता है, key अब भी environment से supplied।

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.")

वह model चुनना जो आपका code लिखता है।

यहां model comparison असामान्य रूप से concrete है: दो models को same task दें और working result तक round trips गिनें। Per-key usage view per session token cost add करता है, जो round-trip count के साथ पूरा comparison है। एक endpoint के पीछे हर candidate एक flag है।

• Main loop को एक ऐसा model चाहिए जो runnable code लिखे और पहली पास पर tracebacks अच्छे से पढ़े; claude-sonnet-4-6 और gpt-5.5 भरोसेमंद middle हैं, और हर failed round trip जो एक बेहतर model टालता है वह बचे हुए tokens और wall-clock हैं।
• deepseek-v4-pro code-heavy sessions के लिए एक strong candidate है जहां volume matter करता है; एक endpoint के through, अपने खुद के tasks पर इसे try करना एक single --model change है।
• Quick utility sessions (file renames, one-off transforms, format conversions) को frontier reasoning नहीं चाहिए; claude-haiku-4-5-20251001 या glm-5.2 इन्हें fast और inexpensive रखते हैं।
• Auto-run mode (-y) code generation और execution के बीच human review step हटा देता है। अगर आप इसे बिल्कुल भी इस्तेमाल करें, तो सबसे strong model के साथ करें जो आप चलाते हैं, एक sandbox या container में, कभी उस model के साथ नहीं जिसे आप अब भी evaluate कर रहे हैं।

जितना उपयोग उतना भुगतान · आधिकारिक मूल्य से कम

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

Open Interpreter के लिए specific failure modes।

एक bare model id आपके endpoint के आस-पास route होती है। openai/ prefix के बिना, LiteLLM नाम से provider resolve करता है: claude-* ids Anthropic के client की तरफ जाती हैं, और परिणाम एक ऐसे host के against एक auth या routing error है जो आपने कभी configure ही नहीं किया। अगर errors आपके gateway की बजाय एक vendor SDK का नाम लें, तो prefix missing है। Default context assumptions आपके sessions trim करती हैं। एक id के लिए जिसे LiteLLM नहीं पहचानता, कुछ भी context window नहीं भरता; Open Interpreter conservative behavior पर fall back करता है और history जल्दी trim करता है। context_window explicitly declare करें, क्योंकि एक code-debugging session जो अपने पहले attempts खो देती है वही गलतियां दोबारा करती है। Growing sessions, growing bills। हर turn conversation plus code plus captured output दोबारा भेजता है। एक session जो loop में एक बड़ा dataframe या एक लंबा log paste करती है वह इसे बाद की हर request में carry करती है। Model को चाहिए कि वह files inspect करने वाला code लिखे, इसकी बजाय कि file contents chat में paste किए जाएं, और task बदलने पर fresh sessions शुरू करें। Function-calling mismatch। Open Interpreter structured function calls इस्तेमाल कर सकता है जहां supported हों; supports_functions flag उन ids के लिए exist करता है जहां detection गलत guess करती है। अगर code blocks एक ऐसे model पर malformed आते हैं जिसे आप capable जानते हैं, इसे explicitly True set करें; अगर एक model genuinely tool support नहीं रखता, False set करें ताकि fallback path engage हो। Execution side आपका है। api_base model traffic move करती है; code अब भी locally आपकी permissions से चलता है। एक gateway कुछ भी sandbox नहीं करता, तो auto-run को containers तक सीमित रखें और बाकी हर जगह safety review को loop में रहने दें।

कौन Open Interpreter को एक gateway के through route करता है।

• Developers जो Open Interpreter को daily automation tool की तरह इस्तेमाल करते हैं और एक key के पीछे Claude-quality code generation, GPT variety, और fast utility ids चाहते हैं।
• Data folks जो exploratory analysis loops चलाते हैं, जहां एक session surprising context burn कर सकती है और per-key usage per notebook-equivalent cost visible बनाता है।
• Engineers जो code-writing models को round-trips-to-working पर compare करते हैं, सबसे honest benchmark जो उपलब्ध है, per candidate एक --model flag।
• Tinkerers जो scheduled या containerized interpreter jobs चलाते हैं, जहां एक env-var endpoint और एक secret per-vendor credential set से बेहतर है।
• Developers जिनके पास किसी given vendor की billing तक access नहीं है। बिना card requirement वाला top-up based access per-provider sign-up dependency हटा देता है।

Endpoint verify करें और पहली session को debug करें।

पहले gateway के models list करें; openai/ के बाद वाली id exactly एक served id से match होनी चाहिए, version suffix शामिल। पहली-session failures एक pattern follow करती हैं। anthropic या किसी और vendor SDK का नाम लेने वाले errors मतलब openai/ prefix missing है और LiteLLM नाम से route कर गया। एक 401 मतलब key उस shell में visible नहीं है जिसने interpreter launch किया, या इस्तेमाल हो रहे variable से अलग किसी variable के लिए set की गई थी; prefix के साथ, OPENAI_API_KEY या एक explicit api_key दोनों काम करते हैं। Gateway से एक model-not-found error एक id typo है। एक connection error का मतलब आमतौर पर api_base से इसका /v1 suffix छूट गया; client आपके दिए base में /chat/completions append करता है। एक बार loop चलने लगे, APIsRouter console per-request model, token counts, और spend दिखाता है। Interpreter sessions उस classic case का उदाहरण हैं जो छोटा महसूस होता है पर medium bill करता है, और usage view वह तरीका है जिससे आप देखते हैं कौन सी sessions असल में tokens carry कर रही थीं।

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

अक्सर पूछे जाने वाले प्रश्न