ربط Claude Code بالنماذج المستضافة ذاتياً باستخدام free-claude-code: اختبار ميداني لبروكسي التوجيه بين 17 مزوداً

نظرة عامة

Claude Code عميل برمجي قوي. غير أن بنيته القائمة على توجيه كل طلب مباشرةً إلى Anthropic API تُقيّد المؤسسات الراغبة في ضبط التكاليف أو إبقاء البيانات داخل حدودها. يعالج مشروع free-claude-code الذي شهد انتشاراً واسعاً مؤخراً هذه النقطة بالذات؛ إذ يُمثّل طبقة بروكسي تعترض حركة مرور Claude Code وتعيد توجيهها إلى 17 مزوداً مختلفاً. وهو مشروع مرخص بـ MIT يحمل 36.7k نجمة على GitHub و5.7k تفرع و712 إيداعاً.

شعار المشروع التسويقي هو “Claude Code مجاناً إلى الأبد.” يعمل النهج عبر تحويل حركة المرور نحو مزودين ذوي فئة مجانية أو منخفضة التكلفة، وهذا الإطار مبالغ فيه إلى حد ما وينطوي على منطقة رمادية من حيث شروط الخدمة. لذا يركز هذا المقال لا على زاوية “المجاني”، بل على ما يعنيه هذا الأداة للمؤسسات كـ ThakiCloud التي تخدم نماذجها الخاصة على Kubernetes وتريد ربط Claude Code ببنيتها التحتية الخاصة. النقاط الجوهرية هي أن الكود والمطالبات لا تغادر حدود المستأجر، وتختفي فواتير السحابة المحسوبة لكل رمز، ولا حاجة لتعديل جانب العميل لأن نقطة النهاية متوافقة مع Anthropic.

ملاحظة: ركّز المقال السابق “توجيه Claude Code إلى النماذج الداخلية - claude-code-router” على المراجحة في التكاليف بين نماذج السحابة (glm وMiniMax وKimi). يتناول هذا المقال أداةً مختلفة (free-claude-code)، ويعالج الاتصال بـ الخلفيات المستضافة ذاتياً (Ollama وvLLM) لا بالسحابة، إلى جانب مخاطر النشر التي كشفها هذا المسار.

ما الذي يفعله هذا الأداة

free-claude-code خادم بروكسي محلي يستقبل الطلبات التي يرسلها Claude Code (وCodex). ميزته الجوهرية أنه يحاكي نقطة نهاية متوافقة مع Anthropic بشكل كامل. من منظور العميل، لا يمكن تمييزه عن Anthropic API الحقيقية، مما يتيح تبديل الخلفية دون تغيير سطر واحد في Claude Code.

الخادم مكتوب بـ FastAPI ويكشف نقاط النهاية التالية:

/v1/messages - متوافق مع Anthropic Messages API (المسار الرئيسي لـ Claude Code)
/v1/models - قائمة النماذج
/v1/responses - متوافق مع OpenAI Responses API (لـ Codex؛ يُحوَّل داخلياً إلى Messages)

عند وصول طلب، يقرر موجّه النماذج أي مزود يرسل إليه الطلب، ثم يحوّل المُوحِّد كتل التفكير وأدوات الاستدعاء واستجابات الخطأ إلى الشكل الذي يتوقعه كل عميل. نظراً لاختلاف صيغ الاستجابة بين المزودين، تكمن في طبقة التوحيد هذه الصعوبة الحقيقية.

لنتوسع قليلاً في سبب صعوبة التوحيد: يفترض Claude Code بنية استجابة خاصة بـ Anthropic؛ فخطوات الاستدلال تأتي ككتل thinking، واستدعاءات الأدوات ككتل محتوى tool_use. لكن DeepSeek يُصدر الاستدلال كحقل منفصل، في حين تُعيد المزودين المتوافقين مع OpenAI استدعاءات الأدوات كمصفوفة tool_calls. المعنى واحد وهو “استُدعيت أداة”، لكن صيغة السلك تختلف في كل حالة. يجب على المُوحِّد استيعاب هذه الفوارق وضمان حصول Claude Code على استجابات بشكل متطابق بغض النظر عن الخلفية المستخدمة. يذهب مسار Codex (/v1/responses) خطوة أبعد بتحويل طلبات OpenAI Responses داخلياً إلى Anthropic Messages قبل مشاركة الموجّه والمُوحِّد ومحوّلات المزودين ذاتها. أي أن تحويل البروتوكول يجري في الاتجاهين — وهذا هو الفارق الجوهري بين البروكسي العكسي البسيط وبروكسي التوجيه.

