Claude کے ان پٹ اور آؤٹ پٹ ٹوکنز کی قیمت میں فرق کیوں ہے؟

آؤٹ پٹ ٹوکنز کی قیمت ان پٹ ٹوکنز سے زیادہ کیوں ہوتی ہے

موجودہ کیٹلاگ میں موجود ہر Claude ماڈل پر آؤٹ پٹ ٹوکنز کی قیمت ان پٹ ٹوکنز کے مقابلے میں پانچ گنا زیادہ ہے۔ اس کی وجہ کمپیوٹیشن کی ساخت ہے۔ پرامپٹ کو پڑھنا ماڈل پر ایک ہی پاس (pass) میں مکمل ہو جاتا ہے۔ جواب لکھنا ہر ٹوکن کے لیے ایک الگ پاس ہے، اور ہر پاس کو اپنے سے پہلے والے پاس کا انتظار کرنا پڑتا ہے۔

یہ تناسب پرائس لسٹ کی ہر قطار میں یکساں ہے، لہذا آپ جو بھی ماڈل منتخب کریں، اس سے آپ کے بل میں آؤٹ پٹ کا حصہ تبدیل نہیں ہوتا۔ اس کا فیصلہ آپ کے ورک لوڈ کی نوعیت کرتی ہے۔ ایک ایجنٹ سٹیپ جو 60,000 ٹوکنز پڑھتا ہے اور 800 ٹوکنز میں جواب دیتا ہے، اس پر آؤٹ پٹ کی لاگت نہ ہونے کے برابر آتی ہے۔ ایک ڈرافٹنگ جاب جو 2,000 ٹوکنز پڑھتی ہے اور 12,000 ٹوکنز لکھتی ہے، اس پر ان پٹ کی لاگت نہ ہونے کے برابر آتی ہے۔ دونوں صورتوں کا موازنہ ذیل میں Anthropic کے اگست 2026 کے شائع شدہ نرخوں کے مطابق کیا گیا ہے۔

Prefill ایک بار چلتا ہے، decoding ہر token کے لیے ایک بار ہوتی ہے

ایک inference سرور درخواست کو دو مراحل میں ہینڈل کرتا ہے جن کی لاگت بہت مختلف ہوتی ہے۔ Prefill پرامپٹ کو پڑھتا ہے۔ Decoding جواب لکھتا ہے۔

Prefill پورے پرامپٹ کو ایک ساتھ لیتا ہے۔ ہر پرامپٹ ٹوکن ایک ہی forward pass میں نیٹ ورک میں داخل ہوتا ہے، لہذا attention اور feed-forward کا کام بڑی میٹرکس ضربوں (matrix multiplications) کی ایک چھوٹی تعداد بن جاتا ہے جو ایک وقت میں ہزاروں ٹوکنز کا احاطہ کرتی ہے۔ میموری سے ماڈل ویٹس (model weights) کو ایک بار پڑھنا پورے پرامپٹ کے لیے کافی ہوتا ہے۔ ایکسیلریٹر کی میٹرکس یونٹس مصروف رہتی ہیں، جس کا مطلب ہے کہ prefill compute-bound ہے: حد یہ ہے کہ چپ کتنی تیزی سے ضرب کر سکتی ہے۔

Decoding اس طرح کام نہیں کر سکتی، کیونکہ ٹوکن 2 کا انحصار ٹوکن 1 پر ہوتا ہے۔ ماڈل نے جو ٹوکن ابھی تیار کیا ہے وہ اگلے مرحلے کے ان پٹ کا حصہ بن جاتا ہے، لہذا یہ مراحل ایک ساتھ نہیں چل سکتے۔ ہر آؤٹ پٹ ٹوکن کو اپنی forward pass ملتی ہے، اور ان میں سے ہر پاس ایک ٹوکن تیار کرنے کے لیے ہائی بینڈوڈتھ میموری سے ماڈل ویٹس کا پورا سیٹ پڑھتی ہے۔ یہ decoding کو memory-bound بناتا ہے: حد یہ ہے کہ ویٹس کتنی تیزی سے منتقل ہو سکتے ہیں، نہ کہ یہ کہ وہ کتنی تیزی سے ضرب ہو سکتے ہیں۔ وہی ویٹ ٹریفک جس نے prefill کے دوران ایک پورا پرامپٹ استعمال کیا تھا، decoding کے دوران آپ کو صرف ایک ٹوکن فراہم کرتی ہے۔

