Claude اتنا مہنگا کیوں ہے؟ Token کا حساب

Claude مہنگا کیوں ہے؟ مختصر جواب

Claude چار وجوہات کی بنا پر مہنگا ہے، اور یہ وجوہات ایک دوسرے کے اثر کو بڑھاتی ہیں۔ output tokens کی قیمت input tokens کے مقابلے میں پانچ گنا ہے۔ API آپ کی گفتگو کی کوئی memory محفوظ نہیں رکھتی، اس لیے ہر turn پر پوری history دوبارہ بھیجی جاتی ہے اور دوبارہ bill کی جاتی ہے۔ ایک agent ایک سوال کو درجنوں API calls میں تبدیل کر دیتا ہے، اور ہر call کے ساتھ بڑھتی ہوئی history بھیجی جاتی ہے۔ اس کے علاوہ، frontier model کی قیمت اس کام کی دشواری کے مطابق مقرر کی جاتی ہے جو وہ انجام دیتا ہے، نہ کہ ایک چھوٹا model چلانے کی لاگت کے مطابق۔

token متن کا ایک حصہ ہوتا ہے، اور اس میں شامل متن کی مقدار model پر منحصر ہوتی ہے۔ Opus 5، Sonnet 5، Fable 5 اور 5.1، نیز ہر 5.5 model، Claude 4.7 کے ساتھ متعارف ہونے والا نیا tokenizer استعمال کرتے ہیں۔ Anthropic کے مطابق ان tokens میں سے one million تقریباً 555,000 English الفاظ یا 2.5 million characters کے برابر ہیں۔ اس حساب سے ایک token تقریباً ڈھائی characters، یا آدھے سے کچھ زیادہ word کے برابر ہے۔ Sonnet 4.6 اور Haiku 4.5 جیسے پرانے models پچھلا tokenizer استعمال کرتے ہیں، جس میں ایک token تقریباً 3.5 English characters کے برابر ہوتا ہے اور one million tokens میں تقریباً 750,000 الفاظ ہوتے ہیں۔ نئے models پر وہی متن تقریباً 30 percent زیادہ tokens شمار ہوتا ہے۔ اس لیے پرانا تخمینہ دوبارہ استعمال کرنے کے بجائے اسے اس model کے مطابق دوبارہ شمار کریں جسے آپ استعمال کرنے کا ارادہ رکھتے ہیں۔ rates فی million tokens بتائی جاتی ہیں اور MTok (million tokens) لکھی جاتی ہیں۔ ذیل میں دی گئی ہر rate October 2026 تک Claude API کی شائع شدہ rate ہے۔

زیادہ تر غیر متوقع bills اس فہرست کی دوسری اور تیسری وجوہات سے آتے ہیں۔ لوگ عموماً یہ سمجھ کر آغاز کرتے ہیں کہ Claude کے لکھے ہوئے answers ہی اخراجات کا سبب ہیں۔ agent session میں writing اکثر کل bill کے one tenth سے بھی کم ہوتی ہے۔

شائع کردہ نرخ، تاکہ نمبروں پر اتفاق ہو جائے

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

مطلق نمبروں کے بجائے شرحوں کی ساخت دیکھیں۔ ہر model input کے مقابلے میں output کے لیے ٹھیک پانچ گنا زیادہ چارج کرتا ہے۔ Opus 5 کے لیے فی million input tokens 5 dollars اور فی million output tokens 25 dollars لاگت آتی ہے۔ Haiku 4.5 کے لیے یہ شرحیں بالترتیب 1 اور 5 ہیں۔ اس لیے اس table میں سب سے سستے model سے سب سے مہنگے model تک فرق پانچ گنا ہے، اور پڑھنے سے لکھنے تک فرق بھی پانچ گنا ہے۔

