Claude میں 1M tokens کی قیمت کتنی ہے؟

Claude میں 1M tokens کی قیمت کتنی ہے؟

1M tokens سے مراد one million tokens ہے، اور ہر Claude API (application programming interface) کی قیمت اسی اکائی میں بیان کی جاتی ہے۔ اس کی کوئی ایک مقررہ قیمت نہیں، کیونکہ input اور output کی بلنگ مختلف rates پر ہوتی ہے اور ہر model کے لیے ان دونوں کی اپنی rates ہوتی ہیں۔ August 2026 تک، Claude Haiku 4.5 پر one million input tokens کی قیمت $1، Claude Sonnet 5 پر $2، اور Claude Opus 5 پر $5 ہے۔

Output مہنگا حصہ ہے۔ ہر موجودہ model میں output rate، input rate سے پانچ گنا ہے۔ اس لیے دونوں کے درمیان تقسیم آپ کے bill پر headline figure کے مقابلے میں زیادہ اثر ڈالتی ہے۔ جو app طویل دستاویزات بھیج کر مختصر جوابات واپس کرتی ہے، اس کا خرچ اس app سے بہت مختلف ہوگا جو مختصر prompt سے طویل جوابات تیار کرتی ہے۔

یہ صفحہ unit economics سے متعلق ہے: ایک token کی قیمت کیا ہے، اور build شروع کرنے سے پہلے bill کا اندازہ کیسے لگایا جائے۔ کام کے دوران tokens حقیقت میں کہاں استعمال ہوتے ہیں، اس کے لیے Claude Code session کے اندر tokens کہاں جاتے ہیں پڑھیں۔

1M ٹوکنز کی مقدار

ٹوکن متن کا ایک حصہ ہوتا ہے جسے ماڈل پڑھتا یا لکھتا ہے۔ Anthropic کے اندازے کے مطابق ہر 4 حروف کے لیے تقریباً 1 ٹوکن درکار ہوتا ہے، یا انگریزی کے تقریباً 0.75 الفاظ کے برابر۔ اس لیے 1M ٹوکنز تقریباً 750,000 الفاظ، یا سادہ متن کی تقریباً 4 MB مقدار کے برابر ہوتے ہیں۔

عام ان پٹس کے شائع شدہ اندازے اس حجم کو بہتر طور پر سمجھنے میں مدد دیتے ہیں۔

[
  {
    "label": "Average web page (10 kB)",
    "tokens": "2,500"
  },
  {
    "label": "Documentation page (100 kB)",
    "tokens": "25,000"
  },
  {
    "label": "Research paper PDF (500 kB)",
    "tokens": "125,000"
  }
]

ان شرحوں کے مطابق، 1M ٹوکنز تقریباً 400 اوسط ویب صفحات کو ایک مرتبہ پڑھنے، یا اسی حجم کے 8 تحقیقی مقالوں کے برابر ہیں۔ یہ درمیانے حجم کے کسی codebase پر ایک مرتبہ عمل کرنے، یا ایک شخص کے لیے ہلکے چیٹ استعمال کے 1 ماہ کے برابر بھی ہیں۔

ان تمام اعداد کو صرف اندازہ سمجھیں۔ Code، JSON اور انگریزی کے علاوہ دیگر زبانوں کے متن میں ایک ٹوکن کے اندر کم الفاظ آتے ہیں، اس لیے 0.75 کا تناسب زیادہ امید پرستانہ حد ہے۔ ایک اور چیز تعداد کو تبدیل کرتی ہے: Claude Opus 4.7 اور اس کے بعد کے ماڈلز، جن میں Opus 5 اور Sonnet 5 شامل ہیں، نیا tokenizer استعمال کرتے ہیں۔ یہ tokenizer اسی متن کے لیے Sonnet 4.6 اور اس سے پہلے کے ماڈلز کے مقابلے میں تقریباً 30 فیصد زیادہ ٹوکنز بناتا ہے۔ Claude Haiku 4.5 پرانا tokenizer استعمال کرتا ہے۔ اس لیے Haiku 4.5 پر ناپی گئی تعداد، اسی input کے لیے Sonnet 5 کی تعداد سے کم ہوگی۔ اس کا مطلب ہے کہ اس حد کے دونوں طرف فی ملین قیمت کا براہِ راست موازنہ منصفانہ نہیں ہے۔ فیصلہ کرنے سے پہلے اسی prompt کو دونوں ماڈلز کے مقابلے میں شمار کریں۔

