أعلنت GitHub يوم 20 يوليو 2026 تحديثًا جديدًا يجعل استهلاك AI Credits في GitHub Copilot ظاهرًا بوضوح على مستوى دورة الفوترة، حتى للمستخدمين الذين لا يملكون ميزانية فردية محددة من مؤسساتهم. هذه الخطوة تبدو بسيطة من الخارج، لكنها تمس واحدة من أكثر النقاط حساسية لدى الفرق التقنية اليوم: كيف نتابع استهلاك أدوات الذكاء الاصطناعي البرمجية قبل أن تتحول التكلفة إلى مفاجأة في نهاية الشهر؟

بحسب إعلان GitHub الرسمي، أصبحت صفحة الاستخدام داخل إعدادات GitHub Copilot تعرض عدد الاعتمادات المستهلكة فعليًا خلال دورة الفوترة الحالية. وإذا لم يحدد المسؤول ميزانية فردية للمستخدم، فسيشاهد إجمالي ما استهلكه من AI Credits مباشرة. أما إذا كانت هناك ميزانية، فستظهر الأرقام بصيغة أوضح تقارن بين الاعتمادات المستهلكة والحد المسموح به.

ما الجديد في استهلاك AI Credits في GitHub Copilot؟

قبل هذا التحديث، كان كثير من مستخدمي Copilot Business وCopilot Enterprise يرون نسبة مئوية مرتبطة بميزانية فقط. المشكلة أن هذه النسبة لم تكن مفيدة عندما لا توجد ميزانية فردية أصلًا، لأن المستخدم في هذه الحالة لا يحصل على رقم يوضح كم استهلك فعلًا من اعتمادات الذكاء الاصطناعي داخل الدورة الحالية.

الآن تغيّر ذلك. GitHub قررت أن تعرض الاستخدام الحقيقي بدل الاعتماد على واجهة مبهمة. وهذا يعني أن المستخدم لم يعد بحاجة إلى انتظار تقرير إداري أو سؤال فريق المالية التقنية لمعرفة ما إذا كان استهلاكه مرتفعًا أم طبيعيًا، بل باتت المعلومة أقرب إليه داخل صفحة الاستخدام نفسها.

لماذا يهم هذا التحديث للفرق والشركات؟

تكمن أهمية التحديث في أن استهلاك AI Credits في GitHub Copilot أصبح جزءًا من تجربة الاستخدام اليومية، لا مجرد بند محاسبي خلفي. ومع توسع اعتماد الوكلاء البرمجيين، وجلسات Copilot الطويلة، والنماذج الأعلى تكلفة، لم يعد كافيًا أن تعرف المؤسسة عدد الرخص التي اشترتها فقط. الأهم هو فهم من يستهلك، وكيف يستهلك، ومتى يبدأ الاستهلاك في الاقتراب من حدود غير مريحة.

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

كيف تعمل AI Credits أصلًا داخل GitHub Copilot؟

وفق توثيق GitHub الرسمي، تُقاس استخدامات Copilot في الخطط المؤسسية عبر AI Credits، حيث يستهلك كل تفاعل قدرًا من الاعتمادات بحسب النموذج وعدد الرموز المستخدمة. وتشير الوثائق إلى أن كل مقعد في Copilot Business يضيف 1900 AI Credits شهريًا إلى الرصيد المشترك، بينما يضيف مقعد Copilot Enterprise 3900 AI Credits شهريًا، مع وجود فترة ترويجية أعلى لبعض العملاء الحاليين خلال صيف 2026.

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

ما الفرق بين الرؤية الفردية والميزانيات الإدارية؟

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

كما أن هذا التطوير ينسجم مع موجة أوسع داخل GitHub لتحسين مراقبة الاستهلاك. وإذا كنت تتابع هذا الملف، فراجع أيضًا مقالنا السابق عن استهلاك GitHub Copilot الشهري، لأنه يوضح كيف بدأت المنصة أصلًا في تقريب بيانات الاستهلاك من المستخدمين، بينما يأتي تحديث يوليو 2026 ليجعل الصورة أكثر مباشرة ومرتبطة بدورة الفوترة نفسها.

أين يمكن متابعة الاستهلاك بالتفصيل؟

توضح صفحة Monitoring your GitHub AI Credits usage أن GitHub توفر أكثر من مستوى للمراقبة، من نظرة عامة داخل صفحة الفوترة إلى تحليلات أعمق بحسب النماذج والمزايا المستخدمة. لكن الميزة الجديدة تضيف طبقة مهمة لأنها تنقل جزءًا من هذه الرؤية إلى واجهة المستخدم المباشرة بدل إبقائها في لوحات الإدارة فقط.

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