Sonnet 5 کے لیے فی million tokens 2 اور 10 dollars لاگت آتی ہے۔ Anthropic نے پہلے یہ قیمت August 31, 2026 تک introductory rate کے طور پر پیش کی، پھر اسے standard price بنا دیا اور 3 اور 15 dollars تک planned اضافہ منسوخ کر دیا۔ model releases کے ساتھ rates تبدیل ہوتے رہتے ہیں، اس لیے ان کی بنیاد پر budget بنانے سے پہلے موجودہ rates چیک کریں۔ نئے models بھی یہی پانچ گنا ساخت برقرار رکھتے ہیں: Opus 5.5 کی فہرست میں فی million 4 اور 20 dollars، Sonnet 5.5 کی 2 اور 10 dollars، جبکہ October 7, 2026 کو released Haiku 5.5 کی شرحیں 0.10 اور 0.50 dollars ہیں۔ اس table سے کم کوئی free tier بھی موجود نہیں، تاہم نئے accounts کو ابتدا میں چھوٹا credit ملتا ہے اور API کے بعض حصے بالکل مفت ہیں۔

آخری column cache read rate ہے۔ زیادہ تر bills کا فیصلہ یہی کرتی ہے۔ حساب کے بعد اس پر واپس آئیں۔

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

پڑھنا اور لکھنا ایک جیسا کام نہیں ہے۔ input tokens کو ایک ہی pass میں process کیا جاتا ہے۔ model پورا prompt ایک ساتھ پڑھتا ہے، اور اس پر کام parallel طور پر چلتا ہے۔ اسی لیے 60,000 token کے prompt کو پڑھنے میں 1,000 token کے prompt کے مقابلے میں 60,000 گنا زیادہ وقت نہیں لگتا۔

آؤٹ پٹ tokens ایک ایک کر کے تیار کیے جاتے ہیں۔ ہر نئے token کے لیے model سے اپنا الگ pass درکار ہوتا ہے، اور اسے اپنے سے پہلے موجود ہر token کو context کے طور پر درکار ہوتا ہے۔ 1,000 tokens لکھنے کا مطلب 1,000 passes ہیں، جو ایک کے بعد ایک چلتے ہیں۔ اس serial کام کو پڑھنے کی طرح پھیلایا نہیں جا سکتا، اس لیے ہر آؤٹ پٹ token hardware کو زیادہ دیر تک مصروف رکھتا ہے۔

اسی لیے "جواب مختصر کریں" لوگوں کی توقع کے مقابلے میں کم مؤثر طریقہ ہے۔ یہ agent bill کے نسبتاً چھوٹے حصے پر اثر ڈالتا ہے۔

میری پوری گفتگو ہر بار دوبارہ بل کیوں ہوتی ہے؟

Claude API حالت محفوظ نہیں کرتی۔ Anthropic کے سرور پر کوئی ایسی گفتگو موجود نہیں ہوتی جس میں آپ صرف ایک نیا پیغام شامل کر رہے ہوں۔ ہر request میں پیغامات کی پوری history شامل ہوتی ہے، اور model کچھ بھی لکھنے سے پہلے اسے مکمل پڑھتا ہے۔ اس لیے turn 30 کے بل میں turns 1 سے 29 تک کا مواد بھی شامل ہوتا ہے۔

اس کا مطلب ہے کہ گفتگو کی لاگت اس کی طوالت سے زیادہ تیزی سے بڑھتی ہے۔ turn 1 میں چھوٹا context bill ہوتا ہے۔ turn 40 میں بڑا context bill ہوتا ہے۔ تمام 40 turns کی لاگت جمع کریں تو آپ نے ان tokens کی تعداد سے کئی گنا زیادہ ادائیگی کی ہوتی ہے جو کبھی لکھے گئے تھے۔

[
  {
    "turn": 1,
    "context_tokens": "20,000"
  },
  {
    "turn": 5,
    "context_tokens": "32,000"
  },
  {
    "turn": 10,
    "context_tokens": "45,000"
  },
  {
    "turn": 15,
    "context_tokens": "55,000"
  },
  {
    "turn": 20,
    "context_tokens": "64,000"
  },
  {
    "turn": 25,
    "context_tokens": "74,000"
  },
  {
    "turn": 30,
    "context_tokens": "84,000"
  },
  {
    "turn": 35,
    "context_tokens": "92,000"
  },
  {
    "turn": 40,
    "context_tokens": "100,000"
  }
]