Claude فی 1 ملین ٹوکن کتنی قیمت لیتا ہے

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

Claude Sonnet 5 کے لیے 31 August 2026 تک تعارفی قیمت لاگو ہے: input کے لیے $2 اور output کے لیے $10۔ 1 September 2026 سے معیاری نرخ لاگو ہوگا: input کے لیے $3 اور output کے لیے $15۔ Claude Opus 5 کی قیمت $5 اور $25 ہے۔

نرخ تبدیل ہو سکتے ہیں۔ اس صفحے پر موجود ہر عدد کو August 2026 کی تاریخ والا عملی نمونہ سمجھیں، اور بجٹ کی منظوری دینے سے پہلے سرکاری قیمتوں کے صفحے پر موجود تازہ اعداد کی تصدیق کریں۔

Context length نرخ کو تبدیل نہیں کرتی۔ Claude 4.6 اور اس کے بعد کے ورژنز میں مکمل 1M token context window کی بلنگ معیاری قیمت کے مطابق ہوتی ہے، اس لیے 900,000 token کی request کی فی token قیمت 9,000 token کی request جیسی ہی ہوتی ہے۔ طویل prompt کی قیمت زیادہ ہوتی ہے کیونکہ اس میں زیادہ tokens ہوتے ہیں؛ طویل context کے لیے کوئی الگ نرخ لاگو نہیں ہوتا۔

قیمت میں تبدیلی کے بعد بھی درست رہنے والی حساب کاری

ہر بل میں دو ضربیں اور ایک جمع شامل ہوتی ہے۔

cost = (input_tokens  / 1,000,000) * input_rate
     + (output_tokens / 1,000,000) * output_rate

اسے قابلِ اجرا code کی صورت میں لکھیں:

INPUT_RATE = 2.00    # USD per million input tokens, Sonnet 5, August 2026
OUTPUT_RATE = 10.00  # USD per million output tokens

def cost(input_tokens, output_tokens):
    return (input_tokens * INPUT_RATE + output_tokens * OUTPUT_RATE) / 1_000_000

print(f"{cost(4300, 400):.4f}")

یہ 0.0126 دکھاتا ہے۔ ایسی request جس میں 4,300 input tokens بھیجے جائیں اور 400 output tokens واپس ملیں، Sonnet 5 پر تقریباً 1.3 cents کی لاگت آتی ہے۔ دونوں rates کو اپنے code میں ایک ہی جگہ رکھیں۔ قیمت تبدیل ہونے پر آپ صرف دو lines میں ترمیم کریں گے، اور آپ کے system میں ہر estimate اسی کے مطابق تبدیل ہو جائے گا۔

ایک حقیقی ایپ کے لیے عملی تخمینہ

ایک support assistant لیں۔ اس کا system prompt اور product documentation مجموعی طور پر 4,000 tokens پر مشتمل ہیں، اور یہ ہر درخواست کے ساتھ بھیجے جاتے ہیں، کیونکہ Messages API stateless ہے اور model کو calls کے درمیان کچھ یاد نہیں رہتا۔ صارف کا سوال تقریباً 300 tokens کا اضافہ کرتا ہے۔ جواب تقریباً 400 tokens پر مشتمل ہوتا ہے۔ اس طرح ہر درخواست میں 4,300 input اور 400 output شامل ہوتے ہیں۔

ایک million input tokens اس نوعیت کی تقریباً 232 requests کے لیے کافی ہوتے ہیں۔ روزانہ 1,000 requests پر ایپ روزانہ 4.3 million input tokens استعمال کرتی ہے، اس لیے "1M tokens" کا مطلب چھ گھنٹے سے بھی کم network traffic ہے۔