هل يؤثر التحديث على جميع مستخدمي Copilot؟

بحسب إعلان GitHub، التحديث موجه إلى مستخدمي Copilot Business وCopilot Enterprise. أي أنه يركز على بيئات العمل الجماعية التي ترتبط فيها الفوترة بالمنظمات والمؤسسات، لا على جميع الحسابات الفردية بالضرورة. وهذا منطقي، لأن المشكلة التي يعالجها التحديث تظهر بشكل أوضح عندما يكون الاستهلاك جزءًا من ميزانية مشتركة داخل مؤسسة.

ومع ذلك، فإن الرسالة الأوسع هنا تتجاوز هذا النطاق: GitHub تدرك أن المستخدمين لم يعودوا يقبلون أدوات ذكاء اصطناعي تُحسب تكلفتها في الخلفية دون تفسير واضح. ومع زيادة تعقيد نماذج التسعير، سيصبح عرض البيانات القابلة للفهم بنفس أهمية جودة النموذج نفسه.

كيف تستفيد الفرق من هذا التحديث عمليًا؟

الاستفادة الحقيقية لا تأتي من مشاهدة الرقم فقط، بل من ربطه بسلوك العمل اليومي. يمكن لمديري الهندسة مثلًا استخدام هذه الرؤية لتحديد الفرق التي تحتاج إلى تدريب على الاستخدام الأكثر كفاءة، أو لتحديث سياسات اختيار النماذج، أو لمراجعة جدوى الوكلاء البرمجيين في بعض المسارات. ويمكن للمستخدمين أنفسهم مقارنة استهلاكهم بعائدهم الفعلي: هل أنجزت هذه الجلسات عملاً ملموسًا؟ أم أنني أستهلك اعتمادات كثيرة على مهام كان يمكن حلها بصورة أبسط؟

بكلمات أخرى، التحديث لا يقدم مجرد لوحة أجمل، بل يمنح المؤسسة أساسًا أفضل للموازنة بين الإنتاجية والتكلفة. ومع استمرار GitHub في توسيع تقارير AI usage والميزانيات، يبدو أن المنافسة لم تعد فقط على من يقدم اقتراحات أكواد أفضل، بل على من يمنح الشركات رؤية أوضح وأكثر قابلية للقياس حول العائد من الذكاء الاصطناعي.

خلاصة المقال

تحديث 20 يوليو 2026 يجعل استهلاك AI Credits في GitHub Copilot أوضح بكثير داخل دورة الفوترة، ويعالج مشكلة كانت تقلل من شفافية الاستخدام لدى كثير من فرق الأعمال والتطوير. فعندما يرى المستخدم ما استهلكه فعليًا، يصبح ضبط التكلفة أسهل، وتصبح قرارات الإدارة والتفعيل أكثر دقة.

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

أدوات المتصفح في GitHub Copilot أصبحت متاحة رسميًا داخل Visual Studio Code منذ 1 يوليو 2026، وهي خطوة مهمة للمطورين الذين يريدون اختبار صفحات الويب والتنقل داخل التطبيقات مباشرة من المحرر بدل التنقل المستمر بين المتصفح وبيئة البرمجة. الإعلان الجديد من GitHub لا يضيف مجرد تكامل شكلي، بل يمنح الوكلاء الذكيين قدرة عملية على تنفيذ خطوات تصفح حقيقية مع الحفاظ على ضوابط الخصوصية والتحكم.

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

ما الذي تقدمه أدوات المتصفح في GitHub Copilot؟

بحسب إعلان GitHub الرسمي، أصبحت الأدوات مفعّلة افتراضيًا مع الإتاحة العامة، ويمكن للوكلاء البرمجيين تنفيذ مجموعة واسعة من المهام داخل المتصفح الحقيقي، منها:

• فتح الصفحات والتنقل بينها بصورة طبيعية.
• النقر والكتابة والتحويم والسحب والتعامل مع النوافذ الحوارية.
• قراءة محتوى الصفحة ورصد أخطاء الـ Console.
• التقاط لقطات شاشة عند الحاجة إلى التحقق البصري.
• تشغيل تدفقات عمل متعددة الخطوات عندما تكون أسرع من التنفيذ اليدوي.

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

لماذا يُعد التحديث مهمًا للمطورين؟

