أضف APIsRouter كنقطة نهاية مخصصة في LibreChat.

إجابة سريعة: كتلة واحدة في librechat.yaml.

تُعَدّ نقاط النهاية المخصصة في LibreChat في librechat.yaml تحت endpoints.custom، وهي مصفوفة كل مدخل فيها مزوّد واحد. الحقول الثلاثة المهمة هي name (التسمية في منتقي نقطة النهاية)، وapiKey (الذي يُدرج متغيرات البيئة بصيغة ${VARIABLE}، لذا يعيش المفتاح في .env ولا يذهب أبداً إلى YAML)، وbaseURL. بالنسبة لـ APIsRouter الـ baseURL هو https://api.apisrouter.com/v1، بتضمين /v1، لأن LibreChat يُلحق مسارات مثل /chat/completions بأياً كان الـ base الذي تعطيه. كتلة models تحدد ما يظهر في القائمة المنسدلة للنموذج. اضبط models.fetch على true ويستعلم LibreChat عن قائمة /v1/models الخاصة بنقطة النهاية عند التحميل، لذا يصبح كل معرّف في الكتالوج قابلاً للاختيار دون الحاجة إلى الحفاظ على قائمة مكتوبة يدوياً. لا يزال models.default مطلوباً كمصفوفة ويعمل كاحتياط يُعرض قبل الجلب أو بدلاً منه. هذا إعداد أصلي (upstream) موثّق، لا رقعة (patch): بنية كائن نقطة النهاية المخصصة في وثائق LibreChat تُعرِّف كل مفتاح مستخدم هنا.

version: 1.2.1
endpoints:
  custom:
    - name: "APIsRouter"
      apiKey: "${APISROUTER_API_KEY}"
      baseURL: "https://api.apisrouter.com/v1"
      models:
        default: ["claude-sonnet-4-6"]
        fetch: true

كيف يوجّه LibreChat نقاط النهاية المخصصة.

LibreChat (danny-avila على GitHub، بنحو 41 ألف نجمة) هو الواجهة الأكثر انتشاراً ذاتية الاستضافة على طراز ChatGPT: متعددة المستخدمين، متعددة النماذج، مع بحث في المحادثات، ووكلاء، ومعالجة ملفات، ومفاتيح لكل مستخدم. على عكس العملاء الذين يُثبِّتون قائمة مزوّدين بشكل جامد، فإن مصفوفة endpoints.custom الخاصة به تقبل أي خدمة متوافقة مع OpenAI، ويُعَدّ عدد من المزوّدين المعروفين في الوثائق عبر هذه الآلية بالضبط. عندما يختار مستخدم نموذجاً من نقطة نهاية مخصصة، يُرسل LibreChat طلب /v1/chat/completions قياسياً إلى baseURL تلك النقطة مع حقل model كسلسلة نصية عادية. لا شيء في العميل يهتم بأي بائع درّب النموذج؛ تُمرَّر السلسلة كما هي. عندما تخدم نقطة النهاية خلف baseURL عدة بائعين، يضع مدخل librechat.yaml واحد معرّفات Claude وGPT وGemini وDeepSeek وGLM في نفس القائمة المنسدلة، ويبدّل المستخدم البائعين في منتصف المحادثة بنفس الطريقة التي يبدّل بها بين نسختين من GPT. هذا يُبسّط إعداد LibreChat المعتاد متعدد المزوّدين. بدلاً من مدخل مخصص واحد لكل بائع، كل منها بمفتاحه الخاص في .env وسطح فوترته الخاص، يغطي مدخل واحد بمفتاح واحد الكتالوج، ويرى المسؤول الاستخدام لكل نموذج في مكان واحد بدلاً من تسوية عدة لوحات.

الإعداد الكامل: YAML، وَ.env، وتوصيل Docker (mount).