اوپر والا session 20,000 tokens سے شروع ہوتا ہے۔ اس میں system prompt، tool definitions اور agent کی جانب سے کھولی گئی پہلی files شامل ہیں۔ turn 40 تک context میں 100,000 tokens موجود ہوتے ہیں۔ تمام 40 turns پر اس کا average نکالیں تو ہر request میں تقریباً 60,000 tokens پڑھے جاتے ہیں۔

ایک agent کی لاگت chat سے کہیں زیادہ کیوں ہوتی ہے؟

chat میں ہر سوال کے لیے ایک request ہوتی ہے۔ agent میں ہر step کے لیے ایک request ہوتی ہے۔ file پڑھنا ایک step ہے۔ test چلانا ایک step ہے۔ test کا output پڑھنا ایک step ہے۔ file میں ترمیم کرنا ایک step ہے۔ کسی ایک task کو مکمل کرنے کے لیے 40 steps coding agent کے لیے معمول کی بات ہے۔

tool استعمال کرنے کے ساتھ 2 اضافی اخراجات بھی شامل ہوتے ہیں۔ tool definitions ہر request میں input tokens ہوتی ہیں، کیونکہ model کو ہر بار یہ بتانا پڑتا ہے کہ کون سے tools موجود ہیں۔ Anthropic اس اضافی حجم کی تفصیل شائع کرتا ہے: tool_choice کو auto پر set کرنے کی صورت میں Opus 5 پر tool use system prompt 286 tokens پر مشتمل ہوتا ہے، اس کے علاوہ آپ کے اپنے tool schemas کے tokens بھی شامل ہوتے ہیں۔ بعض server-side tools کی الگ فیس بھی ہوتی ہے۔ Web search کے لیے نتائج سے استعمال ہونے والے tokens کے علاوہ 1,000 searches پر $10 فیس لی جاتی ہے۔

ہر tool result بھی مستقل context بن جاتا ہے۔ ایسا command جو 3,000 lines print کرتا ہے، ان تمام 3,000 lines کو اس کے بعد آنے والی ہر request میں شامل کر دیتا ہے، جب تک session ختم نہ ہو یا history compact یا clear نہ کر دی جائے۔ Claude Code کی رپورٹ کردہ فی session token usage اس عمل کو نمایاں کرتی ہے: noisy command کے فوراً بعد input number بڑھتا ہوا دیکھیں۔

ایک حقیقی session کا حساب

یہ Opus 5 پر agentic coding کا ایک حقیقت پسندانہ گھنٹہ ہے۔ چالیس API requests کی گئیں۔ context 20,000 سے بڑھ کر 100,000 tokens تک پہنچا، اس لیے فی request اوسطاً تقریباً 60,000 tokens استعمال ہوئے۔ model نے فی request تقریباً 700 tokens لکھے، جن میں مختصر tool calls اور code کے چند طویل blocks شامل تھے۔

Requests in the session:      40
Average context per request:  60,000 tokens

Total input tokens billed:    40 x 60,000                    = 2,400,000
Input cost on Opus 5:         2,400,000 x $5 / 1,000,000     = $12.00

Total output tokens:          40 x 700                       =    28,000
Output cost on Opus 5:        28,000 x $25 / 1,000,000       =  $0.70

Session total                                                = $12.70

[
  {
    "label": "Input, context re-read",
    "billed_tokens": "2,400,000",
    "cost_usd": "12.00"
  },
  {
    "label": "Output, code and tool calls",
    "billed_tokens": "28,000",
    "cost_usd": "0.70"
  }
]

