بُن پروجیکٹ نے مئی 2026 میں زِگ سے رسٹ میں ایک بڑی کوڈ منتقلی مکمل کی، جس میں 11 دن میں 10 لاکھ سے زائد لائنز کوڈ میں تبدیلیاں اور 6,778 کامیٹس کی گئیں۔ اس منتقلی کے لیے 64 کلوڈ کو متوازی طور پر استعمال کیا گیا، جس سے 165,000 امریکی ڈالر کا API اخراج ہوا۔ منتقلی کے بعد میموری لیک کا مسئلہ جڑ سے حل ہو گیا، 2,000 بِلڈس کے بعد میموری 6.7 جیگا بائٹ سے 609 میگا بائٹ تک مستقل ہو گئی، پرفارمنس میں 2 فیصد سے 5 فیصد تک بہتری آئی، اور بائنری فائل کا سائز تقریباً 20 فیصد کم ہو گیا۔ تاہم، کوڈ میں تقریباً 13,000 unsafe کلیدی الفاظ موجود ہیں، جو اس قسم کے دوسرے پروجیکٹس کے مقابلے میں 178 گنا زیادہ ہیں، اور اس میں 19 جانے والے ریگریشن مسائل بھی موجود ہیں، اور 10 لاکھ لائنز کوڈ کو انسانی طور پر ایک ایک کر کے جانچنا ناممکن ہے۔ اب بُن کو اینتھروپک نے خرید لیا ہے۔

مضمون کے مصنف، ذریعہ: InfoQ

مئی 2026 میں، بن پروجیکٹ نے سافٹ ویئر ڈویلپمنٹ کی تاریخ میں تقریباً نایاب بڑے پیمانے پر کوڈ میگریشن مکمل کی۔

یہ منتقلی 3 مئی کو شروع ہوئی اور 14 مئی تک مین برانچ میں مکمل طور پر ضم ہو گئی، صرف 11 دن میں۔ کوڈ لکھنے میں صرف 6 دن لگے اور پورا عمل علنا تھا۔ لیکن جیرڈ سمنر نے اپنا بلاگ مضمون لکھنے میں تقریباً ایک ماہ لگا، جو کوڈ لکھنے کے وقت سے کہیں زیادہ تھا۔

یہ JavaScript رنٹائم اصل میں 535,496 لائنز Zig کوڈ رکھتا تھا، تبصرے کو شامل نہیں کیا گیا؛ اس کے علاوہ، تقریباً 20 فیصد کوڈ C++ میں لکھا گیا تھا اور کئی C/C++ لائبریریز کو اندرا ڈالا گیا تھا۔ اب اسے AI کی مدد سے Rust میں دوبارہ لکھا گیا ہے، جس میں 10 لاکھ سے زائد لائنز کوڈ میں تبدیلیاں، 6,778 کمٹس شامل ہیں، اور Claude Code میں تقریباً 50 ڈائنانمک ورک فلوز چلائے گئے۔

سمرن کے افشا کردہ ڈیٹا کے مطابق، اس ری ورائٹ کے لیے API لیول پر 5.9 ارب غیر کیش شدہ ان پٹ ٹوکن، 690 ملین آؤٹ پٹ ٹوکن، اور 72 ارب کیش شدہ ان پٹ ٹوکن پڑھے گئے، جس کی API قیمت کے مطابق تقریباً 165,000 امریکی ڈالر لاگت آئی۔

سمنر نے کہا کہ یہ موجودہ ٹیکنالوجی کی حد تک پہنچنے کا نتیجہ ہے۔ ان کا اندازہ ہے کہ اگر 3 مکمل طور پر بن کوڈ بیس سے واقف انجینئرز کو اس منتقلی کو ہاتھ سے کرنے دیا جائے، تو اس میں تقریباً ایک سال لگ جائے گا، اور اس دوران ٹیم تقریباً نئے فیچرز، بگ فکسز اور سیکورٹی فکسز پر کام جاری رکھنے میں ناکام رہے گی۔