أنشئ librechat.yaml في جذر المشروع وضع المفتاح في .env. مرجع ${APISROUTER_API_KEY} في YAML يُحلّ من البيئة عند بدء التشغيل، لذا يبقى ملف الإعداد قابلاً للتثبيت (commit). الخطوة التي تفوت معظم الإعدادات لأول مرة خاصة بـ Docker: لا يرى الحاوية (container) ملف librechat.yaml الخاص بك حتى تُوصِّله (mount). تطلب منك الوثائق إنشاء docker-compose.override.yml بتوصيل ربط (bind mount) من ./librechat.yaml إلى /app/librechat.yaml، ثم إعادة إنشاء الحاويات. تعديل YAML بعد ذلك يتطلب أيضاً إعادة تشغيل، لأن الملف يُقرأ عند بدء التشغيل، لا أنه مُراقَب. بضعة حقول اختيارية تستحق الضبط في مدخل بوابة. titleConvo يفعّل عناوين المحادثة التلقائية، وtitleModel يختار النموذج الذي يكتبها؛ الافتراضي الموثّق لـ titleModel في LibreChat هو gpt-3.5-turbo، معرّف قد لا تخدمه نقطة نهاية غير OpenAI، لذا اضبطه صراحة على معرّف كتالوج سريع أو على القيمة الخاصة current_model. modelDisplayLabel يتحكم في الاسم المعروض على رسائل المساعد. وapiKey يقبل القيمة الخاصة user_provided إذا أردت أن يلصق كل مستخدم مفتاحه الخاص بدلاً من مشاركة مفتاح الخادم.

version: 1.2.1
endpoints:
  custom:
    - name: "APIsRouter"
      apiKey: "${APISROUTER_API_KEY}"
      baseURL: "https://api.apisrouter.com/v1"
      models:
        default: ["claude-sonnet-4-6", "gpt-5.5", "deepseek-v4-pro"]
        fetch: true
      titleConvo: true
      titleModel: "claude-haiku-4-5-20251001"
      modelDisplayLabel: "APIsRouter"

اختيار النماذج لمساحة عمل محادثة مشتركة.

بما أن كل نموذج يُفوتَر عبر نفس المفتاح، فإن الحلقة العملية للمسؤول هي مراقبة أسبوع من الاستخدام في اللوحة، ورؤية أي النماذج يختارها المستخدمون فعلياً، وتقليم models.default لتطابق ذلك، مع إبقاء fetch مفعَّلاً حتى يستطيع المستخدمون المتقدّمون الوصول إلى القائمة الكاملة.

• المحادثة اليومية تريد معمَّماً قوياً. claude-sonnet-4-6 وgpt-5.5 يحملان المحادثات الطويلة، ومناقشة الملفات، وتشغيلات الوكيل دون قلق حول النموذج لكل رسالة.
• الأسئلة القصيرة عالية التكرار هي عمل بحجم كبير. claude-haiku-4-5-20251001 وgemini-3.5-flash يجيبان بسرعة ويمنعان انتشاراً متعدد المستخدمين من تركيز الإنفاق على أدوار تُهمَل.
• توليد العناوين يعمل في كل محادثة. وجّه titleModel إلى معرّف سريع؛ دفع أسعار النماذج الحديثة لكتابة عناوين من ست كلمات هو الهدر الصامت الأكثر شيوعاً في نشر LibreChat.
• الفرق متعددة اللغات يجب أن تختبر deepseek-v4-pro وglm-5.2 على مزيج لغاتها الحقيقي؛ قائمة منسدلة متعددة البائعين تجعل ذلك مقارنة داخل التطبيق بدلاً من إعادة إعداد.
• models.fetch يعني أن نماذج الكتالوج الجديدة تظهر دون المساس بـ YAML، لذا نموذج أُضيف من الأصل (upstream) يصبح قابلاً للاختيار في المرة التالية التي تُحدَّث فيها القائمة.

ادفع حسب الاستخدام · أقل من السعر الرسمي

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

أنماط الفشل الخاصة بـ LibreChat.