سرونگ سسٹمز batching کے ذریعے اس کا مقابلہ کرتے ہیں۔ بہت سی درخواستیں ایک ساتھ decode ہوتی ہیں، لہذا ویٹس کو ایک بار پڑھنے سے بیچ میں موجود ہر درخواست کے لیے ایک ٹوکن تیار ہوتا ہے۔ یہی وجہ ہے کہ decoding کسی حد تک قابل برداشت ہے۔ حد پھر سے میموری ہے۔ ہر جاری درخواست ایک KV cache (key/value cache، اب تک کے ہر ٹوکن کے لیے محفوظ شدہ attention state) رکھتی ہے، وہ کیش ہر تیار کردہ ٹوکن کے ساتھ بڑھتی ہے، اور جب یہ ایکسیلریٹر کو بھر دیتی ہے تو بیچ مزید نہیں بڑھ سکتا۔

ان میں سے کوئی بھی چیز آپ کو درست نمبر نہیں دیتی، اور آپ کو 5x کو ہارڈویئر کے پیمانے کے طور پر نہیں دیکھنا چاہیے۔ یہ ایک قیمت ہے، جو Anthropic نے مقرر کی ہے، اور اس عدم توازن (asymmetry) کو مدنظر رکھتی ہے۔ جو چیز آپ خود چیک کر سکتے ہیں وہ سمت ہے، اور اس میں تقریباً ایک منٹ لگتا ہے۔

ان پٹ اور آؤٹ پٹ کے فرق کی پیمائش خود کریں

کسی بھی Ubuntu مشین پر ٹولز انسٹال کریں:

sudo apt update && sudo apt install -y curl jq moreutils

اب ایک مختصر پرامپٹ اسٹریم کریں جو ایک طویل جواب کا مطالبہ کرے، اور ہر لائن پر اس کے پہنچنے کا وقت درج کریں۔

curl -sN https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model":"claude-sonnet-5","max_tokens":1000,"stream":true,
       "messages":[{"role":"user","content":"Count from 1 to 300, one number per line."}]}' \
  | ts -s '%.s'

ts -s ہر لائن کے شروع میں کمانڈ شروع ہونے کے بعد سے گزرے ہوئے سیکنڈز کا اضافہ کرتا ہے۔ اس آؤٹ پٹ سے دو چیزیں پڑھنا مفید ہے۔ پہلی content_block_delta لائن آپ کا time to first token ہے، اور تمام prefill اسی کے اندر مکمل ہوا۔ اس کے بعد کی ہر لائن decoding کا ایک چھوٹا قدم ہے، اور stamps تب تک بڑھتے رہتے ہیں جب تک message_stop موصول نہ ہو جائے۔

اب صورتحال کو الٹ دیں۔ پرامپٹ میں ایک طویل دستاویز رکھیں اور جواب کو چند ٹوکنز تک محدود رکھیں۔

curl -sN https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d "$(jq -n --rawfile doc ./long-document.txt \
       '{model:"claude-sonnet-5", max_tokens:16, stream:true,
         messages:[{role:"user", content:("Answer in one word. Is this document about networking?\n\n" + $doc)}]}')" \
  | ts -s '%.s'

پہلا ڈیلٹا مختصر پرامپٹ کے مقابلے میں زیادہ وقت لیتا ہے، کیونکہ prefill کو پڑھنے کے لیے بہت زیادہ ٹیکسٹ موجود ہوتا ہے۔ اس کے آنے کے بعد جواب تقریباً فوراً ختم ہو جاتا ہے، کیونکہ decode کرنے کے لیے صرف چند ٹوکنز باقی ہوتے ہیں۔ دسیوں ہزار ٹوکنز اندر گئے اور کلاک بمشکل ہلی۔ چند سو ٹوکنز باہر آئے اور کلاک پورے وقت چلتی رہی۔

ہر نان اسٹریمنگ جواب ان نمبروں پر ختم ہوتا ہے جن کی آپ کو بلنگ کی جاتی ہے۔

{
  "usage": {
    "input_tokens": 41283,
    "output_tokens": 6,
    "cache_creation_input_tokens": 0,
    "cache_read_input_tokens": 0
  }
}