اس دوبارہ لکھنے کے بعد، Bun v1.3.14 آخری Zig ورژن ہوگا، اور Bun v1.4.0 پہلا Rust ورژن ہوگا۔

1 نتیجہ: 6.7 جیگابائٹ میموری لیک سے 609 میگابائٹ مستقل تک

بُن اصل میں ایک زِگ منصوبہ تھا جس کا دائرہ کار بہت وسیع تھا: یہ جاوااسکرپٹ اور ٹائپ اسکرپٹ ٹرانسپائلر، بینڈلر، پیکج مینیجر، ٹیسٹ رنر، ماڈیول ریزولور، ایچ ٹی ٹی پی اور ویب سوکٹ کلائنٹ تھا، اور نوڈ جے ایس اے پی لیئر بھی لاگو کرتا تھا۔ اسی پروڈکٹ کی وسعت کی وجہ سے بُن کے سی ایل آئی کے ماہانہ ڈاؤن لوڈز 22 ملین سے زائد ہو گئے، اور ورسل، ریلوے، ڈیجیٹل اوشن، کلوڈ کوڈ اور اوپن کوڈ جیسے منصوبوں یا کمپنیوں کی حمایت حاصل ہوئی۔

لیکن اسی چوڑائی کی وجہ سے بُن کو کچھ چیلنجز بھی پیدا ہوئے۔

بُن v1.3.14 میں، ایک ایسا مسئلہ تھا جس سے بہت سے لوگ پریشان تھے: جب آپ متعدد بار Bun.build() کے کالز کرتے ہیں، تو میموری لگاتار جمع ہوتی رہتی ہے اور کبھی ریلیز نہیں ہوتی۔ ہر بار بننے میں تقریباً 3MB کی میموری لیک ہوتی ہے، جو زیادہ نہیں لگتا، لیکن اگر آپ ایک ڈویلپمنٹ سرور چلا رہے ہیں جہاں ہر ریکوئس پر ایک بِلڈ ٹرگر ہوتا ہے، تو میموری آہستہ آہستہ کھا جائے گی اور عمل تباہ ہو جائے گا۔

اصلی ٹیسٹ میں، 500 بار بنا کر میموری استعمال 1.9GB، 1000 بار کے بعد 3.5GB، 1500 بار کے بعد 5.1GB، اور 2000 بار کے بعد 6.7GB تک بڑھ گئی۔

یہ صرف کئی میموری مسائل کا ایک چھوٹا سا حصہ ہے۔ v1.3.14 کی بگ فکس لسٹ میں سنر نے لمبی فہرست مسائل درج کی ہیں:

jab zlib میڈیول میں .reset() کو بلایا جاتا ہے اور ایک مزید async.write() تھریڈ پول میں چل رہا ہو، تو پراسیس "ہیپ کے بعد استعمال" کی وجہ سے کریش ہو جاتا ہے؛ http2 میڈیول میں نیسٹڈ جاوااسکرپٹ کال بیکس نے ہیش ٹیبل کو ریہیش کر دیا، جس سے اندر کے اسٹریم پوائنٹرز ناکارہ ہو گئے؛ UDPSocket.sendMany() کے دوران، اگر صارف کوڈ valueOf یا toString کال بیکس کے ذریعے سوکٹ کی کنکشن حالت بدل دے، تو باؤنڈری اوور فلو ہوتا ہے؛ crypto.scrypt جب آؤٹ پٹ بفر کی تفویض ناکام ہو جائے، تو کال بیک اور محفوظ پاس ورڈ بفر کبھی رہائی نہیں ملتے؛......

ان خطا کی مشترکہ خصوصیت واضح ہے — وہ تقریباً سب ایک ہی جڑ کی طرف اشارہ کرتی ہیں: ایک ہی سافٹ ویئر میں GC اور ہاتھ سے میموری مینجمنٹ کو ملا دینا۔