الفرق هنا أن GitHub Copilot لم يعد يكتفي بتحليل الكود أو اقتراح التعديلات، بل أصبح قادرًا على رؤية أثر هذه التعديلات داخل المتصفح. عمليًا، يمكن للمطور أن يطلب من الوكيل اختبار صفحة هبوط، أو مراجعة نموذج تسجيل، أو توثيق خطأ يظهر فقط بعد سلسلة نقرات، ثم العودة بنتيجة قابلة للاستخدام داخل بيئة العمل نفسها.

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

الخصوصية والتحكم ما زالا بيد المستخدم

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

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

ماذا عن المؤسسات وفرق العمل الكبيرة؟

GitHub أوضحت أيضًا أن مديري الأنظمة في المؤسسات يستطيعون التحكم بهذه القدرات عبر إعدادات مخصصة، بما في ذلك تفعيل أو تعطيل أدوات المتصفح، وتقييد النطاقات التي يمكن للوكلاء الوصول إليها. وهذا يمنح الشركات مساحة جيدة للاستفادة من الميزة داخل بيئات العمل المنضبطة بدل فتح الوصول بشكل عشوائي.

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

كيف تبدأ باستخدام الميزة؟

للبدء، يكفي تحديث VS Code إلى إصدار حديث ثم استخدام GitHub Copilot داخل نافذة المحرر أو نافذة الوكلاء. وتوضح وثائق VS Code الرسمية أن الأدوات هي الآلية التي تمكّن الوكلاء من تنفيذ أفعال حقيقية بدل الاكتفاء بالرد النصي، وهو ما يفسر لماذا أصبحت أدوات المتصفح عنصرًا مهمًا في تجربة التطوير الحديثة.

باختصار، أدوات المتصفح في GitHub Copilot لا تمثل مجرد تحسين إضافي، بل خطوة واضحة نحو بيئة تطوير يستطيع فيها الوكيل البرمجي اختبار الواجهات وملاحظة النتائج والمساعدة في إغلاق الحلقة بين كتابة الكود والتحقق من الأداء الفعلي. ومع الإتاحة العامة التي بدأت في 1 يوليو 2026، تبدو هذه الميزة مرشحة لتصبح جزءًا أساسيًا من سير عمل كثير من المطورين خلال الفترة المقبلة.

أعلنت Google في 9 يوليو 2026 إطلاق LiteRT.js، وهي طبقة JavaScript جديدة تتيح تشغيل نماذج الذكاء الاصطناعي مباشرة داخل المتصفح بدل الاعتماد الكامل على الخوادم السحابية. وبذلك تدخل Google بقوة إلى سباق جعل تطبيقات الويب أكثر قدرة على تنفيذ مهام الذكاء الاصطناعي محليًا، مع وعود واضحة بتحسين السرعة، وخفض التكلفة، وتعزيز الخصوصية.

وبحسب الإعلان الرسمي في مدونة مطوري Google، فإن LiteRT.js يمثل ربطًا مباشرًا لمكتبة LiteRT المعروفة في بيئات التشغيل الطرفية إلى الويب، بما يسمح للمطورين بتشغيل نماذج .tflite داخل المتصفح نفسه باستخدام تسريع عتادي حديث مثل WebGPU وWebNN إلى جانب WebAssembly.

ما هو LiteRT.js ولماذا يختلف؟

الفكرة الأساسية في LiteRT.js ليست مجرد إضافة مكتبة أخرى إلى أدوات الويب، بل نقل جزء مهم من بنية تشغيل الذكاء الاصطناعي من التطبيقات المحلية والهواتف إلى المتصفح. هذا يعني أن مطور الويب يستطيع بناء تجربة تعتمد على الرؤية الحاسوبية، أو تحليل الصوت، أو مهام التنبؤ والاستدلال، من دون أن يرسل كل طلب إلى خادم بعيد في كل مرة.

الفرق الأهم هنا أن Google لا تقدم محرك JavaScript بحتًا، بل تستفيد من مكونات LiteRT نفسها، وهو ما يسمح بإعادة استخدام تحسينات الأداء والكمّ والتوافق التي تطورت أصلًا في Android وiOS وسطح المكتب. وبهذا يصبح الانتقال من نموذج موجود إلى تجربة ويب أسرع وأكثر مباشرة، خصوصًا لمن يملكون أصلًا نماذج بصيغة .tflite.

لماذا يهم المطورين والشركات؟

أهمية LiteRT.js لا تتوقف عند الجانب التقني فقط، بل تمتد إلى نموذج العمل نفسه. عندما يجري الاستدلال داخل المتصفح، تقل الحاجة إلى إرسال البيانات الحساسة إلى خوادم خارجية، وهو ما يمنح الشركات طبقة إضافية من الخصوصية، ويقلل أيضًا من تكاليف البنية السحابية كلما زاد عدد المستخدمين.

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