تقسیم پر غور کریں۔ reading cost 12.00 dollars اور writing cost 0.70 dollars تھی، اس لیے آپ نے حقیقت میں جو output پڑھا، وہ bill کا تقریباً پانچ فیصد ہے۔ model نے 28,000 tokens لکھے، جبکہ reading کے لیے 2,400,000 tokens کا bill آیا۔ کسی نے 2.4 million tokens ٹائپ نہیں کیے تھے۔ وہی 100,000 tokens بار بار پڑھے گئے۔

لیور 1: prompt caching، جو سب سے بڑا ذریعہ ہے

Prompt caching آپ کے prompt کے مستحکم prefix کی processed شکل محفوظ کرتی ہے۔ اگلی request پر اس prefix کو دوبارہ process کرنے کے بجائے cache سے پڑھا جاتا ہے۔ پانچ منٹ کی cache میں لکھنے کی لاگت input rate سے 1.25 گنا، جبکہ ایک گھنٹے کی cache میں 2 گنا ہوتی ہے۔ زیادہ تر models، بشمول Opus 5، میں اسے پڑھنے کی لاگت input rate سے 0.1 گنا ہے۔ Opus 5.5 اور Sonnet 5.5 کے لیے یہ 0.05 گنا، جبکہ Fable 5.1 کے لیے 0.025 گنا ہے۔ Opus 5 پر اس کی قیمت 0.50 dollars per million ہے، بجائے 5 dollars کے۔

اس کا اطلاق اوپر والے session پر کریں۔ Conversation بڑھنے کے دوران 100,000 میں سے ہر token ایک بار cache میں لکھا جاتا ہے۔ باقی 2,300,000 input tokens cache reads بن جاتے ہیں۔

Tokens written to cache:      100,000
Cache write at 1.25x input:   100,000 x $6.25 / 1,000,000    = $0.63

Tokens read from cache:       2,300,000
Cache read at 0.1x input:     2,300,000 x $0.50 / 1,000,000  = $1.15

Output cost, unchanged                                       = $0.70

Session total                                                = $2.48

Cache کے قابل حصے کو cache_control field سے نشان زد کریں۔ Breakpoint اس content کے بعد رکھیں جو turns کے درمیان تبدیل نہیں ہوتا: system prompt اور tool definitions۔ جس طویل document سے آپ بار بار رجوع کرتے ہیں، اسے بھی اسی مستحکم block میں رکھیں۔

{
  "model": "claude-opus-5",
  "system": [
    {
      "type": "text",
      "text": "<long, stable instructions>",
      "cache_control": {"type": "ephemeral"}
    }
  ],
  "messages": [{"role": "user", "content": "..."}]
}

اب آپ کے prompt کی ترتیب لاگت طے کرتی ہے۔ Cache hit کے لیے prompt کے بالکل آغاز سے exact match درکار ہوتا ہے، اس لیے ہر request پر تبدیل ہونے والی ہر چیز کو غیر متبدل content کے بعد رکھنا ضروری ہے۔ اگر آپ system prompt کے شروع میں timestamp رکھیں گے تو ہر turn پر cache ٹوٹ جائے گی: پورا prefix miss بن جائے گا، اور اسے دوبارہ لکھنے کے لیے input rate سے 1.25 گنا ادائیگی کرنا پڑے گی۔

Response سے معلوم ہو جاتا ہے کہ یہ کام ہوا یا نہیں۔ ایک request بھیجیں اور usage block پڑھیں۔

curl 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-opus-5",
    "max_tokens": 256,
    "messages": [{"role": "user", "content": "Hello"}]
  }'

ہر response میں ایک usage object شامل ہوتا ہے، جیسے یہ:

{
  "usage": {
    "input_tokens": 105,
    "cache_creation_input_tokens": 7345,
    "cache_read_input_tokens": 7123,
    "output_tokens": 239
  }
}

