Open Interpreter را روی یک endpoint سفارشی سازگار با OpenAI اجرا کنید.

Updated 2026-07-30

Open Interpreter مقدار api_base را مستقیم افشا می‌کند. آن را به https://api.apisrouter.com/v1 اشاره دهید، id مدل را با openai/ پیشوند بزنید تا LiteLLM chat completions صحبت کند، و مدلی که کد را روی ماشین شما می‌نویسد و اجرا می‌کند می‌تواند هر id ای در کاتالوگ زیر یک کلید باشد.

پاسخ سریع: api_base به‌علاوه پیشوند مدل openai/.

Open Interpreter یک مسیر endpoint-سفارشی را در هر دو رابط مستند می‌کند. در CLI، --api_base را با endpoint و --model را با یک پیشوند openai/ روی id پاس دهید. در پایتون، interpreter.llm.api_base، interpreter.llm.api_key، و interpreter.llm.model را قبل از فراخوانی chat() تنظیم کنید. پیشوند تزئین نیست. Open Interpreter روی LiteLLM اجرا می‌شود، و LiteLLM از رشته مدل تعیین می‌کند کدام کلاینت provider استفاده شود. openai/claude-sonnet-4-6 یعنی «پروتکل chat-completions OpenAI را با هر چیزی که api_base می‌گوید صحبت کن، با claude-sonnet-4-6 به‌عنوان فیلد model.» پیشوند را حذف کنید و LiteLLM به‌جای آن provider را از نام خام استنتاج می‌کند، یک id مربوط به claude-* را به‌سمت کلاینت Anthropic مسیردهی می‌کند و endpoint ای که پیکربندی کرده‌اید را نادیده می‌گیرد.

export OPENAI_API_KEY=sk-APIsRouter-...

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

Open Interpreter با مدل خود چه می‌کند.

Open Interpreter (openinterpreter در GitHub، حدود ۶۶ هزار ستاره) به یک مدل زبانی یک code interpreter روی ماشین شما می‌دهد: یک هدف را به زبان طبیعی بیان می‌کنید، مدل پایتون یا shell می‌نویسد، Open Interpreter آن را محلی اجرا می‌کند، و خروجی به مکالمه برای گام بعدی بازمی‌گردد. آن حلقه آن را کیفی‌طور متفاوت از یک کلاینت چت می‌کند. مدل نثر تولید نمی‌کند؛ کدی تولید می‌کند که با مجوزهای کاربر شما اجرا می‌شود، و در برابر خطاهای واقعی از سیستم واقعی شما تکرار می‌کند. دو پیامد برای مسیردهی دنبال می‌شود. اول، کیفیت مدل مستقیماً یک ویژگی امنیت و صحت است: مدلی که flag ها را hallucinate می‌کند یا یک traceback را غلط می‌خواند یک رفت-برگشت شکست‌خورده دیگر تولید می‌کند، و در حالت auto-run یکی تولید می‌کند که شما بازبینی نکرده‌اید. دوم، حلقه به شکلی خاص token-گرسنه است: هر نوبت مکالمه، کد، و خروجی گرفته‌شده در حال رشد را دوباره می‌فرستد، پس session های دیباگ بلند سریع context را انباشته می‌کنند. تنظیم api_base کل این حلقه را به یک endpoint جابه‌جا می‌کند. چون فیلد model بعد از پیشوند openai/ به‌عنوان رشته ساده فوروارد می‌شود، یک id از Claude، یک id از GPT، و یک id از DeepSeek انتخاب‌های یک-flag قابل‌تعویض هستند به‌جای راه‌اندازی‌های جدای provider.

راه‌اندازی کامل: API پایتون و یک پروفایل.

