Claude میں input اور output tokens کی لاگت کا فرق

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

موجودہ catalogue میں Claude کے ہر model پر output tokens کی لاگت input tokens سے پانچ گنا ہے۔ اس کی وجہ computation کی نوعیت ہے۔ Prompt پڑھنے کے لیے model پر ایک pass ہوتا ہے۔ جواب لکھنے کے لیے ہر token پر ایک pass ہوتا ہے، اور ہر pass کو اس سے پہلے والے pass کے مکمل ہونے کا انتظار کرنا پڑتا ہے۔

Price list کی ہر row میں یہ ratio یکساں ہے، اس لیے آپ جو model منتخب کرتے ہیں وہ آپ کے bill میں output کے حصے کو تبدیل نہیں کرتا۔ اس کا فیصلہ آپ کے workload کی نوعیت کرتی ہے۔ ایسا agent step جو 60,000 tokens پڑھ کر 800 tokens میں جواب دے، اس میں output کی لاگت تقریباً نہ ہونے کے برابر ہوتی ہے۔ ایسا drafting job جو 2,000 tokens پڑھ کر 12,000 tokens لکھے، اس میں input کی لاگت تقریباً نہ ہونے کے برابر ہوتی ہے۔ ذیل میں دونوں صورتوں کا حساب Anthropic کے شائع کردہ August 2026 کے rates کے مطابق دیا گیا ہے۔

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

Inference server کسی request کو دو مراحل میں handle کرتا ہے، اور دونوں کی لاگت بہت مختلف ہوتی ہے۔ Prefill prompt کو پڑھتا ہے۔ Decoding جواب لکھتا ہے۔

Prefill پورے prompt کو ایک ہی بار میں handle کرتا ہے۔ ہر prompt token اسی forward pass میں network میں داخل ہوتا ہے، اس لیے attention اور feed-forward کا کام چند بڑی matrix multiplications میں تبدیل ہو جاتا ہے، جن میں ایک وقت میں ہزاروں tokens شامل ہوتے ہیں۔ Model weights کو memory سے ایک بار پڑھنا پورے prompt کے لیے کافی ہوتا ہے۔ Accelerator کی matrix units مسلسل مصروف رہتی ہیں۔ اسی لیے prefill compute-bound ہوتا ہے: حد اس رفتار سے متعین ہوتی ہے جس سے chip ضرب دے سکتی ہے۔

Decoding اس طرح کام نہیں کر سکتا، کیونکہ token 2 کا انحصار token 1 پر ہوتا ہے۔ Model نے ابھی جو token تیار کیا ہے، وہ اگلے step کے input کا حصہ بن جاتا ہے، اس لیے یہ steps بیک وقت نہیں چل سکتے۔ ہر output token کے لیے الگ forward pass ہوتا ہے، اور ان میں سے ہر pass high-bandwidth memory سے model weights کا پورا مجموعہ پڑھ کر ایک token تیار کرتا ہے۔ اسی لیے decoding memory-bound ہوتا ہے: حد weights منتقل کرنے کی رفتار سے متعین ہوتی ہے، نہ کہ انہیں ضرب دینے کی رفتار سے۔ Prefill کے دوران پورے prompt کو handle کرنے والی یہی weight traffic decoding کے دوران صرف ایک token تیار کرتی ہے۔

Serving systems batching کے ذریعے اس مسئلے کا ازالہ کرتے ہیں۔ متعدد requests ایک ساتھ decode ہوتی ہیں، اس لیے weights کو ایک بار پڑھنے سے batch میں شامل ہر request کے لیے ایک token تیار ہو جاتا ہے۔ اسی وجہ سے decoding قابلِ عمل رہتا ہے۔ حد پھر memory ہی ہوتی ہے۔ ہر زیرِ عمل request ایک KV cache رکھتی ہے، یعنی key/value cache جو اب تک کے ہر token کے لیے محفوظ attention state ہے۔ ہر تیار ہونے والے token کے ساتھ یہ cache بڑھتا ہے، اور جب یہ accelerator کو بھر دیتا ہے تو batch مزید بڑا نہیں کیا جا سکتا۔

