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

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

1M tokens سے مراد ایک million tokens ہے، اور یہی وہ unit ہے جس میں ہر Claude API (application programming interface) کی قیمت بیان کی جاتی ہے۔ اس کی کوئی ایک مقررہ قیمت نہیں، کیونکہ input اور output کی billing مختلف rates پر ہوتی ہے اور ہر model کے لیے ان دونوں کی اپنی rates ہوتی ہیں۔ August 2026 تک، Claude Haiku 4.5 پر ایک 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 ٹوکن کی مقدار کیسی ہوتی ہے

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

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

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

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

Claude فی 1 million 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 input اور $25 output ہے۔ اس جدول سے بھی زیادہ قیمت والا ایک model موجود ہے: Claude Fable 5 کی فہرست میں input کے لیے $10 اور output کے لیے $50 درج ہے، اس لیے یہ rates ادا کرنا مناسب ہے یا نہیں اس بات پر منحصر ہے کہ آپ اسے حقیقت میں کن کاموں کے لیے استعمال کرتے ہیں۔

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

Context length rate کو تبدیل نہیں کرتی۔ Claude 4.6 اور اس کے بعد کے versions میں مکمل 1M token context window کی billing 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

اسے قابلِ اجرا 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 tokens درکار ہوتے ہیں۔

1 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 ماہانہ میں چلتی ہے۔ اس volume پر آپ کا model choice اور caching کا فیصلہ، دونوں، اس شرح سے زیادہ اہم ہیں جو آپ مذاکرات کے ذریعے حاصل کر سکتے ہیں۔ کون سا model چلانا ہے، یہ الگ سوال ہے، اور جو کم ترین قیمت والا model آپ کی evaluations میں کامیاب ہو، وہی بہتر انتخاب ہے: Opus، Sonnet اور Haiku کے درمیان انتخاب میں اس کی درست testing کا طریقہ بیان کیا گیا ہے۔

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

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

Cache read کی لاگت base input rate کا 0.1 گنا ہے۔ 5 منٹ کی lifetime کے لیے cache لکھنے کی لاگت base rate کا 1.25 گنا، جبکہ 1 گھنٹے کی lifetime کے لیے 2 گنا ہے۔ اس لیے 5 منٹ کا cache ایک read کے بعد اپنی لاگت پوری کر لیتا ہے، کیونکہ اسے لکھنے کی اضافی لاگت 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 کو فائدہ مند ہونے سے روکتی ہیں، اور دونوں خاموشی سے fail ہوتی ہیں۔

prefix byte-identical ہونا چاہیے۔ Cache lookup، prefix match استعمال کرتا ہے، اس لیے system prompt کے آغاز میں timestamp یا user کا نام ہر درخواست میں اسے تبدیل کر دیتا ہے۔ اس صورت میں آپ ہر بار base input کا 1.25 گنا ادا کرتے ہیں اور کبھی cache read نہیں ہوتا۔ علامت یہ ہے کہ cache_creation_input_tokens بلند رہتا ہے جبکہ cache_read_input_tokens، 0 رہتا ہے۔ cache_control کو اس آخری block پر رکھیں جس کا content تمام درخواستوں میں یکساں ہو، اور اس کے بعد وہ تمام 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 ٹوکن prefix Sonnet 5 پر cache ہو جاتا ہے، لیکن Haiku 4.5 پر نہیں، کیونکہ 4,000 اس model کی مقررہ کم از کم حد سے کم ہے۔ جب دونوں counters کی قدر 0 ہو، تو کچھ بھی cache نہیں ہوا۔

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

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

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

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

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

فرض کریں کہ ہر 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 پر مشتمل ہوگی۔

اسی لیے chat feature کی لاگت اس کے transcript سے ظاہر ہونے والی لاگت سے زیادہ ہوتی ہے، اور اسی لیے طویل threads میں مستحکم prefix کو cache کرنا یا پرانے turns کا خلاصہ بنانا فائدہ مند رہتا ہے۔ ایسا agent جو tool calls کے چکروں میں چلتا ہے، اسی انداز میں بڑھتا ہے، بلکہ اس کی صورت زیادہ خراب ہوتی ہے: ہر 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"
    }]
  }'

اس کا response ایک field پر مشتمل ہوتا ہے:

{ "input_tokens": 14 }

اسے اپنا حقیقی system prompt اور tool definitions، ایک نمائندہ user message کے ساتھ، دیں۔ پھر اس تعداد کو اوپر دیے گئے cost function میں شامل کریں۔ endpoint وہی body قبول کرتا ہے جو message request استعمال کرتی ہے، اس لیے images اور PDFs بھی درست طور پر شمار ہوتے ہیں۔ دو باتیں اہم ہیں۔ یہ تعداد تخمینی ہوتی ہے اور 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 بڑھا دیتا ہے۔ دس verbose tool descriptions ایک مختصر prompt کو دوگنا کر سکتی ہیں۔
• Web search کی قیمت 1,000 searches کے لیے $10 ہے۔ اس کے علاوہ results کے context میں شامل ہونے پر استعمال ہونے والے tokens کی قیمت بھی وصول ہوتی ہے۔
• Web fetch کی اپنی کوئی اضافی فیس نہیں، لیکن fetched page 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، introductory pricing کے تحت Claude Sonnet 5 پر $2، اور Claude Opus 5 پر $5 ہے۔ ان تمام models پر output کی قیمت input rate سے پانچ گنا ہے۔ 1 September 2026 کو Sonnet 5 کے rates بڑھ کر $3 input اور $15 output ہو جائیں گے۔ Rates تبدیل ہوتے رہتے ہیں، اس لیے budget میں کوئی رقم شامل کرنے سے پہلے official pricing page پر ان کی تصدیق کریں۔

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

نہیں۔ English میں ایک token تقریباً 4 characters، یا لگ بھگ 0.75 words کے برابر ہوتا ہے، اس لیے 1 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 منتقل نہیں کیے جا سکتے۔ جس model کو چلانے کا ارادہ ہو، اسے فراہم کرتے ہوئے مفت /v1/messages/count_tokens endpoint سے پیمائش کریں۔

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

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

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

کیونکہ ہر 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 سے خارج کر دیں۔