مسیر پایتون همان سه مقدار را روی interpreter.llm تنظیم می‌کند و دو تنظیمی که LiteLLM نمی‌تواند برای یک id سفارشی کشف کند اضافه می‌کند: context_window و max_tokens. Open Interpreter از context_window استفاده می‌کند تا تصمیم بگیرد چقدر تاریخچه مکالمه را قبل از تراشیدن نگه دارد، پس رها‌کردن آن تنظیم‌نشده یا پیش‌فرض روی یک مدل ۲۰۰k خیلی زودتر از لازم می‌تراشد؛ آنچه مدل واقعاً پشتیبانی می‌کند را اعلام کنید. برای یک راه‌اندازی پایدار، همان کلیدها در یک YAML پروفایل زیر یک بلوک llm: زندگی می‌کنند (دایرکتوری پروفایل‌ها را با interpreter --profiles باز کنید). یک پروفایل endpoint، مدل، و تنظیمات پنجره را از تاریخچه شل شما بیرون نگه می‌دارد و پیکربندی را در سرتاسر ماشین‌ها قابل‌اشتراک می‌کند، با کلید که همچنان از محیط تأمین می‌شود.

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

انتخاب مدلی که کد شما را می‌نویسد.

مقایسه مدل اینجا غیرمعمول ملموس است: به دو مدل همان وظیفه را بدهید و رفت-برگشت‌ها تا نتیجه کاری را بشمارید. نمای usage هر-کلید هزینه token به ازای هر session را اضافه می‌کند، که همراه با شمارش رفت-برگشت کل مقایسه است. پشت یک endpoint هر کاندید یک flag است.

  • حلقه اصلی مدلی می‌خواهد که کد قابل‌اجرا بنویسد و tracebacks را خوب در pass اول بخواند؛ claude-sonnet-4-6 و gpt-5.5 میانه قابل‌اتکا هستند، و هر رفت-برگشت شکست‌خورده‌ای که یک مدل بهتر اجتناب می‌کند token و زمان واقعی صرفه‌جویی‌شده است.
  • deepseek-v4-pro کاندیدای قوی برای session های کد-سنگین است جایی که حجم اهمیت دارد؛ از طریق یک endpoint، امتحان‌کردن آن در برابر وظایف خود شما یک تغییر تک --model است.
  • session های ابزاری سریع (تغییرنام فایل، تبدیل‌های یک‌باره، تبدیل‌های فرمت) به استدلال frontier نیازی ندارند؛ claude-haiku-4-5-20251001 یا glm-5.2 آن‌ها را سریع و ارزان نگه می‌دارند.
  • حالت auto-run (-y) گام بازبینی انسانی بین تولید کد و اجرا را حذف می‌کند. اگر اصلاً از آن استفاده می‌کنید، آن را با قوی‌ترین مدلی که اجرا می‌کنید، در یک sandbox یا کانتینر، هرگز با مدلی که هنوز در حال ارزیابی آن هستید استفاده کنید.

پرداخت بر اساس مصرف · پایین‌تر از قیمت رسمی

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

مدلقیمت رسمیقیمت ما
Claude Sonnet 4.6$3.00 / $15.00 per M$2.40 / $12.00 per M
GPT-5.5$5.00 / $30.00 per M$4.00 / $24.00 per M
DeepSeek V4 Pro$0.43 / $0.87 per M$0.40 / $0.90 per M
Claude Haiku 4.5 20251001$1.00 / $5.00 per M$0.80 / $4.00 per M
GLM-5.2$1.14 / $4.00 per M$1.10 / $4.00 per M

حالت‌های شکست مختص Open Interpreter.