اس سے کوئی exact number حاصل نہیں ہوتا، اور 5x کو hardware کا ناپا ہوا ratio نہیں سمجھنا چاہیے۔ یہ Anthropic کی مقرر کردہ قیمت ہے، جس پر اس عدم توازن کا اثر ہے۔ آپ خود جس چیز کی تصدیق کر سکتے ہیں وہ اس کی سمت ہے، اور اس میں تقریباً ایک منٹ لگتا ہے۔

خود input اور output کا gap ناپیں

کسی بھی Ubuntu باکس پر tools install کریں:

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

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

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 ہر line کے شروع میں command شروع ہونے کے بعد گزرنے والے seconds درج کرتا ہے۔ اس output سے دو چیزیں پڑھنا مفید ہے۔ پہلی content_block_delta line آپ کا time to first token ہے، اور پورا prefill اسی کے اندر مکمل ہوا۔ اس کے بعد آنے والی ہر line decoding کا ایک چھوٹا step ہے، اور stamps بڑھتے رہتے ہیں، یہاں تک کہ message_stop آ جائے۔

اب شکل الٹ دیں۔ prompt میں ایک طویل document رکھیں اور جواب کو چند tokens تک محدود کریں۔

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'

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

ہر non-streaming response کے آخر میں وہ numbers شامل ہوتے ہیں جن کی بنیاد پر آپ سے billing کی جاتی ہے۔

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

ہر request کے لیے چاروں fields log کریں۔ output_tokens میں extended thinking بھی شامل ہے، اس لیے جو model جواب دینے سے پہلے سوچتا ہے، وہ اس thinking کی billing output rate پر کرتا ہے۔ Prompt بھیجنے سے پہلے اس کی قیمت معلوم کرنے کے لیے POST /v1/messages/count_tokens وہی request body قبول کرتا ہے، model چلائے بغیر {"input_tokens": N} واپس کرتا ہے، اور یہ مفت ہے۔ API کا یہ واحد مفت حصہ نہیں ہے، اور Claude API کے کن حصوں کی آپ سے کبھی billing نہیں کی جاتی پہلے project کا budget بنانے سے قبل اسے دیکھنا مفید ہے۔

اگست 2026 تک فی ملین tokens 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
  }
]

آخری column، output کو input پر تقسیم کرنے کا نتیجہ ہے، اور ہر row میں یہ 5 ہے۔ Haiku 4.5 کے لیے input کی قیمت $1 اور output کی قیمت $5 ہے۔ Opus 5 کے لیے یہ قیمتیں بالترتیب $5 اور $25 ہیں۔ سب سے مہنگا ماڈل Fable 5، input کے لیے $10 اور output کے لیے $50 لیتا ہے، اور Fable 5 کی یہ قیمتیں آپ کو کیا فراہم کرتی ہیں اسے نظرانداز کرنے سے پہلے پڑھنا مفید ہے۔ اس range میں اوپر جانے سے دونوں جانب ایک ہی factor سے اضافہ ہوتا ہے، اس لیے کل لاگت بدلتی ہے، لیکن input اور output کا تناسب بالکل وہی رہتا ہے۔

Sonnet 5 دو مرتبہ دکھائی دیتا ہے کیونکہ اس کی introductory rate ختم ہو جاتی ہے۔ 31 August 2026 تک اس کی input قیمت $2 اور output قیمت $10 ہے۔ 1 September 2026 سے $3 input اور $15 output کی standard rate لاگو ہوگی، جو دونوں جانب 50% زیادہ ہے۔ ذیل کی تمام worked examples میں August rate استعمال کی گئی ہے۔

Rates تبدیل ہوتی رہتی ہیں، اس لیے انہیں چیک کرنے کے لیے اس page پر انحصار نہ کریں۔ claude.com/pricing اصل ماخذ ہے۔ قیمت تبدیل ہونے کے بعد بھی طریقہ کار برقرار رہتا ہے۔

