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

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

1M tokens سے مراد one million tokens ہے، اور یہی وہ اکائی ہے جس میں Claude API (application programming interface) models کی قیمتیں بیان کی جاتی ہیں۔ اس کی کوئی ایک مقررہ قیمت نہیں، کیونکہ input اور output کی billing مختلف rates پر ہوتی ہے، اور ہر model کے لیے rates کا اپنا جوڑا ہوتا ہے۔ Claude Haiku 5.5 کے لیے دو جوڑے ہیں: ایک 100,000 tokens تک کے prompts کے لیے، اور اس سے زیادہ prompts کے لیے زیادہ rate۔ اکتوبر 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 طویل documents بھیج کر مختصر جوابات واپس کرتی ہے، اس کا خرچ اس app سے بہت مختلف ہوگا جو مختصر prompt سے طویل جوابات تیار کرتی ہے۔

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

1M tokens کی مقدار کیا ہوتی ہے

token متن کا ایک حصہ ہوتا ہے جسے model پڑھتا یا لکھتا ہے۔ Claude 4.7 سے پہلے کے models کے بارے میں Anthropic کی glossary کے مطابق تقریباً 3.5 English characters ایک token کے برابر ہوتے ہیں۔ Anthropic کے model overview کے مطابق ان models میں 1 million tokens تقریباً 750,000 words پر مشتمل ہوتے ہیں۔ 3.5 characters فی token کے حساب سے یہ تقریباً 3.5 million characters، یعنی تقریباً 3.5 MB کا سادہ English متن بنتا ہے۔ Claude Opus 4.7 میں متعارف کرائے گئے نئے tokenizer پر یہی 1 million tokens تقریباً 555,000 words، یا تقریباً 2.5 million characters پر مشتمل ہوتے ہیں۔

عام inputs کے شائع شدہ اندازے اس حجم کو سمجھنے میں زیادہ مدد دیتے ہیں۔