عدم تحميل الإعداد بصمت هو الكلاسيكي، وهو دائماً تقريباً توصيل Docker. بدون توصيل الربط في docker-compose.override.yml، تعمل الحاوية بدون أي librechat.yaml إطلاقاً، ولا تظهر نقطة النهاية المخصصة أبداً في المنتقي، ولا يخطئ أي شيء. تأكد من وجود الملف داخل الحاوية قبل تصحيح أي شيء آخر. apiKey يصل حرفياً كـ ${APISROUTER_API_KEY} يعني أن المتغيّر لم يكن موجوداً في البيئة التي بدأ بها الخادم؛ الإدراج يحدث عند بدء التشغيل من .env، لذا مفتاح أُضيف بعد ذلك يحتاج إعادة تشغيل الحاوية. العرض هو 401 من البوابة برمز حامل (bearer token) عديم المعنى. baseURL بدون /v1 ينتج أخطاء 404 في كل طلب، لأن LibreChat يُلحق /chat/completions بالـ base كما هو مُعطى. الخطأ العكسي، لصق URL completions كامل كـ baseURL، ينتمي إلى خيار directEndpoint المنفصل ولا يجب دمجه مع مدخل عادي. قائمة منسدلة نموذج فارغة مع fetch مطفأ تعني أن models.default مفقودة أو فارغة؛ إنها مصفوفة مطلوبة. مع fetch مفعَّلاً، قائمة منسدلة فارغة تعني عادة أن الجلب نفسه فشل، وهو ما يعود إلى المفتاح أو baseURL. وعناوين محادثة فاشلة على نقطة نهاية تعمل لولا ذلك هي افتراض titleModel يشير إلى معرّف لا تخدمه البوابة؛ اضبطه صراحة.

من يوجّه LibreChat عبر بوابة.

• الفرق التي تستضيف ذاتياً مساحة عمل محادثة مشتركة وتريد Claude وGPT وGemini وDeepSeek في قائمة منسدلة واحدة دون الحفاظ على مدخل endpoints.custom وحساب بائع لكل واحد.
• المسؤولون الذين يشغّلون نشرات متعددة المستخدمين ويحتاجون سطح استخدام واحد. سجلات كل مفتاح تُظهر أي النماذج يستخدمها الفريق فعلياً، مُسعَّرة، دون دمج لوحات البائعين.
• المشغّلون الذين يمنحون الأقسام مفاتيح خاصة بها: نفس YAML، مفتاح واحد لكل مجموعة، ويصبح سجل الاستخدام تقرير التكلفة لكل فريق.
• العائلات والمجموعات الصغيرة التي تستبدل عدة اشتراكات محادثة بنقطة نهاية مقنَّنة واحدة، تدفع مقابل tokens المستخدمة بدلاً من المقاعد.
• المطورون الذين لا يملكون وصولاً إلى فوترة بائع معيّن. الوصول القائم على تعبئة الرصيد بدون شرط بطاقة يزيل الاعتماد على التسجيل لكل مزوّد.

تحقق من نقطة النهاية وصحّح أخطاء الرسالة الأولى.

أثبت صحة نصف البوابة قبل لمس LibreChat: اسرد النماذج بمفتاحك، وتأكد من ظهور المعرّفات التي وضعتها في models.default. إذا نجح ذلك، فكل عرض متبقٍّ في جانب LibreChat من الاتصال. ثم شغّل المكدَّس وافتح منتقي نقطة النهاية. ظهور مدخل APIsRouter إطلاقاً يثبت أن YAML حُمِّل؛ امتلاء قائمة النماذج يثبت الجلب والمفتاح؛ أول رد يثبت مسار المحادثة. اعمل خلال هذه الثلاثة بالترتيب بدلاً من مرة واحدة، لأن لكل منها مجموعة إخفاقات مميّزة، التوصيل ومتغيّر البيئة وbaseURL على التوالي. بمجرد تدفّق الرسائل، تعرض لوحة APIsRouter النموذج لكل طلب، وعدد tokens، والإنفاق. نسخة LibreChat المشتركة هي بالضبط نوع النشر الذي يتركّز فيه الاستخدام بصمت على نموذجين أو ثلاثة، وسجل الاستخدام هو كيف تكتشف أيها قبل أن تفعل الفاتورة.

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

الأسئلة الشائعة