Price list ایک اہم بات نہیں دکھاتی۔ Anthropic کی documentation کے مطابق Claude 4.7 اور اس کے بعد کے models ایک نیا tokenizer استعمال کرتے ہیں، جو Sonnet 4.6 اور اس سے پہلے کے models کے tokenizer کے مقابلے میں ایک ہی text کے لیے تقریباً 30% زیادہ tokens بناتا ہے۔ صرف فی ملین tokens قیمت کا موازنہ کرنے سے نیا model بہتر دکھائی دے گا، کیونکہ اسی document میں اس کے لیے tokens کی تعداد زیادہ ہوگی۔ Finished task کی لاگت کی بنیاد پر موازنہ کریں، اور اپنے حقیقی prompts کو اسی model کے خلاف شمار کریں جسے آپ استعمال کرنے کا ارادہ رکھتے ہیں۔ Providers کے درمیان بھی یہی مسئلہ موجود ہے، کیونکہ ان کے tokenizers ایک دوسرے سے اس سے بھی زیادہ مختلف ہوتے ہیں۔ اس لیے Claude اور ChatGPT دونوں پر کسی حقیقی کام کی لاگت نکالنا دو rate cards کو ساتھ رکھنے سے زیادہ مفید ہے۔ حقیقی text میں Claude کے ایک ملین tokens کی قدر بتاتا ہے کہ عملی طور پر یہ حجم کیسا دکھائی دیتا ہے۔

آپ کے بل پر output کب غالب آنا شروع ہوتا ہے؟

جب output کی قیمت input کے مقابلے میں 5 گنا ہو، تو break-even تناسب ذہن میں رکھنا آسان ہوتا ہے۔ اپنے input tokens کو I اور output tokens کو O کہیں۔ Input کی لاگت I ہے۔ Output کی لاگت 5 گنا O ہے۔ جب 5 گنا O، I سے زیادہ ہو جائے تو آپ کے کل خرچ میں output کا حصہ نصف سے بڑھ جاتا ہے۔ اس کے لیے token ratio 5 input سے 1 output ہے۔

لہٰذا اگر آپ کا prompt، reply سے 5 گنا سے زیادہ طویل ہے تو input خرچ کی بڑی مد ہے۔ اس سے کم تناسب پر output بڑی مد ہے۔

[
  {
    "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 کے تناسب پر output کل خرچ کا 4.8% ہوتا ہے، اور prompt مختصر کرنا ہی واحد قابلِ قدر کام ہوتا ہے۔ 5 سے 1 کے تناسب پر دونوں جانب کا خرچ برابر ہوتا ہے۔ 1 سے 6 کے تناسب پر output کا حصہ 96.8% ہوتا ہے اور prompt کی لاگت round-off error کے برابر رہ جاتی ہے۔ اکثر لوگ اپنے اصل تناسب کا غلط اندازہ لگاتے ہیں، اس لیے کسی بھی optimization سے پہلے اسے اپنے logs سے معلوم کریں۔

ایجنٹ workload: طویل context اندر، مختصر جواب باہر

ایجنٹ کا ایک retrieval step لیں: retrieved documents اور conversation history کے 60,000 input tokens، اور 800 token کا جواب۔ یہ 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
  }
]

ہر model پر output اس call کا 6.25% ہے، کیونکہ پورے price list میں ratio مستقل رہتا ہے۔ August rate پر یہ call Opus 5 میں $0.32، Sonnet 5 میں $0.128، اور Haiku 4.5 میں $0.064 کی ہے۔ Opus 5 پر روزانہ ایسے 200 steps کی لاگت $64 یومیہ ہے۔

یہ تقسیم دیکھنے کے بعد اصل lever واضح ہو جاتا ہے۔ جواب کو 800 tokens سے 400 tokens کرنے سے call کی لاگت تقریباً 3% کم ہوتی ہے۔ prompt سے 20,000 tokens کا پرانا context نکالنے سے لاگت تقریباً ایک تہائی کم ہوتی ہے۔ read-heavy agent میں output length محدود کرنے کی کوشش تقریباً بے فائدہ ہے۔ coding agent کے tokens اصل میں کہاں استعمال ہوتے ہیں وضاحت کرتا ہے کہ prompt میں بنیادی طور پر کیا شامل ہوتا ہے۔