جیسے JavaScriptCore (اور V8) جیسے جدید انجن میں ایکسپشن ہینڈلنگ اور GC کے لیے بہت سخت قواعد ہوتے ہیں، جبکہ Zig C زبان کی طرح میموری کو خودکار طور پر مینیج نہیں کرتا۔ جب یہ دونوں پیراڈائمز ایک ہی پروسیس میں ہوتے ہیں، تو ہر میموری الائوسمن کو لائن بائن جانچنا پڑتا ہے: یہ بائٹس کہاں فری ہوتے ہیں؟ کیسے یقینی بنایا جائے کہ صرف ایک بار فری ہو؟ کیا JavaScript ایکسپشنز کو درست طریقے سے چیک کیا گیا ہے؟ کیا یہ GC کے ذریعے مینیج کی جانے والی پوائنٹر کنسروٹو اسٹیک سکینر کے لیے دکھائی دے رہی ہے؟ کیا یہ GC میموری ہے یا مینولی مینیجڈ میموری؟

مزید پریشانی کی بات یہ ہے کہ ٹیم نے کوئی کوشش نہیں چھوڑی۔ انہوں نے Zig کمپائلر میں تبدیلیاں کی ہیں، Address Sanitizer (ASAN) کی سپورٹ شامل کی ہے، ہر سب مٹن پر CI میں ASAN ٹیسٹ چلائے جاتے ہیں، ونڈوز پر ReleaseSafe بنا کر، Fuzzilli کا استعمال کرتے ہوئے 24/7 فزا ٹیسٹنگ کی جاتی ہے، اور بہت سارے اینڈ تو اینڈ میموری لیک ٹیسٹ بھی کیے جاتے ہیں۔ اس کے باوجود، کریش رپورٹس لگاتار آتے رہتے ہیں۔

"ہماری بگ فکس لسٹ بہت برا محسوس ہوتی ہے، میں Bun کے کریش کے خوف کے ساتھ سونے کو تھک چکا ہوں،" سمنر نے لکھا۔ وہ زِگ کو الزام نہیں دے رہا تھا — دیگر زِگ صارفین کو Bun جیسی مسائل نہیں ہوئیں، کیونکہ GC کو ہاتھ سے مینج کی جانے والی میموری کے ساتھ ملا نا ایک بہت نایاب ضرورت ہے، جس کے لیے تقریباً کوئی زبان نہیں بنائی گئی۔

جبکہ رسٹ ورژن نے 2000 بار Bun.build() کے انجام کے بعد 609 میگا باٹ کی مستقل میموری استعمال کی۔

میموری لیک کے مسئلے کے بنیادی طور پر حل ہونے کے علاوہ، رسٹ کی دوبارہ تحریر نے دیگر کئی پہلوؤں میں بہتری بھی لائی ہے۔

استحکام کے لیے، v1.4.0 نے v1.3.14 میں قابل دوہرائی 128 بگس کو درست کیا، جس میں میموری لیک سے لے کر کریش اور رنگ کے نمایاں ہونے والے مدد کے متن تک کے تمام مسائل شamil ہیں۔

حجم کے لحاظ سے، رسٹ کو دوبارہ لکھنے، ICU میں تبدیلیاں اور ایک جیسے کوڈ فولڈنگ کے ساتھ، Bun کے لِنکس اور ونڈوز پر بائنری فائل کا سائز تقریباً 20 فیصد کم ہو گیا ہے۔

performance میں عام طور پر 2% سے 5% تک بہتری آئی۔ Bun.serve 16.96 لاکھ req/s سے بڑھ کر 17.77 لاکھ req/s ہو گیا، جبکہ node:http 10.38 لاکھ سے بڑھ کر 10.85 لاکھ ہو گیا۔ عملی استعمال کے مطابق، next build 13.62 سیکنڈ سے گھٹ کر 13.03 سیکنڈ ہو گیا، اور tsc بیچ کمپائلیشن 0.94 سیکنڈ سے گھٹ کر 0.89 سیکنڈ ہو گئی۔