[
  {
    "label": "Opus 5, list rates",
    "cost_per_1k_usd": "31.50"
  },
  {
    "label": "Sonnet 5, list rates",
    "cost_per_1k_usd": "12.60"
  },
  {
    "label": "Sonnet 5, Batch API",
    "cost_per_1k_usd": "6.30"
  },
  {
    "label": "Haiku 4.5, list rates",
    "cost_per_1k_usd": "6.30"
  },
  {
    "label": "Sonnet 5, warm prompt cache",
    "cost_per_1k_usd": "5.40"
  }
]

Claude Opus 5 پر اس traffic کی لاگت 1,000 requests کے لیے $31.50 ہے۔ Sonnet 5 پر یہ لاگت $12.60 ہے۔ Claude Haiku 4.5 پر منتقل ہونے سے یہ لاگت $6.30 ہو جاتی ہے، اور Sonnet 5 پر warm prompt cache استعمال کرنے سے لاگت مزید کم ہو کر $5.40 رہتی ہے۔

ایک ماہ کے traffic کے لیے اس رقم کو 30 سے ضرب دیں۔ list rates پر Sonnet 5 کی لاگت تقریباً $378 ماہانہ ہے۔ اسی ایپ کی warm cache کے ساتھ لاگت تقریباً $162 ماہانہ ہے۔ اس volume پر آپ کا model انتخاب اور caching کا فیصلہ، دونوں، اس شرح سے زیادہ اہم ہیں جس پر آپ بات چیت کے ذریعے رعایت حاصل کریں گے۔ کون سا model چلانا ہے، یہ الگ سوال ہے۔ جو کم ترین لاگت والا model آپ کی evaluations میں کامیاب ہو، وہی بہتر انتخاب ہے: Opus، Sonnet اور Haiku کے درمیان انتخاب میں اسے درست طریقے سے جانچنے کا طریقہ بیان کیا گیا ہے۔

پرامپٹ کیشنگ دہرائے گئے حصے کی لاگت کم کرتی ہے

وہ 4,000 ٹوکن کا سابقہ ہر درخواست میں یکساں ہے، اور آپ ہر بار اس کے لیے مکمل input قیمت ادا کرتے ہیں۔ پرامپٹ کیشنگ، پراسیس کیے گئے سابقے کو محفوظ کرتی ہے اور اسے دوبارہ استعمال کرنے پر کم شرح وصول کرتی ہے۔

کیش پڑھنے کی لاگت base input rate کا 0.1 گنا ہے۔ 5 منٹ کی مدت کے لیے cache لکھنے کی لاگت base کی 1.25 گنا، یا 1 گھنٹے کی مدت کے لیے base کی 2 گنا ہے۔ اس لیے 5 منٹ کی کیش ایک read کے بعد اپنی لاگت پوری کر لیتی ہے، کیونکہ لکھنے کی اضافی لاگت 0.25 ہے جبکہ ہر read سے 0.9 کی بچت ہوتی ہے۔ 1 گھنٹے کی کیش کو break-even ہونے کے لیے 2 reads درکار ہوتے ہیں۔

اسے فعال کرنے کا آسان ترین طریقہ ایک واحد top-level field ہے:

curl https://api.anthropic.com/v1/messages \
  -H "content-type: application/json" \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-5",
    "max_tokens": 1024,
    "cache_control": {"type": "ephemeral"},
    "system": "You are a helpful assistant.",
    "messages": [
      {"role": "user", "content": "What are the key themes in Pride and Prejudice?"}
    ]
  }'

اس کے بعد واپس آنے والا usage block پڑھیں:

{
  "usage": {
    "cache_creation_input_tokens": 5120,
    "cache_read_input_tokens": 1800,
    "input_tokens": 50,
    "output_tokens": 503
  }
}

ان تین input counters پر 3 مختلف rates لاگو ہوتی ہیں، اور ان کا مجموعہ آپ کا حقیقی input volume ہے: total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens۔ ایسا cost estimate جو صرف input_tokens پڑھتا ہے، caching فعال ہونے کے بعد بہت غلط ہوگا۔

2 چیزیں کیش کو فائدہ مند بننے سے روکتی ہیں، اور دونوں خاموشی سے ناکام ہوتی ہیں۔