ہر درخواست کے لیے چاروں فیلڈز کو لاگ کریں۔ output_tokens میں توسیعی سوچ (extended thinking) شامل ہوتی ہے، لہذا جو ماڈل جواب دینے سے پہلے سوچتا ہے، وہ اس سوچ کی قیمت آؤٹ پٹ ریٹ کے حساب سے وصول کرتا ہے۔ کسی پرامپٹ کو بھیجنے سے پہلے اس کی قیمت جاننے کے لیے، POST /v1/messages/count_tokens اسی ریکویسٹ باڈی کو قبول کرتا ہے، ماڈل کو چلائے بغیر {"input_tokens": N} واپس کرتا ہے، اور یہ مفت ہے۔ یہ API کا واحد حصہ نہیں ہے جس کی کوئی قیمت نہیں ہے، اور Claude API کے وہ حصے جن کے لیے آپ سے کبھی بل نہیں لیا جاتا کو اپنے پہلے پروجیکٹ کا بجٹ بنانے سے پہلے دیکھنا مفید ہے۔

اگست 2026 تک Claude فی ملین ٹوکنز کے عوض کیا چارج کرتا ہے

[
  {
    "label": "Haiku 4.5",
    "input_usd": 1,
    "output_usd": 5,
    "output_multiple": 5
  },
  {
    "label": "Sonnet 5 (to 31 Aug)",
    "input_usd": 2,
    "output_usd": 10,
    "output_multiple": 5
  },
  {
    "label": "Sonnet 5 (from 1 Sep)",
    "input_usd": 3,
    "output_usd": 15,
    "output_multiple": 5
  },
  {
    "label": "Opus 5",
    "input_usd": 5,
    "output_usd": 25,
    "output_multiple": 5
  },
  {
    "label": "Fable 5",
    "input_usd": 10,
    "output_usd": 50,
    "output_multiple": 5
  }
]

آخری کالم ان پٹ پر تقسیم شدہ آؤٹ پٹ ہے، اور یہ ہر قطار میں 5 پڑھا جاتا ہے۔ Haiku 4.5 کے لیے ان پٹ $1 اور آؤٹ پٹ $5 ہے۔ Opus 5 کے لیے ان پٹ $5 اور آؤٹ پٹ $25 ہے۔ Fable 5، جو سب سے مہنگا ہے، اس کے لیے ان پٹ $10 اور آؤٹ پٹ $50 ہے، اور Fable 5 کے ان ریٹس سے آپ کو کیا ملتا ہے اس بارے میں پڑھنا ضروری ہے اس سے پہلے کہ آپ اوپر والی قطار کو نظر انداز کر دیں۔ رینج میں اوپر جانے سے دونوں اطراف ایک ہی فیکٹر سے ضرب کھاتے ہیں، لہذا یہ آپ کے کل اخراجات کو تبدیل کرتا ہے لیکن آپ کے ان پٹ اور آؤٹ پٹ کا تناسب وہیں رہتا ہے جہاں تھا۔

Sonnet 5 دو بار ظاہر ہوتا ہے کیونکہ اس کا تعارفی ریٹ ختم ہو رہا ہے۔ 31 اگست 2026 تک اس کا ان پٹ $2 اور آؤٹ پٹ $10 ہے۔ 1 ستمبر 2026 سے $3 ان پٹ اور $15 آؤٹ پٹ کا معیاری ریٹ لاگو ہوگا، جو دونوں اطراف میں 50 فیصد زیادہ ہے۔ نیچے دی گئی ہر عملی مثال میں اگست کا ریٹ استعمال کیا گیا ہے۔

ریٹس تبدیل ہوتے رہتے ہیں، اور یہ صفحہ وہ جگہ نہیں ہے جہاں آپ کو انہیں چیک کرنا چاہیے۔ claude.com/pricing ہی اصل ذریعہ ہے۔ جو چیز قیمت میں تبدیلی کے بعد بھی برقرار رہتی ہے وہ طریقہ کار ہے۔

