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

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

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

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

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

1M tokens کی شکل

Token متن کا وہ حصہ ہے جسے model پڑھتا یا لکھتا ہے۔ Anthropic کے عمومی اندازے کے مطابق 1 token تقریباً 4 characters، یا انگریزی کے تقریباً 0.75 words کے برابر ہوتا ہے۔ اس لیے 1M tokens تقریباً 750,000 words، یا سادہ متن کی تقریباً 4 MB مقدار بنتے ہیں۔

عام 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 کو ایک مرتبہ process کرنے، یا ایک شخص کے لیے ہلکے chat استعمال کے 1 ماہ کے برابر ہے۔

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

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

[
  {
    "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 سے standard rate لاگو ہوگی: input کے لیے $3 اور output کے لیے $15۔ Claude Opus 5 کی قیمت $5 اور $25 ہے۔ اس فہرست سے بھی زیادہ مہنگا ایک model موجود ہے: Claude Fable 5 کے لیے input کی قیمت $10 اور output کی قیمت $50 ہے، اس لیے یہ rates ادا کرنا فائدہ مند ہے یا نہیں اس بات پر منحصر ہے کہ آپ اسے کن کاموں کے لیے استعمال کرتے ہیں۔

Rates تبدیل ہوتی رہتی ہیں۔ اس صفحے پر موجود ہر figure کو August 2026 کی تاریخ والی مثال سمجھیں، اور budget منظور کرنے سے پہلے official pricing page پر موجودہ numbers کی تصدیق کریں۔

یہ rates بتاتی ہیں کہ Claude کی قیمت کیا ہے، لیکن یہ نہیں بتاتیں کہ آپ کے workload کے لیے یہ سستا option ہے یا نہیں۔ Claude اور ChatGPT دونوں پر لاگت کا حساب کیے گئے تین کام سے معلوم ہوتا ہے کہ ہر API کہاں بہتر ثابت ہوتی ہے۔

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

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

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

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

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

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 پرنٹ کرتا ہے۔ ایسی درخواست جس میں 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 ٹوکن والا prefix ہر request میں یکساں ہے، لیکن آپ ہر بار اس کی مکمل input قیمت ادا کرتے ہیں۔ Prompt caching اس process شدہ prefix کو محفوظ کرتی ہے اور اسے دوبارہ استعمال کرنے پر کم rate وصول کرتی ہے۔

Cache read کی لاگت base input rate کا 0.1 گنا ہوتی ہے۔ 5 منٹ کی lifetime کے لیے cache لکھنے کی لاگت base rate کا 1.25 گنا، جبکہ 1 گھنٹے کی lifetime کے لیے 2 گنا ہوتی ہے۔ اس لیے 5 منٹ کا cache ایک read کے بعد اپنی لاگت پوری کر لیتا ہے، کیونکہ write کی اضافی لاگت 0.25 ہے اور ہر read سے 0.9 کی بچت ہوتی ہے۔ 1 گھنٹے کے 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 الگ الگ rates پر bill ہوتے ہیں اور ان کا مجموعہ آپ کا حقیقی input volume ہے: total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens۔ ایسا cost estimate جو صرف input_tokens پڑھتا ہو، caching فعال ہونے کے بعد بہت غلط ہوگا۔

2 چیزیں cache کو فائدہ مند ہونے سے روکتی ہیں، اور دونوں صورتوں میں کوئی error ظاہر نہیں ہوتا۔

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

prefix کافی طویل ہونا چاہیے۔ Cache کے لیے کم از کم قابل قبول length Opus 5 پر 512 tokens، Sonnet 5 پر 1,024، اور Haiku 4.5 پر 4,096 ہے۔ اس سے چھوٹا prompt cache نہیں ہوتا اور کوئی error واپس نہیں آتا۔ اوپر دی گئی مثال میں 4,000 tokens والا 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 شمار کریں

tokens کی تعداد word count سے اخذ کرنا بند کریں۔ 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 بھی درست طور پر شمار ہوتے ہیں۔ دو caveats اہم ہیں۔ یہ count ایک تخمینہ ہے اور 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۔ August 2026 تک Claude Haiku 4.5 پر 1 million input tokens کی لاگت $1، ابتدائی قیمت کے تحت Claude Sonnet 5 پر $2، اور Claude Opus 5 پر $5 ہے۔ ان تمام models پر output کی لاگت input rate سے پانچ گنا ہے۔ 1 September 2026 کو Sonnet 5 کی قیمت 1M input tokens کے لیے $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 کے برابر ہوتے ہیں۔ یہ ratio صرف رہنمائی کے لیے ہے۔ Code، JSON اور English کے علاوہ دوسری languages میں ہر word کے لیے زیادہ tokens استعمال ہوتے ہیں۔ Claude Opus 4.7 اور اس کے بعد کے versions ایک نیا tokenizer بھی استعمال کرتے ہیں، جو Claude Sonnet 4.6 اور اس سے پہلے کے versions کے مقابلے میں یکساں text کے لیے تقریباً 30 percent زیادہ tokens بناتا ہے۔ اس لیے مختلف model generations کے درمیان counts قابلِ منتقلی نہیں ہوتے۔ مفت /v1/messages/count_tokens endpoint سے، اس model کو پاس کر کے count معلوم کریں جسے آپ چلانے کا ارادہ رکھتے ہیں۔

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

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