سابقہ byte-identical ہونا چاہیے۔ Cache lookup، prefix match استعمال کرتا ہے، اس لیے system prompt کے آغاز میں timestamp یا صارف کا نام ہر درخواست میں اسے تبدیل کر دیتا ہے۔ اس صورت میں آپ ہر بار base input کی 1.25 گنا لاگت ادا کرتے ہیں اور کبھی cache read نہیں ہوتا۔ علامت یہ ہے کہ cache_creation_input_tokens بلند رہتا ہے جبکہ cache_read_input_tokens، 0 رہتا ہے۔ cache_control کو اس آخری block پر رکھیں جس کا content تمام requests میں یکساں ہو، اور مختلف ہونے والی ہر چیز اس کے بعد رکھیں۔ اپنی tools definitions تبدیل کرنے سے ان کے نیچے موجود پوری cache invalid ہو جاتی ہے، کیونکہ invalidation، tools، پھر system، پھر messages کی ترتیب کے مطابق نیچے کی طرف چلتی ہے۔

سابقہ کافی طویل ہونا چاہیے۔ قابلِ کیش کم از کم لمبائی Opus 5 پر 512 tokens، Sonnet 5 پر 1,024 اور Haiku 4.5 پر 4,096 ہے۔ اس سے چھوٹا prompt cache نہیں ہوتا اور کوئی error واپس نہیں آتا۔ اوپر کی مثال میں موجود 4,000 ٹوکن کا سابقہ Sonnet 5 پر cache ہوتا ہے، لیکن Haiku 4.5 پر cache نہیں ہوتا، کیونکہ 4,000 اس model کی مقررہ کم از کم حد سے کم ہے۔ جب دونوں counters کی قدر 0 ہو، تو کچھ بھی cache نہیں ہوا۔

بیچ پروسیسنگ شرح آدھی کر دیتی ہے

Batch API درخواستوں کو غیر ہم وقت طریقے سے پروسیس کرتا ہے اور input اور output، دونوں پر 50 فیصد رعایت دیتا ہے۔ اوپر دی گئی مثال میں اس سے 1,000 درخواستوں کی لاگت $12.60 سے کم ہو کر $6.30 رہ جاتی ہے۔ یہ رعایت prompt caching کے ساتھ بھی جمع ہوتی ہے، اس لیے bulk کام چلانے کا سب سے کم خرچ طریقہ cached batch job ہے۔

اس کے بدلے latency میں اضافہ ہوتا ہے، اس لیے Batch API ان کاموں کے لیے موزوں نہیں جن کے نتیجے کا کوئی شخص بیٹھ کر انتظار کر رہا ہو۔ یہ رات بھر کی classification اور دستاویزات کے backfill کے لیے موزوں ہے۔

ایک گفتگو کے اندر چیٹ کی لاگت کیوں بڑھتی ہے

چونکہ API کوئی حالت محفوظ نہیں رکھتی، اس لیے آپ کا client ہر turn پر پوری گفتگو دوبارہ بھیجتا ہے۔ اسی وجہ سے ایک چیٹ کے اندر token کا استعمال اس کی طوالت کے مربع کے ساتھ بڑھتا ہے، سیدھی لکیر میں نہیں۔

فرض کریں کہ ہر turn میں اوسطاً 500 tokens ہوں۔ Turn 1 میں 500 input tokens بھیجے جاتے ہیں۔ Turn 2 میں 1,000۔ Turn 20 میں 10,000۔ اسے n(n+1)/2 کے ساتھ جمع کریں تو 20 turns کی گفتگو میں تقریباً 105,000 input tokens بھیجے جا چکے ہوں گے، جبکہ transcript خود صرف 10,000 tokens پر مشتمل ہوگا۔