اگر repeat request میں اب بھی 0، cache_read_input_tokens میں دکھائی دے تو اس کا مطلب ہے کہ cache hit نہیں ہو رہی۔ عام وجہ یہ ہوتی ہے کہ آپ کے breakpoint سے پہلے موجود کوئی چیز تبدیل ہو گئی ہے۔ پانچ منٹ کی cache بھی expire ہو جاتی ہے، اس لیے چھ منٹ بعد بھیجی گئی request miss ہو گی اور اس کے بعد نیا write ہو گا۔

لیور 2: آسان turns کو چھوٹے model پر بھیجیں

Agent session میں زیادہ تر turns مشکل نہیں ہوتے۔ فائل کھولنا، formatter چلانا، diff پڑھنا۔ ان کاموں کے لیے frontier model ضروری نہیں ہوتا۔ انہیں Haiku 4.5 پر route کرنے سے input rate 5 dollars فی million سے کم ہو کر 1 ہو جاتا ہے۔ Haiku 5.5 کی فہرست میں rate مزید کم ہے: 100,000 tokens تک کے prompts کے لیے 0.10 dollars۔ لیکن prompt اس حد سے بڑھتے ہی اس کی ہر rate پانچ گنا ہو جاتی ہے، اور طویل agent context اس حد تک پہنچ جاتا ہے۔ Haiku 5.5 کی لاگت اور اس کا موزوں استعمال دونوں tiers کی وضاحت کرتا ہے۔

[
  {
    "label": "Opus 5, no caching",
    "session_cost_usd": "12.70"
  },
  {
    "label": "Opus 5, cached",
    "session_cost_usd": "2.48"
  },
  {
    "label": "Sonnet 5, cached",
    "session_cost_usd": "0.99"
  },
  {
    "label": "Haiku 4.5, cached",
    "session_cost_usd": "0.50"
  }
]

اسی session کی لاگت Opus 5 پر caching کے بغیر 12.70 dollars، caching کے ساتھ 2.48، Sonnet 5 پر caching کے ساتھ 0.99، اور Haiku 4.5 پر caching کے ساتھ 0.50 ہے۔ صرف caching bill کو تقریباً 80 فیصد کم کر دیتی ہے۔ Model کا انتخاب باقی لاگت کا بیشتر حصہ ختم کر دیتا ہے۔ Haiku 4.5 کی row میں دوسرے models جتنے ہی token totals رکھے گئے ہیں تاکہ rates کا منصفانہ موازنہ ہو سکے۔ Haiku 4.5 پرانا tokenizer استعمال کرتا ہے، جبکہ نیا tokenizer اسی text کے لیے تقریباً 30 فیصد زیادہ tokens شمار کرتا ہے۔ اس لیے یہی کام Haiku 4.5 پر تقریباً 23 فیصد کم tokens میں مکمل ہوتا ہے، اور اس session کی لاگت تقریباً 0.38 dollars ہو سکتی ہے۔

یہاں ایک اہم حقیقت ہے۔ اگر سستا model غلط جواب دے تو پوری session کی لاگت دوبارہ برداشت کرنی پڑتی ہے، اور آپ کا اپنا وقت بھی صرف ہوتا ہے۔ Task کی مشکل کے مطابق route کریں، price کے مطابق نہیں۔ یہ اصول اوپر کی سمت بھی لاگو ہوتا ہے: Claude Fable 5 اور Fable 5.1 کی listed rates Opus 5 سے زیادہ ہیں، یعنی $10 اور $50 فی million۔ اس لیے وہاں turn بھیجنے سے پہلے ان rates سے آپ کو کیا حاصل ہوتا ہے پڑھیں۔ Opus، Sonnet اور Haiku کے درمیان انتخاب میں بتایا گیا ہے کہ ہر model کن حالات میں قابلِ اعتماد رہتا ہے۔

لیور 3: context hygiene