بنية توجيه free-claude-code الشكل 1. يستقبل بروكسي FastAPI حركة المرور المتوافقة مع Anthropic من Claude Code ويوزعها على 17 مزوداً. من منظور ThakiCloud، المسارات الجوهرية هي الخلفيات المستضافة ذاتياً على اليمين (Ollama وLM Studio وvLLM).

المزودون المدعومون 17 مزوداً. على الجانب السحابي: NVIDIA NIM وOpenRouter وGoogle AI Studio (Gemini) وDeepSeek وMistral La Plateforme وMistral Codestral وOpenCode Zen وOpenCode Go وWafer وKimi وCerebras وGroq وFireworks وZ.ai. على جانب الاستضافة الذاتية: LM Studio وllama.cpp وOllama. الثلاثة الأخيرة هي ذات الأهمية من منظور ThakiCloud. إذ يكشف Ollama وllama.cpp نقاط نهاية متوافقة مع OpenAI، مما يعني أن خادم vLLM المنشور بالطريقة ذاتها على Kubernetes يمكن ربطه بنفس الأسلوب.

يتحكم في توجيه الفئات عبر متغيرات البيئة. يحدد كل من MODEL_OPUS وMODEL_SONNET وMODEL_HAIKU أي نموذج يُوجَّه إليه كل فئة من فئات Claude الثلاث؛ وعند غياب التحديد يُستخدم النموذج الاحتياطي MODEL. يتيح هذا نشراً متدرجاً، كتوجيه حركة مرور Haiku الخفيفة إلى نماذج صغيرة والحركة الثقيلة من Opus إلى نماذج أكبر.

التثبيت والتكامل

مسار التثبيت الرسمي هو سطر أوامر واحد:

# macOS / Linux
curl -fsSL "https://github.com/Alishahryar1/free-claude-code/blob/main/scripts/install.sh?raw=1" | sh

# Windows PowerShell
irm "https://github.com/Alishahryar1/free-claude-code/blob/main/scripts/install.ps1?raw=1" | iex

بدلاً من سطر الأوامر، تحققت من الحزمة بتثبيتها مباشرةً في بيئة اختبار معزولة، حفاظاً على سلامة البيئة الافتراضية المشتركة وفق قواعد وقت تشغيل Python في ThakiCloud.

# شجرة عمل معزولة + venv مؤقت (البيئة المشتركة .venv على 3.12.8 وستتعارض)
uv venv --python 3.14 .expenv
VIRTUAL_ENV=.expenv uv pip install "git+https://github.com/Alishahryar1/free-claude-code.git"

تُثبَّت الحزمة ذاتها بنظافة. تُحلّ التبعيات مثل fastapi وuvicorn وhttpx وpydantic وopenai وloguru بنجاح، وتُنشأ سكريبتات وحدة التحكم مثل fcc-server وfcc-init وfcc-claude. بعد تشغيل الخادم، يُوجَّه Claude Code نحو البروكسي على النحو الآتي:

fcc-server            # تشغيل بروكسي FastAPI (الافتراضي http://127.0.0.1:8082)
# مثال على خلفية مستضافة ذاتياً (Ollama):
#   MODEL_HAIKU=ollama/llama3.2:3b
#   MODEL_SONNET=ollama/qwen2.5:7b
# حدد عنوان URL الأساسي لتوجيه Claude Code نحو البروكسي ثم استخدمه كالمعتاد

واجهة الإدارة متاحة على http://127.0.0.1:8082/admin وتكون محدودة بحلقة الاسترداد فقط. تُدار هنا مفاتيح المزودين وتوجيه النماذج وإعدادات الرسائل والصوت.

نتائج التجربة الفعلية

خلال عملية التحقق، واجهت نقطة أعاقت إعادة الإنتاج، وأسجلها كما هي. عدم اختلاق الأرقام مبدأ راسخ في هذا التقرير.

حاجز التشغيل: الاشتراط الصارم بـ Python 3.14

يُثبّت free-claude-code الإصدار v2.3.14 اشتراط requires-python = ">=3.14.0" بشكل صارم. Python 3.14 هو الإصدار الأحدث الذي صدر رسمياً في أكتوبر 2025 فحسب. المشكلة أن الإصدار 3.14 الوحيد المتاح في بيئة الاختبار كان بناء ألفا (3.14.0a7). تشغيل fcc-server على هذا الإصدار الألفا يفشل بالخطأ التالي:

ImportError: cannot import name 'get_annotate_from_class_namespace'
from 'annotationlib'

يحدث هذا التعارض لأن pydantic المثبّت يتوقع واجهة annotationlib الخاصة بالإصدار النهائي 3.14، لكن الرمز المطلوب غير موجود بعد في الإصدار الألفا المبكر. حاولت عندئذٍ التشغيل قسراً على الإصدار المستقر الأدنى (3.13)، لكن التثبيت ذاته يُرفض بسبب الاشتراط الصارم في بيانات الحزمة:

free-claude-code==2.3.14 cannot be used ... your requirements are unsatisfiable.

الخلاصة واضحة: في البيئات التي تفتقر إلى Python 3.14 المستقر، لن يعمل هذا البروكسي أبداً. فشل محاولة إعادة الإنتاج: الحزمة تشترط Python 3.14 الصادر حديثاً، لكن الإصدار 3.14 الوحيد المتاح ألفا يتعارض مع pydantic المثبّت. هذه ليست عيباً في الأداة بقدر ما هي مشكلة تثبيت إصدار متعجّل يتعارض مع واقع بيئات الإنتاج التي تبقى في الغالب على 3.11–3.12.

القياس المباشر لمسار التوجيه المستضاف ذاتياً

رغم أن البروكسي نفسه لم يُشغَّل، فإن الآلية التي تستخدمها هذه الأداة لاستدعاء مزود ollama هي نقطة النهاية المتوافقة مع OpenAI. لذا قست هذا المسار باستدعاء Ollama المحلي مباشرةً. هذه أرقام أداء التوجيه للخلفية ذاتها دون تضمين الحمل الإضافي للبروكسي الذي ستضيفه fcc. نتائج تعيين فئات Claude الثلاث لنماذج محلية كالآتي (Apple Silicon، مطالبة متطابقة، حد 64 رمزاً):

نتائج قياس التوجيه المستضاف ذاتياً الشكل 2. التأخر ومعدل المعالجة عند توجيه فئات Claude إلى نماذج Ollama المحلية. qwen3:8b المُدرج في مسار opus نموذج تفكير يُصدر رموز استدلال مطوّلة مما يزيد الوقت بشكل ملحوظ.

التوجيه	النموذج	التأخر	رموز الإكمال	معدل المعالجة
haiku	llama3.2:3b	0.49s	33	67.3 tok/s
sonnet	qwen2.5:7b	0.56s	20	35.7 tok/s
opus	qwen3:8b	8.12s	281	34.6 tok/s

النموذج الصغير (llama3.2:3b) ينهي استجابته في أقل من 0.5 ثانية، وهو سرعة كافية لحركة مرور بديلة عن Haiku. كذلك qwen2.5:7b عند 0.56 ثانية عملي للاستخدام. في المقابل، استغرق qwen3:8b المُدرج في مسار opus 8.12 ثانية، لأن نموذج التفكير يُصدر أولاً 281 رمز استدلال. معدل المعالجة (34.6 tok/s) طبيعي في حد ذاته، لكن القياس أكد أن توظيف نموذج استدلالي في فئة ثقيلة يُفجّر عدد الرموز ويزيد التأخر المُدرَك بشكل كبير. درس عملي: عند تصميم تعيينات الفئات، ينبغي مراعاة ميل النموذج لتوليد رموز الاستدلال.

التطبيق والدلالات لمنصة ThakiCloud SaaS للذكاء الاصطناعي/تعلم الآلة على Kubernetes

القيمة الحقيقية لهذه الأداة ليست في “المجانية” بل في نمط الاتصال. بمجرد إدراج بروكسي متوافق مع Anthropic كطبقة وسيطة، يمكن إرفاق عملاء تجاريين كـ Claude Code مباشرةً ببنيتنا التحتية.

تُجدول ThakiCloud وحدات GPU باستخدام Kueue وتُقدّم النماذج عبر vLLM على Kubernetes. نظراً لأن vLLM يوفر نقطة نهاية متوافقة مع OpenAI (/v1/chat/completions)، يمكن ربطها بمسار المزود المستضاف ذاتياً في free-claude-code بنفس الطريقة المتبعة مع Ollama أو llama.cpp. أسلوب الاتصال مشترك بين المزودين المستضافين ذاتياً: يُحدَّد عنوان URL الأساسي بنقطة نهاية خدمة vLLM في الكتلة، ويُضاف بادئة المزود إلى معرّف النموذج. تماماً كما تُكتب Ollama بالصيغة ollama/llama3.2:3b، يُضاف النموذج المُقدَّم على vLLM الداخلي لأهداف التوجيه باتباع قاعدة البادئة ذاتها. يُتيح ذلك:

سيادة البيانات: لا يغادر الكود والمطالبات حدود المستأجر. هذا أمر جوهري في البيئات التنظيمية مثل النشر داخل المنشأة ومتطلبات الامتثال للأجهزة الحكومية.
تحوّل هيكل التكلفة: تتحوّل فوترة القياس لكل رمز إلى تكاليف GPU ثابتة. كلما ارتفع الاستخدام، تسارعت نقطة التعادل للتقديم الذاتي.
النشر المتدرج حسب الفئة: يمكن توجيه حركة مرور Haiku الخفيفة إلى نماذج صغيرة والأعمال الثقيلة إلى نماذج أكبر، مما يُحسّن الاستفادة من وحدات GPU. تُقدّم القياسات أعلاه الأرقام المرجعية لهذا النشر المتدرج.

غير أن الأنسب بدلاً من اعتماد هذه الأداة كما هي هو استعارة نمط التوجيه المُتحقَّق منه فحسب. في بيئة متعددة المستأجرين، يجب أن يمتلك البروكسي مصادقة وعزلاً ومراقبةً لكل مستأجر، في حين تفترض واجهة إدارة free-claude-code مستخدماً واحداً في حلقة الاسترداد وهي قاصرة كما هي. الفكرة الكامنة في طبقة التوحيد المتوافقة مع Anthropic تستحق الاستعارة، لكن المصادقة والحصص والتسجيل يجب إعادة تطبيقها وفق معايير بوابتنا.

القيود والاعتراضات

أولاً، المنطقة الرمادية لشروط الخدمة. يعتمد إطار “Claude Code مجاناً” على التوجيه عبر مزودين ذوي فئة مجانية، مما قد يتعارض مع شروط خدمة كل منصة. في البيئات المؤسسية، الاستخدام المشروع والمستدام هو حصراً التوجيه إلى الخلفيات المملوكة (النماذج المُقدَّمة ذاتياً). هذا هو سبب تأكيد هذا المقال على مسار الاستضافة الذاتية فحسب.

ثانياً، تثبيت الإصدار المتعجّل. يمنع الاشتراط الصارم بـ Python 3.14 التشغيلَ فوراً في البيئات التي تفتقر إلى وقت تشغيل مستقر كما رأينا. مع الأخذ بعين الاعتبار تكلفة ومخاطر ترقية صور حاويات الإنتاج إلى 3.14، فإن إدراج هذه الأداة مباشرةً في خط أنابيب النشر في الوقت الراهن ينطوي على عبء مفرط.

ثالثاً، لا يُضمن تكافؤ الجودة. استبدال Opus أو Sonnet من Claude بنماذج مختلفة لا يُبقي جودة البرمجة على حالها. التوجيه خيار يكسب فيه تكاليف أقل وسيادة بيانات مقابل التنازل عن جودة الاستجابة؛ وأي حركة مرور تُوجَّه إلى أي مكان يجب تحديده بالقياس وفق درجة صعوبة المهمة.

رابعاً، قياسات هذا التقرير هي أرقام استدعاء مباشر للخلفية دون المرور بالبروكسي. لا يشمل ذلك الحمل الإضافي للتوحيد والتوجيه في fcc. متى توافرت بيئة Python 3.14 المستقرة، أخطط لإعادة قياس التأخر ذهاباً وإياباً عبر البروكسي وإضافته تكملةً لهذه النتائج.

خلاصة القول، free-claude-code محفوف بالمخاطر إذا استُهلك بوصفه “اختراقاً مجانياً”، لكنه نقطة انطلاق ممتازة كمرجع مفتوح المصدر لأنماط التوجيه المتوافقة مع Anthropic عند تصميم ربط العملاء التجاريين ببنية الاستدلال المستضافة ذاتياً.

المصادر

GitHub: Alishahryar1/free-claude-code (MIT, 36.7k stars, v2.3.14)
بيانات القياس: استدعاءات مباشرة لنقطة النهاية المتوافقة مع OpenAI في Ollama المحلي (llama3.2:3b وqwen2.5:7b وqwen3:8b، Apple Silicon)
مقال ذو صلة: مدونة ThakiCloud التقنية “توجيه Claude Code إلى النماذج الداخلية - claude-code-router”