ایک generation workload: مختصر prompt، طویل draft

اب تناسب بدل دیں۔ 2,000 token کا brief اور 12,000 token کا draft؛ تناسب 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
  }
]

Output اس bill کا 96.8% ہے۔ Opus 5 کی لاگت ہر draft کے لیے $0.31 ہے، جبکہ Haiku 4.5 پر یہی لاگت $0.062 ہے۔ یہ پانچ گنا فرق تقریباً مکمل طور پر output کی وجہ سے ہے، اور یہی وہ حصہ ہے جہاں سستا model سب سے زیادہ بچت دیتا ہے۔

آخری column میں یہی کام Batch API کے ذریعے دکھایا گیا ہے، جو input اور output دونوں پر 50% رعایت دیتا ہے۔ Opus 5 کی لاگت کم ہو کر ہر draft کے لیے $0.155 رہ جاتی ہے۔ Batch نتائج فوراً دینے کے بجائے 24 گھنٹوں کے اندر واپس کرتا ہے، اس لیے یہ رات بھر report generation اور bulk classification کے لیے موزوں ہے۔ یہ ایسے کسی کام کے لیے موزوں نہیں جس کے نتائج کا کوئی شخص بیٹھ کر انتظار کر رہا ہو۔

یہاں model routing agent step کے برعکس مؤثر ثابت ہوتی ہے۔ اگر کام کا تفصیلی حصہ mechanical ہو، مثلاً text کو دوبارہ format کرنا یا پہلے سے منظور شدہ outline کو expand کرنا، تو سستا model یہ tokens قیمت کے پانچویں حصے میں تیار کر دیتا ہے۔ Opus، Sonnet اور Haiku میں انتخاب میں بتایا گیا ہے کہ معیار کی حد حقیقتاً کہاں قائم ہوتی ہے۔

کیشنگ صرف input کی لاگت کم کرتی ہے، input ہی کی

Prompt caching آپ کے prompt کا ایک prefix سرور پر محفوظ کرتی ہے اور اسے دوبارہ پڑھنے کے لیے input rate کا ایک حصہ وصول کرتی ہے۔ August 2026 تک multipliers یہ ہیں: 5 minute cache لکھنے کے لیے base input rate کا 1.25x، 1 hour cache لکھنے کے لیے 2x، اور cache hit پڑھنے کے لیے 0.1x۔

Output اس رعایت میں شامل نہیں ہے۔ Cached output موجود نہیں ہوتا۔ ماڈل جتنے بھی tokens لکھتا ہے، ہر بار ان کی billing مکمل output rate پر ہوتی ہے، چاہے prompt کا کتنا ہی حصہ cache hit کے طور پر واپس آیا ہو۔

Opus 5 پر اسی agent step کو لیں، جس میں 60,000 input tokens میں سے 55,000 warm cache سے فراہم کیے گئے ہیں۔

[
  {
    "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
  }
]

یہ call $0.32 سے کم ہو کر $0.0725 رہ جاتی ہے۔ Output line میں کوئی تبدیلی نہیں آتی: پہلے $0.02، بعد میں $0.02۔ Caching bill کم کرتی ہے اور اس کی ساخت بدل دیتی ہے۔ اس call میں output کا حصہ 6.25% تھا۔ اب یہ call کے ایک چوتھائی سے زیادہ ہے، اس لیے اگلا مؤثر قدم بدل جاتا ہے۔

پہلی call میں write کی لاگت شامل ہوتی ہے۔ 5 minute cache write کی لاگت base input کی 1.25x ہوتی ہے، اس لیے ایک ہی hit کے بعد یہ اپنی لاگت پوری کر لیتی ہے۔ 1 hour write کی لاگت 2x ہوتی ہے، اس لیے اسے دو hits درکار ہوتے ہیں۔ write اور read multipliers، اور وہ مقام جہاں caching فائدہ مند نہیں رہتی میں اس حساب کی تفصیل دی گئی ہے۔

آپ کے اختیار میں چار طریقے