ایک انتباہ جو قیمتوں کی فہرست میں نہیں دکھایا گیا ہے۔ Anthropic کی دستاویزات بتاتی ہیں کہ Claude 4.7 اور بعد کے ماڈلز ایک نیا ٹوکنائزر استعمال کرتے ہیں جو Sonnet 4.6 اور اس سے پہلے کے ٹوکنائزر کے مقابلے میں اسی متن کے لیے تقریباً 30 فیصد زیادہ ٹوکنز پیدا کرتا ہے۔ صرف فی ملین ٹوکنز کی قیمت پر موازنہ کرنے سے نئے ماڈل کی قیمت کم معلوم ہوگی، کیونکہ وہی دستاویز اس پر زیادہ ٹوکنز بناتی ہے۔ مکمل شدہ ٹاسک کی لاگت پر موازنہ کریں، اور اپنے اصل پرامپٹس کو اس ماڈل کے خلاف گنیں جسے آپ استعمال کرنے کا ارادہ رکھتے ہیں۔ ایک ملین Claude ٹوکنز کی اصل متن میں کیا قدر ہے اس بات کا احاطہ کرتا ہے کہ عملی طور پر یہ حجم کیسا دکھتا ہے۔

آؤٹ پٹ آپ کے بل پر کب حاوی ہونا شروع ہوتا ہے؟

چونکہ آؤٹ پٹ کی قیمت ان پٹ سے 5 گنا زیادہ ہے، اس لیے بریک ایون (break-even) کا حساب لگانا آسان ہے۔ اپنے ان پٹ ٹوکنز کو I اور آؤٹ پٹ ٹوکنز کو O کہیں۔ ان پٹ کی قیمت I ہے۔ آؤٹ پٹ کی قیمت 5 گنا O ہے۔ آؤٹ پٹ آپ کے اخراجات کا نصف تب ہوتا ہے جب 5 گنا O کی قیمت I سے زیادہ ہو، جو کہ 5 ان پٹ بمقابلہ 1 آؤٹ پٹ کا تناسب ہے۔

لہذا اگر آپ کا پرامپٹ آپ کے جواب سے پانچ گنا زیادہ طویل ہے، تو ان پٹ زیادہ خرچ والا حصہ ہے۔ اس سے کم ہونے پر، آؤٹ پٹ زیادہ خرچ والا حصہ بن جاتا ہے۔

[
  {
    "label": "100:1",
    "input_share_pct": 95.2,
    "output_share_pct": 4.8
  },
  {
    "label": "75:1",
    "input_share_pct": 93.75,
    "output_share_pct": 6.25
  },
  {
    "label": "20:1",
    "input_share_pct": 80,
    "output_share_pct": 20
  },
  {
    "label": "10:1",
    "input_share_pct": 66.7,
    "output_share_pct": 33.3
  },
  {
    "label": "5:1",
    "input_share_pct": 50,
    "output_share_pct": 50
  },
  {
    "label": "1:1",
    "input_share_pct": 16.7,
    "output_share_pct": 83.3
  },
  {
    "label": "1:6",
    "input_share_pct": 3.2,
    "output_share_pct": 96.8
  }
]

100 بمقابلہ 1 کے تناسب پر، آؤٹ پٹ کل اخراجات کا 4.8% ہوتا ہے، اور ایسی صورت میں صرف پرامپٹ کو مختصر کرنا ہی کارآمد کام ہے۔ 5 بمقابلہ 1 پر دونوں اطراف برابر ہو جاتے ہیں۔ 1 بمقابلہ 6 پر، آؤٹ پٹ 96.8% ہوتا ہے اور پرامپٹ کی قیمت نہ ہونے کے برابر رہ جاتی ہے۔ زیادہ تر لوگ اپنے تناسب کا غلط اندازہ لگاتے ہیں، اس لیے کسی بھی چیز کو بہتر (optimize) کرنے سے پہلے اپنے لاگز سے درست اعداد و شمار حاصل کریں۔

ایجنٹ ورک لوڈ: طویل سیاق و سباق، مختصر جواب

ایک ریٹریول ایجنٹ کے مرحلے پر غور کریں: 60,000 ان پٹ ٹوکنز پر مشتمل حاصل کردہ دستاویزات اور گفتگو کی تاریخ، اور 800 ٹوکنز پر مشتمل جواب۔ یہ 75 نسبت 1 کا تناسب ہے، جو ہر اس عمل کے لیے معمول ہے جس میں لکھنے سے پہلے پڑھنا شامل ہو۔

[
  {
    "label": "Haiku 4.5",
    "input_cost": 0.06,
    "output_cost": 0.004,
    "total_cost": 0.064
  },
  {
    "label": "Sonnet 5 (Aug)",
    "input_cost": 0.12,
    "output_cost": 0.008,
    "total_cost": 0.128
  },
  {
    "label": "Opus 5",
    "input_cost": 0.3,
    "output_cost": 0.02,
    "total_cost": 0.32
  },
  {
    "label": "Fable 5",
    "input_cost": 0.6,
    "output_cost": 0.04,
    "total_cost": 0.64
  }
]