وهذا المسار ينسجم مع اتجاه أوسع يرى أن المتصفح لم يعد مجرد نافذة لعرض الصفحات، بل صار طبقة تشغيل فعلية لأدوات العمل الذكية. ولمن يريد رؤية هذه الفكرة من زاوية تجربة الاستخدام اليومية، يمكنه قراءة مراجعة Dia Browser في 2026 لفهم كيف يتحول المتصفح نفسه إلى مساحة عمل أكثر ذكاءً.

أبرز المزايا العملية في LiteRT.js

1. تسريع عتادي عبر CPU وGPU وNPU

تقول Google إن LiteRT.js يستطيع الاستفادة من أكثر من مسار للتسريع: المعالج المركزي عبر XNNPACK، والمعالج الرسومي عبر WebGPU، ووحدات المعالجة العصبية عبر WebNN حيثما توفرت. هذه النقطة مهمة جدًا لأن قيمة الذكاء الاصطناعي على الويب لا تظهر في مجرد تشغيل النموذج، بل في القدرة على تشغيله بسرعة كافية تسمح بتجارب لحظية وتفاعلية.

2. طريق أسهل لنماذج PyTorch وLiteRT

من المزايا العملية أيضًا أن Google تضع LiteRT.js ضمن منظومة أوسع تشمل التحويل من PyTorch إلى LiteRT، ثم نشر النموذج على الويب. هذا يقلل الاحتكاك بين فرق تعلم الآلة وفرق الواجهة الأمامية، ويجعل الانتقال من النموذج التجريبي إلى المنتج الفعلي أكثر سلاسة.

3. أداء أفضل في الاستخدامات الثقيلة

بحسب الأرقام التي عرضتها Google، تفوق LiteRT.js على بعض بيئات التشغيل المنافسة بما يصل إلى 3 مرات في بعض اختبارات الاستدلال على CPU وGPU، بينما قد تصل مكاسب التسريع إلى 5 إلى 60 مرة عند الاستفادة من WebGPU أو WebNN بدل التنفيذ القياسي على CPU في التطبيقات الشرهة للأداء مثل تتبع الأجسام، وتحويل الصوت، ومعالجة الصور في الزمن الحقيقي. هذه أرقام مرجعية من اختبارات Google نفسها، لكنها تعطي مؤشرًا واضحًا على اتجاه الأداء الذي تستهدفه المنصة.

أين يمكن أن نرى LiteRT.js فعليًا؟

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

الميزة هنا أن هذه السيناريوهات لا تحتاج دائمًا إلى نموذج لغوي ضخم. أحيانًا يكفي نموذج رؤية، أو كشف كائنات، أو تصنيف، أو تحسين صورة، وهذه كلها فئات تستفيد بقوة من التنفيذ المحلي السريع عندما تكون الموارد العتادية متاحة.

هل يعني ذلك نهاية TensorFlow.js؟

ليس بالضرورة. Google تقدم LiteRT.js بوصفه امتدادًا أكثر كفاءة لبعض الاستخدامات، لا إعلان وفاة فوريًا لكل ما سبقه. ما يتغير فعلًا هو أن المطورين صار لديهم خيار أقوى حين يريدون تشغيل نماذج .tflite بكفاءة أعلى داخل المتصفح، خصوصًا في المشاريع التي تحتاج أداءً قريبًا من التطبيقات المحلية.

كما أن Google توفر بالفعل دليل البدء بـ LiteRT.js، ما يوحي بأنها تريد تسريع تبني الأداة عمليًا، لا الاكتفاء بإعلان نظري عنها.

الخلاصة

إطلاق LiteRT.js خطوة مهمة لأنها تدفع فكرة الذكاء الاصطناعي داخل المتصفح من خانة التجارب المثيرة إلى خانة البنية القابلة للاستخدام الفعلي. وإذا تمكنت Google من الحفاظ على هذا الزخم في التوافق، والتوثيق، ودعم WebNN وWebGPU على نطاق أوسع، فقد نرى جيلًا جديدًا من تطبيقات الويب الذكية التي تكون أسرع وأرخص وأكثر احترامًا لخصوصية المستخدم.

باختصار، LiteRT.js ليس مجرد مكتبة جديدة للمطورين، بل إشارة واضحة إلى أن معركة الذكاء الاصطناعي القادمة لن تكون فقط على مستوى النماذج، بل أيضًا على مستوى مكان التنفيذ نفسه: هل يبقى في السحابة، أم ينتقل أكثر فأكثر إلى جهاز المستخدم؟