آپ context میں جو بھی token چھوڑتے ہیں، باقی ہر turn پر اس کی لاگت آتی ہے۔ اس لیے کسی token کو شروع میں ہٹانا، اسے دیر سے ہٹانے کے مقابلے میں کہیں زیادہ مفید ہے۔ اگر 40 turn کے session میں turn 5 پر 5,000 token کی file مکمل طور پر شامل کر دی جائے، تو اسے مزید 35 بار پڑھا جائے گا۔ اس سے 175,000 اضافی input tokens بنتے ہیں، جو Opus 5 پر ایک غیر محتاط paste کے لیے تقریباً ایک dollar کے برابر ہیں۔

یہ 4 عادات اس تعداد کو کم کرتی ہیں:

• نئے task کے لیے گزشتہ دن کے session کو جاری رکھنے کے بجائے نیا session شروع کریں۔
• noisy commands کے output کو model تک پہنچنے سے پہلے، head -50 جیسی کسی چیز کے ذریعے filter کریں، بعد میں نہیں۔
• پوری file کے بجائے صرف وہ function طلب کریں جس کی آپ کو ضرورت ہے۔
• جب طویل session میں پیش رفت رک جائے تو summary طلب کریں اور اسی summary سے دوبارہ شروع کریں۔ summary چند سو tokens پر مشتمل ہوتی ہے، جبکہ transcript ایک لاکھ tokens کا ہو سکتا ہے۔

لیور 4: ہر غیر تعاملی کام کو batch کریں

Batch API درخواستوں کو asynchronous طور پر process کرتی ہے اور input اور output دونوں کی لاگت میں 50 فیصد کمی کرتی ہے۔ اگر کسی job کو اگلے second میں جواب درکار نہیں ہے تو اسے batch کریں۔ اس میں classification، extraction، backlog کا summarising، اور evaluation runs شامل ہیں۔ batch discount، prompt caching کے ساتھ بھی لاگو ہوتا ہے۔ یہ interactive session پر لاگو نہیں ہوتا، کیونکہ وہاں انتظار کرنے کے لیے کچھ نہیں ہوتا۔

کیا مجھ سے اضافی رقم وصول کی جا رہی ہے؟

"Claude مہنگا کیوں ہے" کے پیچھے اصل سوال یہی ہے، اس لیے سیدھا جواب یہ ہے۔ نرخ شائع شدہ ہیں، standard tiers میں سب کے لیے یکساں ہیں، اور فی token وصول کیے جاتے ہیں۔ استثنا negotiated contract ہے، اور وہاں بھی Claude Enterprise pricing انہی metered tokens کو ختم کرنے کے بجائے ان کے ساتھ فی seat charge شامل کرتی ہے۔ اگر آپ کے ذہن میں موازنہ کسی دوسرے plan کے بجائے دوسرے vendor سے ہے تو Claude اور ChatGPT APIs پر یکساں کام کی قیمتیں سے معلوم ہوتا ہے کہ کس معاملے میں کون سا سستا ہے۔ bill میں کوئی رقم اختیاری طور پر شامل نہیں کی جاتی۔ rate card یہ نہیں بتا سکتا کہ آپ کو مناسب قدر مل رہی ہے یا نہیں، کیونکہ اس میں tokens کی قیمت مقرر ہوتی ہے جبکہ آپ outcomes کی قدر کرتے ہیں۔

اس لیے outcome کی قیمت کا اندازہ لگائیں۔ اوپر والے session کی uncached لاگت 12.70 dollars تھی۔ اگر اس نے ایسا feature فراہم کیا جسے مکمل کرنے میں آپ کو 1 گھنٹہ لگتا، تو یہ سستا تھا۔ اگر اس نے 40 turns بے نتیجہ دائرے میں صرف کیے، تو انہی 12.70 dollars کے بدلے کچھ حاصل نہیں ہوا، اور مسئلہ rate نہیں تھا۔

یاد رکھنے والی بات یہی ہے۔ آپ کا bill value کے مطابق نہیں بلکہ tokens کے مطابق بڑھتا ہے۔ ایک ہی طوالت کے productive session اور wasted session کی لاگت یکساں ہوتی ہے۔ اسی لیے چار levers rate card سے زیادہ اہم ہیں: آپ فی token قیمت پر مذاکرات نہیں کر سکتے، لیکن یہ آپ طے کرتے ہیں کہ کام کے لیے کتنے tokens درکار ہوں گے۔