جبکہ Claude Code کو Rust Bun پر جاری کرنے کے بعد، Linux پر اسٹارٹ اپ ٹائم 517 ملی سیکنڈ سے گھٹ کر 464 ملی سیکنڈ ہو گیا، جو تقریباً 10 فیصد تیز ہے۔

2 طریقے: 64 کلاؤڈ، 11 دن، 50 ورک فلو

سمنر نے یہ کیسے کیا، یہ شاید سب سے زیادہ توجہ کا مرکز ہے — کیونکہ اس نے جو طریقہ استعمال کیا، وہ روایتی "AI کو کوڈ لکھنے کے لیے کہنا" سے مختلف تھا۔

سمر نے پورے عمل کو تقریباً 50 ڈائنانک ورک فلو میں تقسیم کیا، جن میں سے ہر ایک ایک سائکل ہے۔ اس نے اپنے بلاگ میں اس ماڈل کو پسودو کوڈ کے ساتھ بیان کیا:

ہر کام کا ایک حوالہ ہوتا ہے (مثلاً ایک Jira ٹکٹ یا GitHub ایشو)، اور کلوڈ اس حوالہ کے مطابق کوڈ لکھتا ہے، پھر دو جانچنے والے (بھی کلوڈ) کوڈ کا جائزہ لیتے ہیں، اور آخر میں فیڈ بیک لاگو کیا جاتا ہے۔ اس کے بعد، اگلے کام کو لیا جاتا ہے۔

یہ ماڈل پورے ریوائٹ پروسیس کے ذریعے پایا جاتا ہے۔ ہر ورک فلو ایک خاص مقصد کے لیے ذمہ دار ہے:

• زِگ کے پیٹرن اور ٹائپس کو رسٹ کے پیٹرن اور ٹائپس میں مپ کرنے کے لیے ایک پورٹنگ گائیڈ تیار کریں؛
• ہر .zig فائل کو ایک .rs فائل میں مکینیکل طور پر منتقل کریں، اور PORTING.md اور LIFETIMES.tsv کے ساتھ مطابقت رکھیں؛
• ہر کریٹ کی کمپائلیشن کی خرابیوں کو درست کریں؛
• bun test یا bun build جیسے سب کمانڈز کو چلائیں؛
• بُن کے مکمل ٹیسٹ سوٹ میں ہر ٹیسٹ کو کامیاب بنائیں؛ کچھ بڑے ریفیکٹرنگ اور صفائی کے دور کریں۔

اُچھی چوٹی پر، سمنر نے 4 ورکفلوز چلائے، جن میں سے ہر ایک میں 16 کلاؤڈ تھے، جس سے کل 64 کلاؤڈ 4 ورک ٹریز میں ایک ساتھ متوازی طور پر کام کر رہے تھے اور فائلیں جمع اور پوش کر رہے تھے۔ سب سے زیادہ چوٹی پر، کلاؤڈ فی منٹ تقریباً 1300 لائنز کوڈ لکھتا تھا۔

یہ "عمل کرنے والا / جانچنے والا" کا الگ کرنا کلیدی ہے۔ کوڈ لکھنے والے کلود کو کوڈ قبول ہونا چاہیے، جس میں انسانی انجینئرز کی طرح جانبداری ہوتی ہے۔ اس لیے جانچنے والے اور عمل کرنے والے مکمل طور پر الگ ہیں — جانچنے والا صرف کوڈ کے فرق دیکھتا ہے، عمل کرنے والے کے استدلال کو نہیں، اور اسے واضح طور پر بتایا جاتا ہے کہ "کوڈ غلط ہے"۔ ہر عمل کرنے والا دو سے زیادہ مخالف جانچنے والوں کا سامنا کرتا ہے، جن کا واحد کام بگز تلاش کرنا ہے۔