یک id مدل خام دور endpoint شما مسیردهی می‌شود. بدون پیشوند openai/، LiteLLM provider را از نام resolve می‌کند: id های claude-* به‌سمت کلاینت Anthropic می‌روند، و نتیجه یک خطای auth یا مسیردهی در برابر یک host است که هرگز پیکربندی نکرده‌اید. اگر خطاها یک SDK vendor را به‌جای gateway شما ذکر می‌کنند، پیشوند گم شده. فرض‌های context پیش‌فرض session های شما را می‌تراشند. برای یک id ای که LiteLLM آن را نمی‌شناسد، هیچ‌چیز context window را پر نمی‌کند؛ Open Interpreter به رفتار محافظه‌کارانه برمی‌گردد و تاریخچه را زود می‌تراشد. context_window را صریح اعلام کنید، چون یک session دیباگ کد که تلاش‌های قبلی خود را از دست می‌دهد همان اشتباهات را دوباره می‌سازد. session های در حال رشد، صورت‌حساب‌های در حال رشد. هر نوبت مکالمه به‌علاوه کد به‌علاوه خروجی گرفته‌شده را دوباره می‌فرستد. یک session که یک dataframe بزرگ یا یک log بلند را در حلقه می‌چسباند آن را در هر درخواست بعدی حمل می‌کند. ترجیح دهید مدل کدی بنویسد که فایل‌ها را بازرسی کند به‌جای چسباندن محتوای فایل در چت، و وقتی یک وظیفه تغییر می‌کند session های تازه شروع کنید. عدم‌تطابق function-calling. Open Interpreter می‌تواند از فراخوانی‌های function ساختاریافته جایی که پشتیبانی می‌شود استفاده کند؛ flag برابر supports_functions برای id هایی وجود دارد که تشخیص اشتباه حدس می‌زند. اگر بلوک‌های کد بدشکل روی مدلی که می‌دانید توانمند است می‌رسند، آن را صریح روی True تنظیم کنید؛ اگر یک مدل واقعاً پشتیبانی tool ندارد، False تنظیم کنید تا مسیر fallback فعال شود. سمت اجرا مال شماست. api_base ترافیک مدل را جابه‌جا می‌کند؛ کد همچنان محلی با مجوزهای شما اجرا می‌شود. یک gateway هیچ‌چیز را sandbox نمی‌کند، پس auto-run را محدود به کانتینرها نگه دارید و بگذارید بازبینی ایمنی در همه‌جای دیگر در حلقه بماند.

چه کسانی Open Interpreter را از طریق یک gateway مسیردهی می‌کنند.

  • توسعه‌دهندگانی که از Open Interpreter به‌عنوان یک ابزار اتوماسیون روزانه استفاده می‌کنند و تولید کد با کیفیت Claude، تنوع GPT، و id های ابزاری سریع پشت یک کلید می‌خواهند.
  • اهل‌داده‌هایی که حلقه‌های تحلیل اکتشافی اجرا می‌کنند، جایی که یک session می‌تواند context شگفت‌آوری را بسوزاند و usage هر-کلید هزینه به ازای هر معادل-notebook را قابل‌مشاهده می‌کند.
  • مهندسانی که مدل‌های کد-نویسی را روی رفت-برگشت‌ها-تا-کاری مقایسه می‌کنند، صادقانه‌ترین benchmark موجود، یک flag برابر --model به ازای هر کاندید.
  • اهل‌فن‌هایی که کارهای interpreter زمان‌بندی‌شده یا کانتینری اجرا می‌کنند، جایی که یک endpoint env-var و یک secret از یک مجموعه credential هر-vendor بهتر است.
  • توسعه‌دهندگان بدون دسترسی به صورت‌حساب یک vendor خاص. دسترسی مبتنی بر شارژ بدون الزام کارت وابستگی ثبت‌نام هر-provider را حذف می‌کند.

endpoint را تأیید کنید و اولین session را عیب‌یابی کنید.