اس لیے dollars per completed task track کریں، dollars per month نہیں۔ اگر caching اور routing کو بہتر بنانے کے دوران یہ عدد کم ہو رہا ہے تو آپ کا setup بہتر ہو رہا ہے، چاہے monthly total بڑھ رہا ہو، کیونکہ total زیادہ کام کرنے کی وجہ سے بڑھ رہا ہے۔

آپ کا بل کم نہیں کرتا

کچھ مقبول مشورے بہت کم اثر رکھتے ہیں۔ ماڈل کو "مختصر جواب دیں" کہنے سے output کم ہو جاتا ہے، جبکہ مثال کے بل میں output صرف پانچ فیصد تھا۔ اپنے سوال کو مختصر کرنے سے 60,000 token کے context کے مقابلے میں چند سو tokens کی بچت ہوتی ہے۔ extended thinking بند کرنے سے صرف اسی صورت میں فائدہ ہوتا ہے جب thinking tokens آپ کے output کا واقعی نمایاں حصہ ہوں۔ usage block یہ بات واضح کر دیتا ہے، اس لیے آپ کو اندازہ لگانے کی ضرورت نہیں رہتی۔

بڑا context window بذاتِ خود اضافی لاگت نہیں بنتا۔ Claude 4.6 اور اس کے بعد کے versions میں، Haiku 5.5 کے سوا، مکمل one million token window کی billing standard per-token rate پر ہوتی ہے۔ اس لیے 900,000 token کی request کی فی token لاگت 9,000 token کی request کے برابر ہے۔ Haiku 5.5 اس سے مستثنیٰ ہے۔ اس میں prompt length کے مطابق قیمت مقرر ہوتی ہے، اور 100,000 tokens سے زیادہ کے prompt پر input، output اور cache کے لیے پانچ گنا زیادہ ادائیگی ہوتی ہے۔ چنانچہ input کی قیمت 0.10 سے بڑھ کر 0.50 dollars per million ہو جاتی ہے، جبکہ output کی قیمت 0.50 سے بڑھ کر 2.50 ہو جاتی ہے۔ ہر دوسرے موجودہ model میں window size قیمت مقرر نہیں کرتا۔ قیمت کا انحصار اس بات پر ہوتا ہے کہ آپ window میں کیا شامل کرتے ہیں۔

مزید دو امور کسی ایک session کے بجائے planning کا حصہ ہیں۔ اگر آپ کا استعمال روزانہ اور interactive ہے تو pay per token کا flat plan سے موازنہ کریں: API اور subscription cost کا موازنہ یہی حساب کرتا ہے۔ اگر flat plan بہتر ہو اور اسی دوران آپ کسی دوسرے vendor پر بھی غور کر رہے ہوں تو Claude اور ChatGPT plans کا یکساں قیمتوں کے ساتھ موازنہ دونوں کے لیے یہی موازنہ کرتا ہے۔ اگر کوئی agent کسی server پر unattended چل رہا ہو تو باقی tuning سے پہلے hard spend cap مقرر کریں۔ VPS پر AI agent کے لیے cost controls اسی موضوع کا احاطہ کرتا ہے۔ لاگت کے حجم کو سادہ انداز میں سمجھنے کے لیے ایک million Claude tokens سے حقیقت میں کیا حاصل ہوتا ہے rate card کو صفحات کے متن میں تبدیل کرتا ہے۔

FAQ

میرے Claude کے بل میں agent استعمال شروع کرنے کے بعد اتنا اضافہ کیوں ہوا؟