ہر ماڈل پر اس کال کا آؤٹ پٹ 6.25% ہوتا ہے، کیونکہ یہ تناسب پوری پرائس لسٹ میں یکساں ہے۔ یہ کال Opus 5 پر $0.32، اگست کے ریٹ پر Sonnet 5 پر $0.128، اور Haiku 4.5 پر $0.064 کی لاگت رکھتی ہے۔ Opus 5 پر روزانہ ایسے 200 مراحل کی لاگت $64 یومیہ بنتی ہے۔

ایک بار جب آپ اس تقسیم کو دیکھ لیں تو اصل پہلو واضح ہو جاتا ہے۔ جواب کو 800 ٹوکنز سے کم کر کے 400 کرنے سے کال کی لاگت میں تقریباً 3% کی بچت ہوتی ہے۔ پرامپٹ سے 20,000 غیر ضروری ٹوکنز نکالنے سے اس کا تقریباً ایک تہائی حصہ بچ جاتا ہے۔ ریڈ ہیوی (read-heavy) ایجنٹ پر آؤٹ پٹ کی لمبائی کو محدود کرنا تقریباً بے سود کوشش ہے۔ کوڈنگ ایجنٹ کے ٹوکنز دراصل کہاں جاتے ہیں اس بات کی وضاحت کرتا ہے کہ پرامپٹ میں یہ مواد کہاں سے آتا ہے۔

جنریشن ورک لوڈ: مختصر پرامپٹ، طویل ڈرافٹ

اب اس عمل کو الٹ دیں۔ 2,000 ٹوکن کی بریفنگ، 12,000 ٹوکن کا ڈرافٹ، یعنی 1 اور 6 کی نسبت۔

[
  {
    "label": "Haiku 4.5",
    "input_cost": 0.002,
    "output_cost": 0.06,
    "total_cost": 0.062,
    "batch_total_cost": 0.031
  },
  {
    "label": "Sonnet 5 (Aug)",
    "input_cost": 0.004,
    "output_cost": 0.12,
    "total_cost": 0.124,
    "batch_total_cost": 0.062
  },
  {
    "label": "Opus 5",
    "input_cost": 0.01,
    "output_cost": 0.3,
    "total_cost": 0.31,
    "batch_total_cost": 0.155
  },
  {
    "label": "Fable 5",
    "input_cost": 0.02,
    "output_cost": 0.6,
    "total_cost": 0.62,
    "batch_total_cost": 0.31
  }
]

آؤٹ پٹ اس بل کا 96.8% ہے۔ Opus 5 کی لاگت $0.31 فی ڈرافٹ ہے جبکہ Haiku 4.5 پر یہ $0.062 ہے۔ یہ پانچ گنا فرق تقریباً مکمل طور پر آؤٹ پٹ سائیڈ سے آتا ہے، اور یہی وہ جگہ ہے جہاں سستا ماڈل آپ کی سب سے زیادہ بچت کرتا ہے۔

آخری کالم وہی کام Batch API کے ذریعے دکھاتا ہے، جو ان پٹ اور آؤٹ پٹ پر 50% رعایت دیتا ہے۔ Opus 5 کی قیمت کم ہو کر $0.155 فی ڈرافٹ رہ جاتی ہے۔ Batch نتائج فوری کے بجائے 24 گھنٹوں کے اندر فراہم کرتا ہے، لہذا یہ رات بھر میں رپورٹ جنریشن اور بلک کلاسیفیکیشن کے لیے موزوں ہے۔ یہ کسی ایسے کام کے لیے موزوں نہیں ہے جس کے لیے کوئی شخص انتظار کر رہا ہو۔

ماڈل روٹنگ یہاں اس طرح فائدہ دیتی ہے جیسا کہ ایجنٹ سٹیپ پر کبھی نہیں ہوتا۔ اگر کام کا تفصیلی حصہ مکینیکل نوعیت کا ہو، جیسے ٹیکسٹ کی ری فارمیٹنگ یا کسی ایسے آؤٹ لائن کو پھیلانا جسے آپ پہلے ہی منظور کر چکے ہوں، تو سستا ماڈل وہ ٹوکن پانچ گنا کم قیمت پر تیار کر دیتا ہے۔ Opus، Sonnet اور Haiku کے درمیان انتخاب اس بات کا احاطہ کرتا ہے کہ معیار کی حد اصل میں کہاں واقع ہے۔