کوڈ لکھنا صرف پہلا مرحلہ ہے۔ زِگ کوڈ ایک منفرد کمپائل یونٹ ہے، جبکہ رسٹ کو تقریباً 100 کریٹس میں تقسیم کیا جاتا ہے تاکہ کمپائلیشن کی رفتار بڑھائی جا سکے، جس سے سائیکلک ڈیپینڈنسی کی وجہ سے کارگو چیک ایک بار میں تقریباً 16,000 کمپائلیشن ایررز ظاہر کرتا ہے۔ ایک شخص کے لیے یہ تباہی ہے، لیکن 64 متوازی طور پر کام کرنے والے کلاؤڈ کے لیے یہ قابلِ انتظام ورک کیو ہے۔ ورک فلو ایررز کو کریٹس کے لحاظ سے گروپ کرتا ہے، ہر کریٹ پر کارگو چیک چلایا جاتا ہے، ایک کلاؤڈ ایرر درست کرتا ہے، دو اس کا جائزہ لیتے ہیں، اور ایک تبدیلیاں لاگو کرتا ہے۔

اگلے مرحلے میں bun --version چلائیں، پھر bun test۔ ٹیسٹ ورک فلو ہر بار 100 ٹیسٹ فائلز کو 4 ورک ٹریز میں تقسیم کرتا ہے۔ ٹیسٹ سوٹ میں کئی قسم کے ٹیسٹ شامل ہیں: کچھ ٹیسٹ ایک منٹ سے زیادہ چلتے ہیں، کچھ سسٹم TCP کنکشنز کی حد تک استعمال کرتے ہیں، اور کچھ تقریباً 10000 پروسیسز کا فورک کرتے ہیں۔ سمنر نے systemd-run کا استعمال کرکے cgroup بنایا تاکہ وسائل کو محدود کیا جا سکے، لیکن مشین کئی بار ڈسک اسپیس کی کمی کی وجہ سے کریش ہو گئی۔

دو دن بعد، لینکس پلیٹ فارم کے ناکام ٹیسٹ 972 سے گھٹ کر 23 رہ گئے۔ ایک اور نصف دن بعد، لینکس پر سب کچھ گرین ہو گیا۔ پانچ دن بعد، تمام ستہ پلیٹ فارمز — لینکس x64، لینکس arm64، میک او ایس x64، میک او ایس arm64، ونڈوز x64، ونڈوز arm64 — سب نے کامیابی حاصل کر لی۔

14 مئی کو، PR #30412 کو بالکل مربوط کر دیا گیا، اور ٹیسٹ سوٹ مکمل طور پر کامیاب ہو گیا، کوئی ٹیسٹ نہیں چھوڑا یا حذف کیا گیا۔

3 خفیہ خطرات: 13,000 غیر محفوظ اور لائن بہ لائن جانچ کے قابل نہیں کوڈ

تاہم، سنمر نے تسلیم بھی کیا کہ یہ کام ابھی تک مکمل نہیں ہوا۔

اب تک، Bun کے Rust کوڈ میں تقریباً 4% unsafe بلاکس میں ہے، جس میں تقریباً 13,000 unsafe کی ورڈز ہیں، جو تقریباً 27,000 لائنز کوڈ میں پھیلے ہوئے ہیں، جبکہ Rust کے کل کوڈ کی مقدار تقریباً 780,000 لائنز ہے۔ اس میں سے 78% unsafe بلاکس صرف ایک لائن کے ہیں، جو عام طور پر C++ سے ایک پوائنٹر یا C لائبریری پر ایک کال ہوتی ہے۔

وہ متوقع کرتے ہیں کہ بعد کی دوبارہ ڈیزائن کرنے سے یہ تناسب کم ہو جائے گا۔ لیکن کسی نے ایک حساب لگایا: uv میں تقریباً 350,000 لائنز کوڈ ہیں، جن میں صرف 73 بار unsafe کالز ہیں۔ جبکہ Bun میں unsafe کالز کی تعداد uv سے 178 گنا زیادہ ہے۔ اس فرق کو "C لائبریریز کو کال کرنے کی ضرورت" کے ذریعے سمجھنا مشکل ہے۔