کیونکہ agent ہر سوال کے لیے متعدد requests بھیجتا ہے، اور ہر request میں اب تک کی پوری conversation شامل ہوتی ہے۔ Chat ہر سوال کے لیے ایک request بھیجتا ہے۔ Coding agent ہر step کے لیے ایک request بھیجتا ہے، اور ایک task کے لیے چالیس steps معمول کی بات ہے۔ ان تمام requests کے لیے پورے context کی billing ہوتی ہے، اس لیے 100,000 tokens پر ختم ہونے والے session کے لیے مجموعی طور پر 2 million سے زیادہ input tokens کی billing ہو سکتی ہے۔ اسے براہ راست دیکھنے کے لیے API response میں input_tokens اور cache_read_input_tokens پڑھیں۔

کیا prompt caching واقعی بل میں اتنی کمی کرتا ہے؟

عملی مثال میں اس نے session کی لاگت 12.70 dollars سے کم کر کے 2.48 dollars کر دی، کیونکہ Opus 5 میں cache read کی قیمت input rate کا دسواں حصہ ہے۔ بچت کا انحصار مکمل طور پر آپ کے hit rate پر ہوتا ہے۔ پانچ منٹ کے cache کے ساتھ یہ ایک ہی read کے بعد اپنی لاگت پوری کر لیتا ہے، کیونکہ write کی قیمت input کی 1.25 گنا اور read کی قیمت 0.1 گنا یا اس سے کم ہے۔ اگر ہر request کے آغاز کے قریب آپ کا prompt تبدیل ہوتا رہے تو آپ کو بالکل کوئی hit نہیں ملے گا، اور write premium بلا وجہ ادا کرنا پڑے گا۔ یہ فرض کرنے سے پہلے کہ caching کام کر رہی ہے، cache_read_input_tokens سے تصدیق کریں۔

کیا مجھے ہر کام کے لیے صرف Haiku استعمال کرنا چاہیے؟

نہیں۔ Haiku 4.5 کی قیمت فی million input tokens 1 dollars ہے، جبکہ Opus 5 کے لیے یہ قیمت 5 dollars ہے۔ اس لیے classification اور routing جیسے سادہ، زیادہ volume والے کاموں میں بچت حقیقی ہے۔ مشکل کام پر غلط جواب سے model کی بچت سے زیادہ لاگت آتی ہے، کیونکہ retry کی قیمت اور اپنے وقت کی لاگت بھی ادا کرنا پڑتی ہے۔ مؤثر pattern mixed استعمال ہے: mechanical turns کے لیے چھوٹا model، اور judgement درکار ہونے والے turn کے لیے frontier model۔

کیا API، Claude subscription سے سستا ہے؟

یہ اس بات پر منحصر ہے کہ آپ کا استعمال کتنا مستقل ہے۔ Subscription ایک مقررہ ماہانہ قیمت ہوتی ہے، جس کے ساتھ usage limits شامل ہوتی ہیں۔ API میں ceiling کے بغیر فی token ادائیگی ہوتی ہے۔ آپ کا استعمال کم ہو یا وقفے وقفے سے ہو تو یہ سستا پڑتا ہے، لیکن ہر working day زیادہ استعمال کی صورت میں مہنگا پڑتا ہے۔ Usage block سے روزانہ کے اوسط tokens لیں، انہیں اپنے model کے rate پر price کریں، اس رقم کو مہینے میں استعمال کے دنوں سے ضرب دیں، پھر اس ماہانہ رقم کا موازنہ plan price سے کریں۔ Entry tier کی قیمت Claude Pro کی قیمت اور اس کی usage limits آپ کو کہاں روکتی ہیں میں دی گئی ہے۔ اگر مجموعی رقم API کے حق میں ہو تو cancellation سے پہلے ادا کیے گئے موجودہ مہینے کا نقصان نہیں ہوتا، کیونکہ cancellation موجودہ billing period کے اختتام پر مؤثر ہوتی ہے اور اس وقت تک plan برقرار رہتا ہے۔ Plan ختم کرنا یا نچلے tier پر منتقل ہونا دونوں طریقوں کا احاطہ کرتا ہے۔