صرف ان پٹ پر کیشنگ ڈسکاؤنٹس

Prompt caching آپ کے پرامپٹ کے ایک ابتدائی حصے کو سرور پر محفوظ کر لیتی ہے اور اسے دوبارہ پڑھنے کے لیے ان پٹ ریٹ کا ایک چھوٹا حصہ وصول کرتی ہے۔ اگست 2026 تک، 5 منٹ کی کیش لکھنے کے لیے ملٹی پلائر بنیادی ان پٹ ریٹ کا 1.25 گنا، 1 گھنٹے کی کیش لکھنے کے لیے 2 گنا، اور ہٹ (hit) کو پڑھنے کے لیے 0.1 گنا ہے۔

آؤٹ پٹ اس سودے میں شامل نہیں ہے۔ کوئی کیشڈ آؤٹ پٹ نہیں ہوتی۔ ماڈل جو بھی ٹوکن لکھتا ہے، اس کا پورا آؤٹ پٹ ریٹ ہر بار وصول کیا جاتا ہے، چاہے پرامپٹ کا کتنا ہی حصہ کیش ہٹ کے طور پر واپس کیوں نہ آیا ہو۔

Opus 5 پر وہی ایجنٹ سٹیپ لیں، جس میں 60,000 ان پٹ ٹوکنز میں سے 55,000 ٹوکنز وارم کیش سے فراہم کیے گئے ہیں۔

[
  {
    "label": "No cache",
    "input_cost": 0.3,
    "output_cost": 0.02,
    "total_cost": 0.32
  },
  {
    "label": "55k prefix cache read",
    "input_cost": 0.0525,
    "output_cost": 0.02,
    "total_cost": 0.0725
  }
]

کال کی قیمت $0.32 سے کم ہو کر $0.0725 پر آ جاتی ہے۔ آؤٹ پٹ لائن میں کوئی تبدیلی نہیں آتی: پہلے $0.02 تھی، اور بعد میں بھی $0.02 ہے۔ کیشنگ بل کو کم کرتی ہے اور اس کی ساخت کو تبدیل کرتی ہے۔ اس کال میں آؤٹ پٹ 6.25% تھی۔ اب یہ اس کا ایک چوتھائی سے زیادہ حصہ ہے، جس سے یہ بدل جاتا ہے کہ اگلا کون سا اقدام کرنا زیادہ فائدہ مند ہے۔

پہلی کال رائٹ (write) کی قیمت ادا کرتی ہے۔ 5 منٹ کی کیش رائٹ کی قیمت بنیادی ان پٹ کا 1.25 گنا ہے، لہذا یہ ایک ہی ہٹ کے بعد اپنی قیمت پوری کر لیتی ہے۔ 1 گھنٹے کی رائٹ کی قیمت 2 گنا ہے، لہذا اسے دو ہٹس کی ضرورت ہوتی ہے۔ رائٹ اور ریڈ ملٹی پلائرز، اور جہاں کیشنگ کا فائدہ ختم ہوتا ہے اس حساب کتاب کی تفصیل بیان کرتا ہے۔

چار کنٹرول لیورز

1. max_tokens کو ماڈل کی زیادہ سے زیادہ حد پر نہیں، بلکہ اپنی p95 آؤٹ پٹ لمبائی پر سیٹ کریں۔
2. طویل مراحل کو سستے ماڈل کی طرف بھیجیں۔
3. ہر اس کام کو بیچ (batch) کریں جس کا فوری انتظار نہ ہو۔
4. ان ہدایات کو حذف کریں جو جوابات کو غیر ضروری طور پر لمبا کرتی ہیں۔

max_tokens ایک سخت حد ہے، اور اسے زیادہ رکھنے سے خود بخود کوئی خرچ نہیں ہوتا، کیونکہ آپ سے تیار کردہ ٹوکنز کا معاوضہ لیا جاتا ہے، نہ کہ حد کا۔ ایک بڑی حد رکھنے کا فائدہ یہ ہے کہ یہ غلط جواب کی صورت میں رکاوٹ نہیں بنتی۔ اپنے لاگز سے output_tokens کی تقسیم نکالیں، حد کو 95ویں پرسنٹائل سے تھوڑا اوپر سیٹ کریں، اور stop_reason: "max_tokens" کو کوڈ میں جواب جاری رکھ کر یا دوبارہ کوشش کر کے سنبھالیں۔ آپ کی طرف سے پکڑی گئی ٹرنکیشن (truncation) اس 4,000 ٹوکن کی فضول گوئی سے سستی پڑتی ہے جس کے لیے آپ ادائیگی کرتے ہیں اور پھر اسے ضائع کر دیتے ہیں۔ توسیعی سوچ (extended thinking) بھی output_tokens میں آتی ہے، لہذا اس بجٹ کو بھی اسی شواہد کی بنیاد پر سیٹ کریں۔

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