[
  {
    "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 tokens تقریباً 400 اوسط web pages کو ایک بار پڑھنے، یا اس حجم کے 8 research papers کے برابر ہیں۔ یہ درمیانے حجم کے codebase کو ایک بار پڑھنے، یا ایک شخص کے لیے ایک ماہ کے ہلکے chat استعمال کے برابر بھی ہیں۔

ان تمام اعداد کو اندازہ سمجھیں۔ Code، JSON اور English کے علاوہ دوسری زبانوں کا متن ایک token میں کم words رکھتا ہے، اس لیے یہ word counts زیادہ امید افزا حد کو ظاہر کرتے ہیں۔ ایک اور عامل count کو بدلتا ہے: Claude Opus 4.7 اور اس کے بعد کے models، جن میں Opus 5 اور Sonnet 5 شامل ہیں، نیا tokenizer استعمال کرتے ہیں۔ یہ Sonnet 4.6 اور اس سے پہلے کے models کے مقابلے میں ایک ہی متن کے لیے تقریباً 30 percent زیادہ tokens پیدا کرتا ہے۔ Claude Haiku 4.5 پرانا tokenizer استعمال کرتا ہے۔ اس لیے Haiku 4.5 پر ماپا گیا count، یکساں input کے لیے Sonnet 5 کا count کم ظاہر کرتا ہے۔ اس کا مطلب ہے کہ اس حد کے دونوں طرف price-per-million کا براہ راست موازنہ منصفانہ نہیں۔ فیصلہ کرنے سے پہلے ایک ہی prompt کو دونوں models کے خلاف count کریں۔

Claude فی 1 ملین tokens کی قیمت

[
  {
    "label": "Haiku 4.5",
    "input_usd": 1,
    "output_usd": 5
  },
  {
    "label": "Sonnet 5",
    "input_usd": 2,
    "output_usd": 10
  },
  {
    "label": "Sonnet 4.6",
    "input_usd": 3,
    "output_usd": 15
  },
  {
    "label": "Opus 5",
    "input_usd": 5,
    "output_usd": 25
  }
]

Claude Sonnet 5 کی قیمت input کے لیے $2 اور output کے لیے $10 ہے۔ Anthropic نے 31 August 2026 تک یہ قیمت introductory rate کے طور پر پیش کی، پھر اسے standard price بنا دیا اور $3 اور $15 تک planned اضافہ منسوخ کر دیا۔ Claude Opus 5 کی قیمت بالترتیب $5 اور $25 ہے۔ Fable models کی قیمتیں اس جدول سے بھی زیادہ ہیں: Claude Fable 5 اور نیا Claude Fable 5.1، دونوں کے لیے input $10 اور output $50 ہے، اس لیے ان نرخوں کی ادائیگی قابلِ قدر ہے یا نہیں یہ اس بات پر منحصر ہے کہ آپ انہیں کن کاموں کے لیے استعمال کرتے ہیں۔

Anthropic کی موجودہ lineup ان models سے نئی ہے جن کی قیمتیں اس صفحے پر دی گئی ہیں۔ Claude Opus 5.5 کی قیمت input کے لیے $4 اور output کے لیے $20، Claude Sonnet 5.5 کی $2 اور $10، جبکہ Claude Haiku 5.5 کی $0.10 اور $0.50 سے شروع ہوتی ہے۔ Opus 5، Sonnet 5، Haiku 4.5 اور Fable 5 اب legacy models کے طور پر درج ہیں، لیکن اب بھی دستیاب ہیں، اس لیے ذیل میں دی گئی عملی مثالیں اسی طرح چلتی ہیں۔ Haiku 5.5 کی قیمت اور اس کا استعمال نئے models میں سب سے کم قیمت والے model کی وضاحت کرتا ہے۔

نرخ تبدیل ہوتے رہتے ہیں۔ اس صفحے پر دی گئی ہر رقم کو October 2026 کی ایک عملی مثال سمجھیں، اور بجٹ منظور کرنے سے پہلے موجودہ اعداد official pricing page پر ضرور دیکھیں۔

یہ نرخ بتاتے ہیں کہ Claude کی قیمت کیا ہے، لیکن یہ نہیں بتاتے کہ آپ کے workload کے لیے یہ کم قیمت اختیار ہے یا نہیں۔ Claude اور ChatGPT دونوں پر قیمت لگائے گئے تین کام دکھاتے ہیں کہ ہر API کس صورت میں بہتر ثابت ہوتی ہے۔

Context length نرخ کو تبدیل نہیں کرتی، صرف ایک exception ہے۔ Claude 4.6 اور اس کے بعد کے models میں، Claude Haiku 5.5 کے علاوہ، مکمل 1M token context window standard pricing کے تحت billed ہوتی ہے۔ اس لیے 900,000 tokens کی request کی فی token قیمت 9,000 tokens والی request کے برابر ہوتی ہے۔ طویل prompt کی قیمت زیادہ اس لیے ہوتی ہے کہ اس میں tokens زیادہ ہوتے ہیں؛ long-context کے لیے الگ rate لاگو نہیں ہوتا۔ Claude Haiku 5.5 کی قیمت prompt length کے مطابق مقرر ہوتی ہے۔ جس request کا prompt 100,000 tokens سے زیادہ ہو، اس کے لیے input کی قیمت $0.50 اور output کی قیمت $2.50 فی million ہوتی ہے، نہ کہ $0.10 اور $0.50۔ Cache reads اور cache writes بھی اس حد میں شمار ہوتے ہیں۔

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

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

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, October 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 tokens درکار ہوتے ہیں۔

ایک million input tokens سے اس نوعیت کی تقریباً 232 requests کی جا سکتی ہیں۔ روزانہ 1,000 requests پر ایپ روزانہ 4.3 million input tokens استعمال کرتی ہے، اس لیے "1M tokens" چھ گھنٹے سے بھی کم 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 ماہانہ میں چلتی ہے۔ آپ کا model انتخاب اور caching کا فیصلہ، اس volume پر آپ کی negotiated rate سے زیادہ اہم ہیں۔ کون سا model چلانا ہے، یہ الگ سوال ہے؛ evaluations میں کامیاب ہونے والا سب سے کم قیمت model منتخب کریں: Opus، Sonnet اور Haiku کے درمیان انتخاب میں اسے درست طریقے سے test کرنے کا طریقہ بیان کیا گیا ہے۔

Prompt caching بار بار آنے والے حصے کی لاگت کم کرتی ہے

وہ 4,000 token prefix ہر request پر یکساں ہوتا ہے، اور ہر بار اس کی مکمل input price ادا کرنا پڑتی ہے۔ Prompt caching اس process شدہ prefix کو محفوظ کرتی ہے اور اسے دوبارہ استعمال کرنے کے لیے کم rate وصول کرتی ہے۔

اس page کے price chart اور worked examples میں شامل models، یعنی Haiku 4.5، Sonnet 5، Sonnet 4.6 اور Opus 5، اور Fable 5 میں cache read کی لاگت base input rate کا 0.1 گنا ہے۔ کچھ نئے models read کے لیے اس سے بھی کم charge کرتے ہیں: Opus 5.5 اور Sonnet 5.5 میں یہ 0.05 گنا، جبکہ Fable 5.1 اور Mythos 5.1 میں 0.025 گنا ہے۔ Cache لکھنے کی لاگت 5 minute lifetime کے لیے base rate کا 1.25 گنا، یا 1 hour lifetime کے لیے 2 گنا ہے۔ اس لیے 0.1 گنا والے models میں 5 minute cache ایک read کے بعد اپنی لاگت پوری کر لیتی ہے، کیونکہ write پر 0.25 اضافی لاگت آتی ہے جبکہ ہر read پر 0.9 کی بچت ہوتی ہے۔ 1 hour cache کو break even ہونے کے لیے 2 reads درکار ہوتے ہیں۔

اسے فعال کرنے کا آسان ترین طریقہ ایک single 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
  }
}