1. max_tokens کو ماڈل کی زیادہ سے زیادہ حد کے بجائے اپنی p95 output length پر مقرر کریں۔
2. تفصیلی مراحل کو کم لاگت والے model پر route کریں۔
3. ہر اس کام کو batch کریں جس کے نتائج کا کوئی منتظر نہ ہو۔
4. وہ instructions حذف کریں جو replies کو غیر ضروری طور پر طویل بناتی ہیں۔

max_tokens ایک سخت حد ہے۔ اسے خود زیادہ مقرر کرنے پر کوئی اضافی لاگت نہیں آتی، کیونکہ billing تیار کیے گئے tokens کے حساب سے ہوتی ہے، اس حد کے حساب سے نہیں۔ زیادہ cap صرف اس reply کی حد ہٹاتی ہے جو غلط سمت میں چلا جائے۔ اپنے logs سے output_tokens distribution نکالیں، cap کو 95th percentile سے کچھ اوپر مقرر کریں، اور stop_reason: "max_tokens" کو code میں handle کریں: response جاری رکھیں یا retry کریں۔ جس truncation کا آپ بروقت پتا لگا لیں، اس کی لاگت اس 4,000 token کی طویل ramble سے کم ہوتی ہے جس کی ادائیگی کر کے آپ اسے discard کر دیں۔ Extended thinking بھی output_tokens میں شامل ہوتی ہے، اس لیے اس budget کو بھی اسی evidence کی بنیاد پر مقرر کریں۔

Routing اس وقت مؤثر ہوتی ہے جب کسی step کا مہنگا حصہ judgement کے بجائے volume ہو۔ فیصلہ strong model پر رکھیں، اور typing کسی کم لاگت والے model کو دے دیں۔ Routed version کو پہلے اپنے evaluation set پر measure کریں، کیونکہ وہ cheap model جسے دو attempts درکار ہوں، ایک expensive attempt سے زیادہ مہنگا پڑتا ہے۔

Batching output پر discount دینے والا واحد طریقہ ہے۔ دونوں جانب 50% رعایت، results 24 گھنٹوں کے اندر، اور schedule کے مطابق چلنے والا ہر کام اس میں شامل ہوتا ہے۔

آخری طریقہ وہ ہے جسے لوگ نظرانداز کر دیتے ہیں۔ "be thorough" اور "explain your reasoning" جیسے phrases آپ کی ہر call کی output length مقرر کرتے ہیں۔ ان کی جگہ مطلوبہ format واضح کریں: "Answer in at most three sentences" یا "Return only the JSON object, with no preamble"۔ ایک system prompt جو ہر reply میں 300 tokens شامل کرے، prompt میں اسی 300 tokens کی لاگت سے پانچ گنا زیادہ پڑتا ہے۔ running agent کے اخراجات قابو میں رکھنا monitoring کے پہلو کا احاطہ کرتا ہے، اور یہ طے کرنا کہ آپ کے pattern کے لیے API یا flat subscription سستی ہے اس سے پہلے طے کر لینا چاہیے کہ آپ per-token spend کو optimize کرنے میں ایک ہفتہ صرف کریں، جبکہ subscription وہ لاگت پہلے ہی absorb کر لیتی۔ ایک developer کے لیے یہ زیادہ تر اس بات پر منحصر ہے کہ Claude Pro کے $20 ماہانہ اور اس کے ساتھ آنے والی usage limits اس کام کے لیے کافی ہیں یا نہیں جسے آپ بصورت دیگر meter کرتے۔ اگر آپ session کے دوران پہلے ہی ان limits تک پہنچ رہے ہیں تو یہ معلوم کرنا کہ آپ کس window کا انتظار کر رہے ہیں اولین ترجیح ہے، کیونکہ اس کے بعد حل smaller model، lighter context، اضافی usage credits، یا اس کام کو metered API پر منتقل کرنا ہو سکتا ہے۔ اگر metered API اس کام کے لیے سستی ثابت ہو تو چھوٹے plan پر آنا یا اسے cancel کرنا پہلے سے ادا کیے گئے مہینے کو متاثر نہیں کرتا، اس لیے تبدیلی کرتے وقت آپ کو کوئی اضافی نقصان نہیں ہوتا۔ اگر آپ جس plan کا Pro کے مقابلے میں جائزہ لے رہے ہیں وہ metered API کے بجائے ChatGPT کا plan ہے تو دونوں subscription ladders کی ساتھ ساتھ قیمتیں ظاہر کرتی ہیں کہ coding work کے لیے کون سا سستا ہے۔ اگر یہ سوال ایک developer کے بجائے team کے لیے پوچھا جا رہا ہے تو یاد رکھیں کہ Claude Enterprise فی seat fee کو انہی API rates پر metered tokens کے ساتھ جوڑتا ہے، اس لیے اس صفحے کا ہر طریقہ bill کے metered حصے پر اب بھی لاگو ہوتا ہے۔