بیچنگ (batching) واحد لیور ہے جو آؤٹ پٹ پر رعایت دیتا ہے۔ دونوں طرف 50 فیصد رعایت، 24 گھنٹے کے اندر نتائج، اور شیڈول پر ہونے والا کوئی بھی کام اس کے لیے اہل ہے۔

آخری لیور وہ ہے جسے لوگ نظر انداز کر دیتے ہیں۔ "تفصیلی رہیں" اور "اپنی دلیل واضح کریں" جیسے جملے ہر کال پر آپ کی آؤٹ پٹ کی لمبائی طے کر دیتے ہیں۔ ان کی جگہ اپنی مطلوبہ شکل لکھیں: "زیادہ سے زیادہ تین جملوں میں جواب دیں"، یا "صرف JSON آبجیکٹ واپس کریں، بغیر کسی تمہید کے"۔ ایک سسٹم پرامپٹ جو ہر جواب میں 300 ٹوکنز کا اضافہ کرتا ہے، وہ پرامپٹ میں موجود انہی 300 ٹوکنز کی قیمت سے پانچ گنا زیادہ مہنگا پڑتا ہے۔ ایک رننگ ایجنٹ کے اخراجات کو کنٹرول میں رکھنا مانیٹرنگ کے پہلو کا احاطہ کرتا ہے، اور آیا API یا فلیٹ سبسکرپشن آپ کے پیٹرن کے لیے سستی ہے اس بات کا فیصلہ کرنا ضروری ہے اس سے پہلے کہ آپ ٹوکن کے حساب سے خرچ کو بہتر بنانے میں ایک ہفتہ ضائع کریں۔ ایک ڈویلپر کے لیے یہ بنیادی طور پر اس بات پر منحصر ہے کہ کیا Claude Pro کے 20 ڈالر ماہانہ اور اس کے ساتھ آنے والی استعمال کی حدود اس کام کا احاطہ کرتی ہیں جو آپ بصورت دیگر میٹرڈ API پر کر رہے ہوتے۔ اگر آپ سیشن کے دوران ہی ان حدود تک پہنچ رہے ہیں، تو یہ معلوم کرنا کہ آپ کس ونڈو کا انتظار کر رہے ہیں پہلے آتا ہے، کیونکہ اس کا حل ایک چھوٹا ماڈل، ہلکا سیاق و سباق، اضافی استعمال کے کریڈٹس، یا اس کام کو میٹرڈ API پر منتقل کرنا ہے۔ اگر میٹرڈ API اس کام کے لیے سستا ذریعہ ثابت ہوتا ہے، تو چھوٹے پلان پر آنا یا اسے منسوخ کرنا آپ کے اس مہینے کو برقرار رکھتا ہے جس کی آپ ادائیگی کر چکے ہیں، لہذا سوئچ کرنے سے آپ کو کوئی اضافی نقصان نہیں ہوتا۔ اگر آپ جس پلان کا موازنہ Pro سے کر رہے ہیں وہ ChatGPT کا ہے نہ کہ میٹرڈ API کا، تو دو سبسکرپشن لیڈرز کا پہلو بہ پہلو موازنہ دکھاتا ہے کہ کوڈنگ کے کام کے لیے کون سا سستا پڑتا ہے۔ اگر یہ سوال ایک ڈویلپر کے بجائے ٹیم کے لیے پوچھا جا رہا ہے، تو نوٹ کریں کہ Claude Enterprise فی سیٹ فیس کے ساتھ انہی API ریٹس پر ٹوکنز میٹر کرتا ہے، لہذا اس صفحے پر موجود ہر لیور اس بل کے میٹرڈ حصے پر لاگو ہوتا ہے۔

FAQ

آؤٹ پٹ ٹوکنز ان پٹ ٹوکنز سے زیادہ مہنگے کیوں ہوتے ہیں؟