اسی لیے چیٹ feature کی لاگت اس کے transcript سے ظاہر ہونے والی لاگت سے زیادہ ہوتی ہے۔ اسی وجہ سے مستحکم prefix کو cache کرنا یا پرانے turns کا خلاصہ بنانا طویل threads میں اپنی لاگت پوری کر دیتا ہے۔ جو agent tool calls کے ذریعے loop کرتا ہے، اس میں بھی یہی صورت ہوتی ہے، بلکہ زیادہ خراب: ہر tool result history میں برقرار رہتا ہے اور بعد کے ہر turn پر دوبارہ بھیجا جاتا ہے۔ اپنے زیرِ انتظام agent کے لیے اخراجات کی سخت حد مقرر کرنا یہاں سب سے زیادہ اہم ہے، کیونکہ یہ اضافہ خودکار ہوتا ہے اور کوئی اس کی نگرانی نہیں کر رہا ہوتا۔

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

الفاظ کی تعداد سے ٹوکنز کی تعداد اخذ کرنا بند کریں۔ API آپ کے لیے یہ تعداد بلا معاوضہ گنتی ہے، اور اس کے لیے message creation سے الگ rate limit استعمال ہوتی ہے۔

curl https://api.anthropic.com/v1/messages/count_tokens \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "content-type: application/json" \
  -H "anthropic-version: 2023-06-01" \
  -d '{
    "model": "claude-opus-5",
    "system": "You are a scientist",
    "messages": [{
      "role": "user",
      "content": "Hello, Claude"
    }]
  }'

جواب میں ایک field شامل ہوتی ہے:

{ "input_tokens": 14 }

اس میں اپنا حقیقی system prompt اور tool definitions، نیز ایک نمائندہ user message شامل کریں، پھر اس عدد کو اوپر دیے گئے cost function میں استعمال کریں۔ یہ endpoint وہی body قبول کرتا ہے جو message request قبول کرتی ہے، اس لیے images اور PDFs بھی درست طور پر شمار ہوتے ہیں۔ دو باتیں اہم ہیں۔ یہ count ایک تخمینہ ہے اور billed figure سے معمولی طور پر مختلف ہو سکتا ہے۔ اس کی پیمائش اس model کے tokenizer سے ہوتی ہے جسے آپ بھیجتے ہیں، اس لیے وہی model بھیجیں جسے آپ حقیقت میں چلائیں گے۔

Output tokens کو پہلے سے شمار نہیں کیا جا سکتا، کیونکہ وہ ابھی موجود نہیں ہوتے۔ max_tokens کے ذریعے ان کی حد مقرر کریں، پھر live traffic پر usage.output_tokens سے حقیقی distribution کی پیمائش کریں۔

بل میں مزید کیا شامل ہوتا ہے

بل کا زیادہ تر حصہ tokens پر مشتمل ہوتا ہے۔ چند اشیا tokens نہیں ہوتیں، لیکن یہ صارفین کے لیے غیر متوقع ہوتی ہیں۔

• ہر request پر tool definitions، input tokens بن جاتی ہیں۔ صرف tool use system prompt ہی Opus 5 پر آپ کی اپنی schemas شامل کرنے سے پہلے 286 سے 406 tokens بڑھا دیتا ہے۔ دس تفصیلی tool descriptions ایک چھوٹے prompt کا حجم دوگنا کر سکتی ہیں۔
• Web search کے لیے ہر 1,000 searches پر $10 وصول کیے جاتے ہیں۔ اس کے علاوہ results کے context میں شامل ہونے پر استعمال ہونے والے tokens کی لاگت بھی لاگو ہوتی ہے۔
• Web fetch کی اپنی کوئی فیس نہیں، لیکن fetch کیا گیا page، input tokens بن جاتا ہے۔ 100 kB کا documentation page تقریباً 25,000 tokens کے برابر ہوتا ہے۔
• Claude 4.6 اور اس کے بعد کے ورژنز پر inference_geo کے ساتھ صرف US میں inference طلب کرنے سے ہر token category پر 1.1 multiplier لاگو ہوتا ہے، جس میں cache reads اور cache writes بھی شامل ہیں۔

API خریدنا مجموعی طور پر درست فیصلہ ہے یا نہیں، اس کا انحصار آپ کے استعمال کے حجم پر ہے۔ استعمال کی ایک خاص سطح سے کم پر flat monthly plan واضح طور پر زیادہ فائدہ مند ہوتا ہے، اور Claude subscription کے مقابلے میں API حقیقی اعداد کے ساتھ یہ موازنہ کرتا ہے۔