FAQ

آؤٹ پٹ tokens کی لاگت input tokens سے زیادہ کیوں ہوتی ہے؟

انہیں تیار کرنے کے لیے فی token accelerator کا کہیں زیادہ وقت درکار ہوتا ہے۔ Prompt کو ایک ہی forward pass میں مکمل طور پر process کیا جاتا ہے، اس لیے model weights کو ایک بار پڑھنے سے ہزاروں tokens cover ہو جاتے ہیں اور hardware کی حد multiply throughput بن جاتی ہے۔ جواب ایک وقت میں ایک token تیار ہوتا ہے۔ ہر token کے لیے اپنا forward pass درکار ہوتا ہے، جس میں model weights کو دوبارہ مکمل طور پر پڑھا جاتا ہے۔ اس لیے hardware کی حد memory bandwidth بن جاتی ہے۔ Anthropic پورے موجودہ catalogue میں input کے مقابلے میں output کی قیمت 5 گنا رکھتا ہے، Haiku 4.5 سے Fable 5 تک۔

کیا prompt caching سے output tokens سستے ہو جاتے ہیں؟

نہیں۔ Prompt caching صرف input پر لاگو ہوتی ہے۔ August 2026 تک cache read کی لاگت base input rate کا 0.1x ہے، جبکہ cache writes کی لاگت 5 minute duration کے لیے 1.25x اور 1 hour duration کے لیے 2x ہے۔ ہر call پر output کی مکمل rate کے مطابق billing ہوتی ہے، cache نے کچھ بھی کیا ہو۔ اسی لیے caching آپ کے bill کی مقدار کے ساتھ اس کی ساخت بھی بدلتی ہے: جب input والا حصہ بہت کم ہو جاتا ہے تو output وہ حصہ بن جاتا ہے جس پر لاگت کم کرنے کی کوشش ہونی چاہیے۔

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

نہیں۔ آپ سے model کے واقعی تیار کردہ tokens کے لیے billing کی جاتی ہے، اس لیے max_tokens ایک حد ہے، پہلے سے مختص مقدار نہیں۔ پھر بھی یہ اہم ہے، کیونکہ یہ ایسے جواب کے لیے واحد سخت حد ہے جو بے قابو ہو کر طویل ہو جائے۔ اسے اپنے مشاہدہ شدہ output_tokens کے 95th percentile سے کچھ زیادہ مقرر کریں، پھر silently truncated جواب بھیجنے کے بجائے code میں stop_reason: "max_tokens" کو handle کریں۔

میں اپنا input سے output token ratio کیسے معلوم کروں؟

ہر response کے usage object سے input_tokens، output_tokens، cache_read_input_tokens اور cache_creation_input_tokens کو log کریں، پھر ایک ہفتے کے مجموعی اعداد کو تقسیم کریں۔ اگر input to output ratio 5 سے 1 سے زیادہ ہے تو آپ کی لاگت prompt میں ہے؛ مستحکم حصے کو cache کریں اور باقی کو مختصر کریں۔ اگر یہ اس سے کم ہے تو آپ کی لاگت جواب میں ہے؛ اس کی لمبائی محدود کریں اور وہ steps جو اس کا زیادہ حصہ تیار کرتے ہیں، کم لاگت والے model یا Batch API میں منتقل کریں۔