ان 3 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 چیزیں cache کو فائدہ مند ہونے سے روکتی ہیں، اور دونوں خاموشی سے fail ہوتی ہیں۔

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

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

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

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

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

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

چونکہ API کوئی state محفوظ نہیں رکھتا، اس لیے آپ کا 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 سے ظاہر ہونے والی لاگت سے زیادہ ہوتی ہے۔ اسی وجہ سے طویل threads میں مستحکم prefix کو cache کرنا یا پرانے turns کا خلاصہ بنانا فائدہ مند ہوتا ہے۔ جو agent tool calls پر loop کرتا ہے، اس میں بھی یہی صورت بنتی ہے، بلکہ مسئلہ زیادہ سنگین ہوتا ہے: ہر tool result history میں رہتا ہے اور بعد کے ہر turn پر دوبارہ بھیجا جاتا ہے۔ اپنے زیر انتظام agent کے لیے سخت spending limit مقرر کرنا یہاں سب سے زیادہ اہم ہے، کیونکہ یہ اضافہ خودکار ہوتا ہے اور اس کی نگرانی کوئی نہیں کر رہا ہوتا۔

اندازہ لگانے سے پہلے tokens شمار کریں

Word count سے tokens کی تعداد اخذ کرنا بند کریں۔ 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"
    }]
  }'

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

{ "input_tokens": 14 }

اسے اپنا حقیقی system prompt اور tool definitions، نیز ایک نمائندہ user message فراہم کریں، پھر حاصل شدہ تعداد کو اوپر دیے گئے cost function میں رکھیں۔ Endpoint وہی body قبول کرتا ہے جو message request استعمال کرتی ہے، اس لیے base64 کے طور پر بھیجی گئی images اور PDFs بھی درست طور پر شمار ہوتی ہیں۔ یہ web search اور web fetch جیسے server tools، نیز URL یا file reference کے ذریعے بھیجی گئی images یا documents کو مسترد کرتا ہے۔ دو باتیں اہم ہیں۔ یہ تعداد ایک estimate ہے اور billed figure سے معمولی طور پر مختلف ہو سکتی ہے۔ اس کی پیمائش اس model کے tokenizer سے بھی ہوتی ہے جسے آپ فراہم کرتے ہیں، اس لیے وہی model فراہم کریں جسے آپ حقیقتاً چلائیں گے۔

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

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

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

• Tool definitions ہر request پر 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 کیا گیا صفحہ input tokens بن جاتا ہے۔ 100 kB کا documentation page تقریباً 25,000 tokens پر مشتمل ہوتا ہے۔
• Claude 4.6 اور بعد کے versions پر inference_geo کے ساتھ صرف US inference طلب کرنے سے ہر token category پر 1.1 multiplier لاگو ہوتا ہے، جس میں cache reads اور writes بھی شامل ہیں۔

API خریدنا مجموعی طور پر درست فیصلہ ہے یا نہیں، اس کا انحصار آپ کے volume پر ہے۔ Plan کی usage ceiling تک پہنچنا عموماً یہی سوال پیدا کرتا ہے، اور limit سے نکلنے کے راستے window ختم ہونے کا انتظار کرنے سے لے کر اس کام کو metered API calls پر منتقل کرنے تک ہوتے ہیں۔ استعمال کی ایک خاص حد سے کم flat monthly plan واضح طور پر بہتر رہتا ہے، اور Claude subscription کے مقابلے میں API اس تقابل کو حقیقی اعداد کے ساتھ پیش کرتا ہے۔

FAQ

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

یہ model پر منحصر ہے، اور اس بات پر بھی کہ tokens input ہیں یا output۔ اکتوبر 2026 تک، one million input tokens کی قیمت Claude Haiku 4.5 پر $1، Claude Sonnet 5 پر $2، اور Claude Opus 5 پر $5 ہے۔ نئے Claude Haiku 5.5 میں 100,000 tokens تک کے prompts کے لیے قیمت one million input tokens پر $0.10 سے شروع ہوتی ہے، جبکہ اس حد سے زیادہ prompts پر $0.50 وصول کیے جاتے ہیں۔ ان تمام models میں output کی قیمت input rate سے پانچ گنا ہے۔ Rates تبدیل ہو سکتی ہیں، اس لیے budget میں رقم شامل کرنے سے پہلے official pricing page پر ان کی تصدیق کریں۔

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

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

کیا prompt caching ہمیشہ پیسے بچاتی ہے؟

نہیں۔ 5 minute cache write کی قیمت base input rate کا 1.25 گنا ہے، اس لیے ایسا prefix جو لکھا جائے مگر کبھی read نہ ہو، اسے عام طریقے سے بھیجنے کے مقابلے میں 25 percent زیادہ مہنگا پڑتا ہے۔ پہلی read کے بعد اس کا خرچ پورا ہو جاتا ہے۔ یہ دو طریقوں سے fail ہوتی ہے، اور دونوں صورتوں میں کوئی error نہیں آتا۔ اگر 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 سے خارج کریں۔