FAQ

Claude میں 1M tokens کی قیمت کتنی ہے؟

یہ model پر منحصر ہے، اور اس بات پر بھی کہ tokens input ہیں یا output۔ August 2026 تک Claude Haiku 4.5 پر one million input tokens کی قیمت $1، introductory pricing کے تحت Claude Sonnet 5 پر $2، اور Claude Opus 5 پر $5 ہے۔ ان میں سے ہر model پر output کی قیمت input rate سے پانچ گنا ہے۔ 1 September 2026 کو Sonnet 5 کی قیمت input کے لیے $3 اور output کے لیے $15 ہو جائے گی۔ Rates تبدیل ہوتے رہتے ہیں، اس لیے budget میں کوئی رقم شامل کرنے سے پہلے official pricing page پر ان کی تصدیق کریں۔

کیا 1M tokens، 1M words کے برابر ہیں؟

نہیں۔ ایک token میں English کے تقریباً 4 characters، یا تقریباً 0.75 words ہوتے ہیں۔ اس لیے one million tokens تقریباً 750,000 words کے برابر ہوتے ہیں۔ یہ نسبت صرف ایک عمومی رہنما ہے۔ Code، JSON اور English کے علاوہ دیگر languages میں ہر word کے لیے زیادہ tokens استعمال ہوتے ہیں۔ Claude Opus 4.7 اور اس کے بعد کے models ایک نیا tokenizer بھی استعمال کرتے ہیں، جو یکساں text کے لیے Claude Sonnet 4.6 اور اس سے پہلے کے models کے مقابلے میں تقریباً 30 percent زیادہ tokens بناتا ہے۔ اس لیے مختلف model generations کے درمیان counts قابلِ منتقلی نہیں ہوتے۔ مفت /v1/messages/count_tokens endpoint استعمال کرکے پیمائش کریں اور وہ model دیں جسے آپ چلانے کا ارادہ رکھتے ہیں۔

کیا prompt caching ہمیشہ رقم بچاتی ہے؟

نہیں۔ 5 minute کی cache write کی قیمت base input rate سے 1.25 گنا ہوتی ہے۔ اس لیے جو prefix لکھا جائے اور کبھی پڑھا نہ جائے، اسے عام طریقے سے بھیجنے کے مقابلے میں 25 percent زیادہ لاگت آتی ہے۔ پہلی read سے ہی اس کی لاگت پوری ہو جاتی ہے۔ یہ دو طریقوں سے ناکام ہوتی ہے، اور دونوں صورتوں میں خاموشی سے۔ اگر requests کے درمیان cached prefix تبدیل ہو جائے تو lookup کبھی match نہیں ہوتا، کیونکہ یہ exact prefix match ہوتا ہے۔ اگر prefix model کی minimum cacheable length سے مختصر ہو، جو Sonnet 5 پر 1,024 tokens اور Haiku 4.5 پر 4,096 ہے، تو کچھ بھی cache نہیں ہوتا اور کوئی error واپس نہیں آتا۔ جب cache_creation_input_tokens اور cache_read_input_tokens دونوں 0 پڑھیں، تو cache کوئی کام نہیں کر رہی۔

میرے bill میں message count کے مقابلے میں زیادہ تیزی سے اضافہ کیوں ہوا؟

کیونکہ ہر turn پر پوری conversation دوبارہ بھیجی جاتی ہے۔ Messages API کوئی state محفوظ نہیں کرتی، اس لیے chat کے turn 20 میں پہلے کے تمام 19 turns دوبارہ input کے طور پر شامل ہوتے ہیں۔ اگر ہر turn میں اوسطاً 500 tokens ہوں، تو 20 turn کی conversation تقریباً 105,000 input tokens بھیجتی ہے، جبکہ transcript کی لمبائی صرف 10,000 tokens ہوتی ہے۔ Agent loops بھی اسی طرح کام کرتے ہیں، کیونکہ ہر tool result history میں برقرار رہتا ہے۔ Stable prefix کو cache کریں، یا پرانے turns کا خلاصہ بنا کر انہیں request سے خارج کریں۔