اور پھر اس کے بعد محفوظ Rust کوڈ میں بھی غیر تعریف شدہ رویہ ظاہر ہوا۔ یہ C++ سے زیادہ ڈیبگ کرنا مشکل ہے، کیونکہ آپ سمجھتے ہیں کہ محفوظ کوڈ میں کوئی مسئلہ نہیں ہو سکتا۔

بُن ٹیم نے بعد میں اس مسئلے میں PathString::init کو unsafe fn میں تبدیل کر دیا۔

سمنر نے خود تسلیم کیا کہ اس دوبارہ لکھنے سے 19 معلوم ریگریشن مسائل پیدا ہوئے ہیں، اور انہوں نے کہا کہ زیادہ تر ریگریشن مسائل وہیں سے آئے ہیں جہاں سینٹیکس ایک جیسا تھا لیکن سیمنٹکس مختلف تھے۔

مثال کے طور پر، یہ دو کوڈ اسناپس ایک جیسے لگتے ہیں، لیکن ان کا رویہ بالکل مختلف ہے۔ زِگ کا کوڈ assert ایک فنکشن ہے، اس لیے اس کے پیرامیٹرز ہر بار بِلڈ میں چلائے جاتے ہیں۔ رسٹ کا کوڈ debug_assert! ایک میکرو ہے، اس لیے ریلیز ورژن میں، پورا اظہار (فنکشن کال سمیت) حذف ہو جاتا ہے insert_stale۔

ہر مسئلہ درست ہو چکا ہے، لیکن اس کا مطلب یہ نہیں کہ ملینوں لائنز کے AI کوڈ میں کوئی دوسرے مسائل نہیں ہیں۔

کوئی بھی عقلمند شخص اس کے بعد اپنا پیداواری ایپلیکیشن منتقل کرے گا جب اس کا رن ٹائم مکمل طور پر دوبارہ لکھ دیا جائے؟ اگر آپ سمجھتے ہیں کہ ورژن 1.4 میں کوئی نیا بگ نہیں شامل ہوا یا کوئی سلوک میں تبدیلی نہیں آئی، تو یہ بہت بے خبری ہے۔

ایک ایسا بات جسے نظرانداز نہیں کیا جا سکتا وہ کوڈ ریویو ہے۔ 10 لاکھ لائنز کے تبدیلی کو انسان ایک ایک کرکے نہیں دیکھ سکتا — اگر ایک منٹ میں ایک لائن دیکھی جائے تو 11.7 دن تک لگاتار دیکھنا پڑے گا؛ اصل کوڈ ریویو کی رفتار (ایک گھنٹے میں 200 لائنز) کے مطابق، اسے دیکھنے میں دو سال سے زیادہ لگ جائیں گے۔

اس پری کی درخواست کے جائزہ لینے والے بنیادی طور پر claude[bot] اور coderabbitai[bot] تھے۔ سنمر نے خود تسلیم کیا ہے کہ اس کا جائزہ لینے کا طریقہ “مخالف جائزہ لینے والے ایجنٹ کو یقینی بنانا ہے کہ وہ فرق درست طریقے سے پکڑ رہا ہے، تبدیلی کے ہدایات کی پابندی کی گئی ہے، اور اس نے خود کافی کوڈ بھی دیکھا”۔ لیکن “کافی” کا مطلب کیا ہے، اس کا ذکر اس نے نہیں کیا۔

ایک اور ناگزیر سوال یہ ہے کہ Bun کو 2025ء کے دسمبر میں Anthropic نے خرید لیا، اور اس کوڈ بیس کو مؤثر طریقے سے برقرار رکھنے کا واحد عملی ٹول تقریباً صرف Claude ہی ہے۔ کمیونٹی میں کچھ لوگ کہتے ہیں کہ اب یہ روایتی معنوں میں اوپن سورس پروجیکٹ نہیں رہا—اگر آپ Bun کے لیے PR دینا چاہتے ہیں، تو آپ کو Anthropic کا سبسکرائب کرنا ہوگا، یا ان کچھ مرکزی ممبران پر انحصار کرنا ہوگا جنہوں نے AI جنریٹڈ کوڈ کو سمجھ لیا ہے۔