اول مدل‌های gateway را فهرست کنید؛ id بعد از openai/ باید دقیقاً با یک id سرویس‌داده‌شده مطابقت داشته باشد، شامل پسوند نسخه. شکست‌های اولین session از یک الگو پیروی می‌کنند. خطاهایی که anthropic یا یک SDK vendor دیگر را نام می‌برند یعنی پیشوند openai/ گم شده و LiteLLM با نام مسیردهی کرده. یک ۴۰۱ یعنی کلید در شلی که interpreter را راه‌اندازی کرده قابل‌مشاهده نیست، یا برای یک متغیر متفاوت از آنچه در استفاده است تنظیم شده؛ با پیشوند سرجایش، هم OPENAI_API_KEY و هم یک api_key صریح کار می‌کنند. یک خطای model-not-found از gateway یک غلط‌تایپی id است. یک خطای اتصال معمولاً یعنی api_base پسوند /v1 خود را گم کرده؛ client مسیر /chat/completions را به هر base ای که بدهید اضافه می‌کند. وقتی حلقه اجرا شود، کنسول APIsRouter مدل، شمارش token، و هزینه هر-درخواست را نشان می‌دهد. session های interpreter نمونه کلاسیک یک workload اند که کوچک احساس می‌شود اما متوسط صورت‌حساب می‌دهد، و نمای usage روشی است که می‌بینید کدام session ها واقعاً token ها را حمل کردند.

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

پرسش‌های پرتکرار

آیا Open Interpreter می‌تواند مدل‌های Claude یا DeepSeek را از طریق یک endpoint اجرا کند؟

بله. با api_base اشاره‌کرده به gateway و پیشوند openai/ روی id مدل، LiteLLM chat completions استاندارد را به آن endpoint صحبت می‌کند و id را به‌عنوان رشته ساده فوروارد می‌کند. id های Claude، GPT، DeepSeek، و GLM همه با همان دو تنظیم کار می‌کنند.

چرا id مدل به پیشوند openai/ نیاز دارد؟

Open Interpreter روی LiteLLM اجرا می‌شود، که کلاینت provider خود را از رشته مدل انتخاب می‌کند. پیشوند openai/ کلاینت پروتکل-OpenAI هدف‌گذاری‌شده به api_base شما را اجبار می‌کند. یک id خام از claude-* به‌جای آن به کلاینت Anthropic resolve می‌شود و endpoint شما را نادیده می‌گیرد.

کدام متغیر محیطی کلید را نگه می‌دارد؟

با پیشوند openai/ در بازی، OPENAI_API_KEY انتخاب متعارف است، یا interpreter.llm.api_key را صریح در پایتون تنظیم کنید، یا --api_key را در CLI پاس دهید. کلید را بیرون از پروفایل‌ها و اسکریپت‌ها نگه دارید؛ محیط خانه درست آن است.

آیا باید context_window را دستی تنظیم کنم؟

برای id های سفارشی، بله. LiteLLM نمی‌تواند پنجره را برای مدلی که نمی‌شناسد استنتاج کند، و Open Interpreter تاریخچه مکالمه را در برابر این عدد می‌تراشد. پنجره واقعی مدل (۲۰۰۰۰۰ برای id های Claude در جدول) را اعلام کنید وگرنه session های بلند context قبلی خود را از دست می‌دهند.

آیا مسیردهی از طریق یک gateway auto-run (-y) را ایمن می‌کند؟

خیر. gateway ترافیک مدل را حمل می‌کند؛ کد تولیدشده همچنان محلی با مجوزهای شما اجرا می‌شود. auto-run گام بازبینی را حذف می‌کند، پس آن را صرف‌نظر از اینکه کدام endpoint مدل را سرویس می‌دهد به کانتینرها یا sandbox ها محدود کنید.

یک session interpreter چند token مصرف می‌کند؟

با نوبت‌ها و با آنچه وارد حلقه می‌شود مقیاس می‌گیرد: هر رفت-برگشت مکالمه، کد، و خروجی گرفته‌شده را دوباره می‌فرستد. وظایف ابزاری کوتاه متوسط‌اند؛ session های دیباگ بلند با داده چسبانده‌شده سریع انباشته می‌شوند. نمای usage هر-کلید در کنسول APIsRouter عدد واقعی هر-session را نشان می‌دهد.