ان کی تخلیق میں فی ٹوکن ایکسلریٹر کا بہت زیادہ وقت صرف ہوتا ہے۔ پرامپٹ کو پورے ڈیٹا پر ایک ہی فارورڈ پاس میں پروسیس کیا جاتا ہے، لہذا ماڈل ویٹس (model weights) کو ایک بار پڑھنے سے ہزاروں ٹوکنز کور ہو جاتے ہیں اور ہارڈویئر کی کارکردگی ضرب کی رفتار (multiply throughput) تک محدود رہتی ہے۔ اس کے برعکس، جواب ایک وقت میں ایک ٹوکن کر کے تخلیق ہوتا ہے، اور ہر ٹوکن کو اپنے الگ فارورڈ پاس کی ضرورت ہوتی ہے جو دوبارہ پورے ماڈل ویٹس کو پڑھتا ہے، جس کی وجہ سے ہارڈویئر میموری بینڈوڈتھ (memory bandwidth) تک محدود ہو جاتا ہے۔ Anthropic اپنے موجودہ پورے کیٹلاگ میں آؤٹ پٹ کی قیمت ان پٹ سے پانچ گنا زیادہ رکھتا ہے، جس میں Haiku 4.5 سے لے کر Fable 5 تک شامل ہیں۔

کیا پرامپٹ کیشنگ (prompt caching) آؤٹ پٹ ٹوکنز کو سستا بناتی ہے؟

نہیں۔ پرامپٹ کیشنگ صرف ان پٹ پر لاگو ہوتی ہے۔ اگست 2026 تک، کیش ریڈ (cache read) کی قیمت بنیادی ان پٹ ریٹ کا 0.1 گنا ہے، اور کیش رائٹس (cache writes) کی قیمت 5 منٹ کے دورانیے کے لیے 1.25 گنا یا 1 گھنٹے کے دورانیے کے لیے 2 گنا ہے۔ آؤٹ پٹ کا بل ہر کال پر مکمل ریٹ پر بنتا ہے، چاہے کیشنگ نے کچھ بھی کیا ہو۔ یہی وجہ ہے کہ کیشنگ آپ کے بل کے حجم کے ساتھ ساتھ اس کی ساخت کو بھی تبدیل کرتی ہے: ایک بار جب ان پٹ سائیڈ کا خرچ کم ہو جاتا ہے، تو آؤٹ پٹ وہ حصہ بن جاتا ہے جس پر توجہ دینا ضروری ہوتا ہے۔

کیا ہائی max_tokens مجھے مہنگا پڑتا ہے اگر جواب مختصر ہو؟

نہیں۔ آپ سے صرف ان ٹوکنز کا بل لیا جاتا ہے جو ماڈل درحقیقت تخلیق کرتا ہے، لہذا max_tokens ایک حد (ceiling) ہے نہ کہ ریزرویشن۔ یہ اب بھی اہم ہے، کیونکہ یہ کسی طویل اور بے قابو جواب پر واحد سخت حد ہے۔ اسے اپنے مشاہدہ کردہ output_tokens کے 95ویں پرسنٹائل سے تھوڑا اوپر سیٹ کریں، اور پھر خاموشی سے کٹے ہوئے جواب (silently truncated answer) بھیجنے کے بجائے stop_reason: "max_tokens" کو کوڈ میں ہینڈل کریں۔

میں اپنا ان پٹ ٹوکن اور آؤٹ پٹ ٹوکن کا تناسب کیسے معلوم کروں؟

ہر رسپانس کے usage آبجیکٹ سے input_tokens، output_tokens، cache_read_input_tokens اور cache_creation_input_tokens کو لاگ کریں، پھر ایک ہفتے کے کل ٹوٹل کو تقسیم کریں۔ اگر تناسب 5 ان پٹ کے مقابلے میں 1 آؤٹ پٹ سے زیادہ ہے، تو آپ کا خرچ پرامپٹ میں ہے، لہذا مستحکم حصے کو کیش کریں اور باقی کو ٹرم (trim) کریں۔ اس سے کم تناسب کی صورت میں، آپ کا خرچ جواب میں ہے، لہذا اس کی لمبائی کو محدود کریں اور ان مراحل کو جو سب سے زیادہ آؤٹ پٹ پیدا کرتے ہیں، کسی سستے ماڈل یا Batch API پر منتقل کریں۔