165,000 امریکی ڈالر کے بدلے ایک سال کا کام، کیا یہ قیمتی ہے؟

سمنر نے اپنے بلاگ میں اس بات کا بھی انکشاف کیا کہ اس ری ورٹ کی API کی لاگت تقریباً 165,000 امریکی ڈالر ہے، جو تین انجینئرز کے ایک سال کے کام کے برابر ہے۔ یہ عدد ہیکر نیوز پر تشدد کے ساتھ بحث کا موضوع بن گیا۔

کچھ لوگوں کا خیال ہے کہ یہ اخراجات حقیقت میں بہت سود مند ہیں۔ سلیکون ویلی میں 165,000 امریکی ڈالر صرف کر کے کچھ مکمل وقت کے انجینئرز نہیں مل سکتے، خاص طور پر Anthropic جیسی کمپنیوں کے انجینئرز کے لیے تو بات ہی کچھ اور ہے۔ levels.fyi پر دی گئی تنخواہوں کے مطابق، Anthropic کے انجینئرز کی کل تنخواہ 500,000 امریکی ڈالر یا اس سے زیادہ ہونے کا امکان ہے۔ 50 انجینئرز کی اوسط سالانہ تنخواہ 336,000 امریکی ڈالر کے تقريبی حساب سے، روزانہ تقریباً 1,292 امریکی ڈالر آتا ہے۔ 50 افراد کا 11 دن تک لگاتار کام کرنا، صرف انسانی وسائل کے خرچے کے لحاظ سے تقریباً 710,000 امریکی ڈالر کے برابر ہے، جس میں فوائد، دفتر کا اجارہ، سامان اور دیگر انتظامی اخراجات شamil نہیں۔

لیکن، سمنر نے "کلوڈ فیبل 5 کا پری ریلیز ورژن" استعمال کیا، جو عوام کے لیے ابھی تک دستیاب نہیں ہے اور جس پر برآمد کنٹرول لگ سکتا ہے۔ اس لیے API کی قیمت صرف آخری صارفین کو دکھائی جانے والی رقم ہے، جبکہ اس کے پیچھے اینتھرپک کی طرف سے کی گئی بہت بڑی تحقیق و ترقی کی لاگت ہے۔ کچھ لوگوں نے اشارہ کیا ہے کہ لاگت کو صرف API کی قیمت تک محدود کرنا حقیقی انvestments کو چھپانے کی کوشش ہے۔ اگر مدل ترقی، تربیت، کمپوٹنگ طاقت، انجینئرنگ مزدوری سمیت تمام لاگتوں کو شامل کیا جائے، تو مجموعی لاگت بہت زیادہ ہوگی، اور یقیناً 1.5 ملین امریکی ڈالر سے زیادہ ہو سکتی ہے۔

اور اب تک کی صورت حال میں، جبکہ 165,000 امریکی ڈالر کے بدلے ایک سال کا کام کرنے کا خرچہ، اعداد و شمار کے لحاظ سے کافی منافع بخش لگ رہا ہے۔

لیکن اصل لاگت اس بکھری ہوئی فہرست پر نہیں ہے۔ اس کوڈ بیس میں 6778 کمٹس ہیں، اور کوئی بھی انہیں پورے طور پر نہیں پڑھ چکا، حالانکہ اب سب کچھ ٹھیک لگ رہا ہے، لیکن چھ ماہ بعد کیا ہوگا؟ جب کوئی عجیب ہم آہنگی کی مسئلہ رات کے تین بجے اچانک ظاہر ہو جائے، تو نگرانی کرنے والے انجینئر کے سامنے ایسا نظام ہوگا جس کا اندر کا منطق وہ خود بھی واضح نہیں کر سکتا۔ مستقبل میں اسے AI کے ذریعے مینٹین کرنا پڑے گا، اور مینٹیننس کی لاگت کیسے گنتی جائے؟ اصل میں یہ بہت مشکل ہے۔