Claude tokens کیا ہیں؟ Code session کی لاگت

Claude میں tokens کیا ہوتے ہیں؟

Token اس متنی اکائی کو کہتے ہیں جسے Claude پڑھتا اور لکھتا ہے۔ یہ کسی لفظ کا ایک حصہ ہوتا ہے، اور تقریباً 3.5 English characters کے برابر ہوتا ہے۔ یہ عدد Anthropic کی اپنی glossary سے لیا گیا ہے۔ Spaces اور punctuation کو شمار کرنے کے بعد ہر لفظ کے لیے عموماً ایک سے زیادہ token درکار ہوتے ہیں۔ اسی لیے نثر کے 1,000 الفاظ میں عموماً 1,300 سے کافی زیادہ tokens ہوتے ہیں۔ Code میں ہر line کے حساب سے token استعمال زیادہ ہوتا ہے۔ Braces، operators، underscores اور indentation، English کے مقابلے میں ہر character کو زیادہ tokens میں تقسیم کرتے ہیں۔ چند سو lines والی source file میں عموماً کئی ہزار tokens ہوتے ہیں۔ اگر agent 2,000 lines والی file پڑھنے کا فیصلہ کرے تو نئی code کی ایک line لکھنے سے پہلے ہی اس پر پانچ ہندسوں کی token لاگت آ سکتی ہے۔

Tokenizers کے بارے میں دو باتیں اکثر الجھن پیدا کرتی ہیں۔ پہلی بات یہ ہے کہ tokenizer ہر model کے لیے مخصوص ہوتا ہے۔ July 2026 تک Opus 4.7 اور اس کے بعد کے versions، Sonnet 5، اور Fable 5 ایک نیا tokenizer استعمال کرتے ہیں۔ یہ پہلے کے Claude models کے مقابلے میں اسی text کے لیے تقریباً 30% زیادہ tokens بناتا ہے۔ درست اضافہ content کے لحاظ سے بدلتا ہے۔ اس سے tokens میں بنائی گئی ہر budget متاثر ہوتی ہے، اگرچہ per-token prices اس اضافے کے ساتھ نہیں بڑھیں۔ دوسری بات یہ ہے کہ tiktoken، جسے تقریباً ہر blog post استعمال کرتی ہے، OpenAI کا tokenizer ہے۔ یہ عام text میں Claude کے tokens کو تقریباً 15–20% کم شمار کرتا ہے، جبکہ code میں فرق اس سے بھی زیادہ ہوتا ہے۔ قابلِ اعتماد count صرف count_tokens endpoint فراہم کرتا ہے، جس کا ذکر نیچے کیا گیا ہے۔

آپ کے coding session کی لاگت کی وجہ

ہر Claude bill، خواہ وہ API invoice ہو یا subscription limit، آخرکار ایک ہی meter پر منحصر ہوتا ہے: اندر آنے والے tokens اور باہر جانے والے tokens۔ pricing page پر حساب سادہ دکھائی دیتا ہے: ہر million input tokens کے لیے اتنے dollars، اور ہر million output tokens کے لیے اتنے dollars۔ لیکن اس سے یہ واضح نہیں ہوتا کہ agentic coding session میں input meter توقع سے کہیں زیادہ تیزی سے چلتا ہے، کیونکہ ہر turn پر پوری conversation دوبارہ بھیجی جاتی ہے۔ میں پندرہ سال سے metered infrastructure فروخت کر رہا ہوں، اور tokens وہ پہلا meter ہے جس کے بارے میں میں نے دیکھا ہے کہ زیادہ تر customers حقیقی طور پر یہ نہیں بتا سکتے کہ اسے کیا چلا رہا ہے۔ یہ meter پڑھنے کا سبق ہے: agentic session میں input اور output میں کیا شمار ہوتا ہے، resend loop اتنا مہنگا کیوں ہے، prompt caching حساب کو کیسے بدل دیتی ہے، اور کون سے levers واقعی اس number کو تبدیل کرتے ہیں۔

ہر چیز input ہے: meter اصل میں کیا شمار کرتا ہے

لوگ سمجھتے ہیں کہ وہ Claude کے لکھے ہوئے code کی ادائیگی کرتے ہیں۔ agentic session میں یہ لاگت کا معمولی حصہ ہوتا ہے۔ input tokens، جن کی rate کم ہوتی ہے مگر volume بہت زیادہ ہوتا ہے، میں یہ شامل ہیں:

• system prompt۔ Claude Code کی اپنی harness instructions، نیز آپ کی CLAUDE.md اور memory files، session کے آغاز پر load ہوتی ہیں اور اس کے بعد ہر request میں موجود رہتی ہیں۔
• tool definitions۔ ہر tool schema جسے agent call کر سکتا ہے۔ آپ جو بھی MCP server مربوط کرتے ہیں وہ اس مستقل overhead میں اضافہ کرتا ہے۔ تاہم Claude Code اب default طور پر مکمل MCP tool definitions کو مؤخر کرتا ہے، اس لیے کسی tool کے پہلی بار استعمال ہونے تک context میں صرف tool names موجود رہتے ہیں۔ اس سے لاگت کم ہوتی ہے، مگر ختم نہیں ہوتی۔
• agent کی پڑھی ہوئی ہر file۔ کسی source file کا Read پورا file context میں شامل کر دیتا ہے، اور وہ وہیں موجود رہتا ہے۔
• ہر tool result۔ Test runs، grep output، terminal spew، build logs، یہ سب input tokens کی صورت میں واپس آتے ہیں۔ اگر failing test suite 8,000 lines print کرے تو اس کی لاگت ایک مختصر کتاب جتنے tokens کی ہو سکتی ہے۔
• اب تک کی پوری conversation، ہر turn پر دوبارہ بھیجی جاتی ہے۔ یہ نکتہ اپنے الگ section کا مستحق ہے۔

ہر بار دوبارہ بھیجنے کی لاگت کوئی شمار نہیں کرتا

Claude API بے حالت ہے۔ اسے requests کے درمیان آپ کا session یاد نہیں رہتا، کیونکہ کوئی چیز یاد نہیں رہتی۔ چنانچہ turn 2 پر client، turn 1، اس کا response اور آپ کا نیا message دوبارہ بھیجتا ہے۔ turn 50 پر یہ turns 1 سے 49 تک، پڑھی گئی ہر file، ہر tool result، ہر diff اور turn 50 دوبارہ بھیجتا ہے۔ model ہر بار مکمل transcript دوبارہ پڑھتا ہے، اور دوبارہ پڑھے جانے والے ان تمام tokens کو input کے طور پر bill کیا جاتا ہے۔

نتیجہ یہ ہے کہ session کے دورانیے کے ساتھ ہر turn کی لاگت تقریباً خطی طور پر بڑھتی ہے، جبکہ پورے session کی مجموعی لاگت تقریباً مربعی طور پر بڑھتی ہے۔ turn 3 پر جس message کی لاگت نصف cent تھی، وہی ایک سطری سوال turn 60 پر اس سے 20 گنا زیادہ مہنگا ہو سکتا ہے، کیونکہ اس کے ساتھ 60 turns کا تمام سابقہ مواد دوبارہ بھیجا جا رہا ہوتا ہے۔ یہی وہ بنیادی حقیقت ہے جو زیادہ تر "میرا bill اتنا زیادہ کیوں آیا؟" tickets کی وضاحت کرتی ہے۔ یہ صرف Claude کی خصوصیت نہیں ہے؛ ہر ایسا LLM product جو بظاہر stateful محسوس ہوتا ہے، دراصل پس منظر میں resend loop کے ساتھ ایک stateless API ہوتا ہے۔

Output: جو آپ دیکھتے ہیں، اور وہ سوچ بھی جو آپ کو نظر نہیں آتی

Output tokens موجودہ lineup میں input rate کے مقابلے میں پانچ گنا مہنگے ہیں ($5/$25 on Opus 4.8، $3/$15 sticker on Sonnet 5، $1/$5 on Haiku 4.5، July 2026 کے مطابق)۔ Output میں Claude کا تیار کردہ متن اور code، نیز thinking tokens شامل ہوتے ہیں: یہ وہ داخلی reasoning ہے جو model جواب دینے سے پہلے کرتا ہے۔ یہاں دو باتیں اہم ہیں۔ Thinking کی billing output rates کے مطابق ہوتی ہے اور یہ max_tokens میں شمار ہوتی ہے۔ اگر API response stop_reason: "max_tokens" کے ساتھ ختم ہو جائے اور جواب truncated ہو، تو اکثر اس کا مطلب ہوتا ہے کہ جواب تیار ہونے سے پہلے thinking نے budget استعمال کر لیا۔ موجودہ models میں reasoning summary شاید بالکل دکھائی نہ دے؛ Opus 4.8، Sonnet 5 اور Fable 5 اسے default طور پر شامل نہیں کرتے، لیکن thinking پھر بھی ہوئی ہوتی ہے اور اس کی billing بھی ہوتی ہے۔ نظر نہ آنا مفت ہونے کے برابر نہیں ہے۔

Claude Code extended thinking کو default طور پر فعال کرتا ہے، کیونکہ یہ multi-step کام میں قابلِ پیمائش بہتری لاتا ہے، اور default budget فی request دسیوں ہزار tokens تک جا سکتا ہے۔ آسان tasks کے لیے آپ اسے کم کر سکتے ہیں: /effort کے ذریعے یا /model میں effort level کم کریں، یا /config میں thinking settings تبدیل کریں۔ یہ حقیقی cost lever ہے، محض وہم نہیں۔

Prompt caching حساب بدل دیتا ہے

Prompt caching کی وجہ سے resend loop سب کے اخراجات ختم نہیں کرتا۔ API آپ کے prompt، system prompt، tool definitions اور conversation history کے ایک مستحکم ابتدائی حصے کو cache کر سکتی ہے، پھر اگلی request پر اسے قیمت کے ایک حصے میں فراہم کر سکتی ہے۔ July 2026 تک multipliers یہ ہیں: cache write کی لاگت base input rate سے 1.25× ہے (1-hour variant کے لیے 2×)، جبکہ cache read کی لاگت 0.1× ہے۔ Writes اضافی قیمت پر ہوتے ہیں؛ reads پر 90% رعایت ملتی ہے۔ صرف ایک read ہی 5-minute write کی اضافی لاگت سے زیادہ کی تلافی کر دیتا ہے۔

Claude Code آپ کے لیے caching manage کرتا ہے، اور صحت مند session میں اس بڑے resend کا تقریباً پورا حصہ cache سے فراہم ہوتا ہے۔ لیکن default cache آخری استعمال کے بعد صرف پانچ منٹ تک برقرار رہتا ہے۔ اگر کافی کے لیے جائیں اور وقفہ طویل ہو جائے، واپس آ کر message بھیجیں، تو cache expire ہو چکا ہوتا ہے۔ اس صورت میں پورا جمع شدہ prefix 0.1× پر read ہونے کے بجائے 1.25× پر دوبارہ write ہوتا ہے۔ 150K-token session میں ایک cold turn کی لاگت ایک درجن سے زیادہ warm turns کی لاگت سے بڑھ سکتی ہے۔ یہ وہ بظاہر غیر متوقع نتیجہ ہے جسے ذہن میں رکھنا چاہیے: idle رہنے کے بعد resume کرنے کا طریقہ continuous work سے زیادہ مہنگا ہو سکتا ہے، کیونکہ TTL سے زیادہ ہر idle gap آپ کے اگلے turn کو سستے read سے مہنگے re-write میں بدل دیتا ہے۔ کام کو الگ الگ stints میں کریں؛ ایک بڑے session میں ہر دس منٹ بعد ایک message بھیجتے نہ رہیں۔

اگر آپ API کو اپنی VPS پر موجود application سے call کر رہے ہیں، تو یہ سہولت خودکار طور پر نہیں ملتی۔ اس صورت میں عام طور پر خود پیدا کیا گیا مسئلہ یہ ہوتا ہے کہ system prompt میں timestamp یا request ID interpolate کر دی جاتی ہے۔ اس سے ہر request پر prefix کے bytes تبدیل ہو جاتے ہیں اور caching خاموشی سے غیر فعال ہو جاتی ہے۔ اس کی علامت یہ ہے کہ یکساں دکھائی دینے والی calls میں usage.cache_read_input_tokens مسلسل صفر رہتا ہے۔

فارمولہ، عملی مثال کے ساتھ

جو لوگ یہ کہتے ہیں کہ "ایک session کی لاگت $X ہے"، ان کی بات نظرانداز کریں۔ Sessions کی لاگت میں دو orders of magnitude تک فرق ہو سکتا ہے۔ قابلِ اعتماد چیز یہ formula ہے:

turn cost = (uncached input      x base input price)
          + (cache writes        x 1.25 x base input price)
          + (cache reads         x 0.10 x base input price)
          + (output incl. thinking x output price)

session cost = sum over all turns

Claude Opus 4.8 کی عملی مثال دیکھیں۔ July 2026 تک اس کی قیمت فی million input tokens $5 اور فی million output tokens $25 ہے۔ ایک mid-session turn میں accumulated context کے 80,000 tokens شامل ہیں: 75,000 cache سے پڑھے گئے، 3,000 نئے لکھے گئے، 2,000 uncached fresh input تھے، اور 1,500 output tokens تھے، جن میں thinking بھی شامل تھی۔

• Cache reads: 75,000 × $0.50/M = $0.0375
• Cache writes: 3,000 × $6.25/M = $0.019
• Uncached input: 2,000 × $5/M = $0.010
• Output: 1,500 × $25/M = $0.0375

اس turn کی لاگت تقریباً $0.10 ہے؛ اسی طرح کے 50 turns کی لاگت تقریباً $5 ہوگی۔ اب یہی turn cache expire ہونے کے بعد دیکھیں: پورے 80,000 tokens کو $6.25/M کے حساب سے دوبارہ لکھنے کی لاگت output سے پہلے ہی $0.50 ہے۔ یہ اسی کام کے لیے مکمل warm turn کی لاگت سے تقریباً پانچ گنا زیادہ ہے۔ یہی فرق caching کی پوری اہمیت کو ایک عدد میں ظاہر کرتا ہے۔ Vendors کا موازنہ کرنے کا ایماندار طریقہ بھی یہی چار سطریں ہیں، کیونکہ sticker rates cache reads اور thinking کو مکمل طور پر نظرانداز کرتے ہیں۔ مزید یہ کہ انہیں 3 حقیقی jobs پر چلانے سے معلوم ہوتا ہے کہ Claude کا bill OpenAI کے bill سے زیادہ یا کم کہاں آتا ہے۔

اگر آپ کسی ایک turn کے بجائے خود billing unit کو سمجھنا چاہتے ہیں تو یہ دیکھیں کہ 1 million tokens صفحات، files اور dollars میں کتنے بنتے ہیں۔ یہ اسی حساب کو ایک درجے اوپر لے جاتا ہے۔ یہ پیش گوئی نہیں بلکہ calibration کے لیے ہے: Anthropic کے شائع کردہ اعداد و شمار کے مطابق، July 2026 تک enterprise Claude Code deployments میں فی active day فی developer اوسط لاگت تقریباً $13 ہے، جبکہ ماہانہ لاگت $150–250 ہے۔ 90% users کی یومیہ لاگت $30 سے کم رہتی ہے۔ آپ کی اصل لاگت model choice، session hygiene اور codebase size پر منحصر ہے۔ اسی لیے نیچے دیے گئے levers اہم ہیں۔

اپنا استعمال دیکھنا

Claude Code میں کمانڈ /usage ہے (/cost اب بھی کام کرتا ہے، یہ ایک alias ہے)۔ اوپر موجود Session بلاک موجودہ session کے token statistics اور مقامی طور پر حساب کیا گیا cost estimate دکھاتا ہے؛ subscription plans پر یہی اسکرین plan-limit bars بھی دکھاتی ہے اور حالیہ استعمال کو skills، subagents، plugins اور انفرادی MCP servers سے منسوب کر کے breakdown فراہم کرتی ہے۔ API accounts کے لیے مستند billing معلومات Claude Console کے usage page میں ہوتی ہیں؛ CLI کا عدد صرف estimate ہے۔ /context ایک رنگین grid بناتا ہے جس میں context window میں موجود مواد، system prompt، tools، MCP definitions، files اور history دکھائے جاتے ہیں۔ یہ پھولے ہوئے CLAUDE.md یا بہت زیادہ messages بھیجنے والے MCP server کی شناخت کا تیز ترین طریقہ ہے؛ مکمل per-item breakdown دیکھنے کے لیے all فراہم کریں۔

API سے ہر response میں واضح طور پر بتایا جاتا ہے کہ کیا ہوا:

response = client.messages.create(model="claude-sonnet-5", max_tokens=2048,
                                  messages=messages)
u = response.usage
total_prompt = u.input_tokens + u.cache_creation_input_tokens + u.cache_read_input_tokens
print(f"uncached={u.input_tokens} written={u.cache_creation_input_tokens} "
      f"read={u.cache_read_input_tokens} output={u.output_tokens}")

یاد رکھیں کہ input_tokens صرف uncached remainder ہے؛ prompt کا حقیقی حجم تینوں input fields کے مجموعے کے برابر ہوتا ہے۔ ایک agent جو ایک گھنٹے تک چلتا رہا اور input_tokens: 4000 دکھا رہا ہے، سستا نہیں ہے؛ باقی 200,000 tokens cache سے فراہم کیے گئے تھے۔ request بھیجنے سے پہلے اندازہ لگانے کے لیے token-counting endpoint استعمال کریں۔ اسے call کرنا مفت ہے، اس کی rate limit الگ ہے، اور یہ آپ کے نامزد کردہ model کے tokenizer سے count کرتا ہے۔ نتیجے کو قریباً درست estimate سمجھیں؛ billing حقیقی request کی بنیاد پر ہوتی ہے:

count = client.messages.count_tokens(model="claude-sonnet-5",
                                     messages=[{"role": "user", "content": big_file}])
print(count.input_tokens)

مندرجہ بالا وجہ سے کبھی tiktoken نہ کریں۔

سبسکرپشن پلان بمقابلہ pay-as-you-go

اس گائیڈ میں طریقۂ کار ہر جگہ یکساں ہے؛ فرق صرف بلنگ کا ہے۔ API key کے ساتھ Anthropic، شائع شدہ rates کے مطابق، ہر token کی بنیاد پر pay-as-you-go بلنگ کرتا ہے۔ اوپر دی گئی ہر رقم حقیقی لاگت ہے۔ یہ meter زیادہ تر لوگوں کی توقع سے پہلے شروع ہو جاتا ہے، کیونکہ متبادل کے طور پر کوئی free tier موجود نہیں۔ صرف signup پر ملنے والا ایک چھوٹا credit اور چند ایسے endpoints ہیں جن کی بلنگ نہیں ہوتی۔ یہی وہ چیز ہے جو card کو account پر محفوظ کرنے سے پہلے نیا API account حقیقتاً حاصل کرتا ہے۔ Claude subscription (Pro، Max، Team، Enterprise) میں Claude Code کا استعمال اس کے بجائے آپ کے plan میں شامل allowance سے منہا ہوتا ہے۔ July 2026 تک اس میں پانچ گھنٹے کی rolling session window اور ایک weekly window شامل ہے۔ یہ windows مختلف models اور claude.ai chat کے درمیان مشترک ہیں۔ /usage dollar figure صرف معلوماتی ہے، bill نہیں۔

جب کوئی window مکمل طور پر استعمال ہو جائے تو آپ کو reset time کے ساتھ "آپ اپنی session limit تک پہنچ چکے ہیں" یا "آپ اپنی weekly limit تک پہنچ چکے ہیں" دکھائی دے گا۔ /model کے ذریعے model تبدیل کرنے سے access بحال نہیں ہوگا، کیونکہ windows تمام models کے درمیان مشترک ہیں۔ یہ windows اس account سے وابستہ ہوتی ہیں جسے آپ استعمال کر رہے ہیں، نہ کہ اس client سے جس میں آپ اس وقت کام کر رہے ہیں۔ اگر آپ ابھی یہ معلوم کر رہے ہیں کہ Linux پر مقامی طور پر کیا چلتا ہے اور ہر surface کو کون سا plan cover کرتا ہے تو یہ بات اہم ہے۔ آپ نے حقیقتاً ان دونوں میں سے کون سی window مکمل کی ہے، اسی سے انتظار کی مدت اور اس دوران کیے جانے والے مفید اقدامات طے ہوتے ہیں۔ اس لیے درمیانِ کام limit تک پہنچنے پر اپنے اختیارات جاننا مفید ہے۔

Plans اختیاری طور پر usage credits فعال کر سکتے ہیں۔ /usage-credits کے ذریعے ان credits کا انتظام کر کے مقررہ ceiling سے زیادہ usage خریدا جا سکتا ہے۔ میں جان بوجھ کر plan quotas درج نہیں کر رہا، کیونکہ اس موضوع میں یہ سب سے زیادہ تیزی سے تبدیل ہونے والی numbers ہیں۔ اس کے بجائے claude.com/pricing اور اپنی /usage bars دیکھیں۔ Subscription استعمال کرتے وقت بھی token mechanics اہم رہتے ہیں۔ غیر مؤثر session آپ کی window اسی طرح ضائع کرتا ہے جیسے وہ dollars ضائع کرتا۔ Subscription کے لیے دیکھیں کہ آپ کے استعمال کے لیے کون سا Claude plan موزوں ہے۔

جو طریقے واقعی مؤثر ہیں

• Agent کے پڑھنے کا دائرہ محدود کریں۔ "auth.py میں validation bug ٹھیک کریں" کہنے پر ایک فائل پڑھی جاتی ہے؛ "اس codebase کو بہتر بنائیں" کہنے پر چالیس فائلیں پڑھی جاتی ہیں۔ CLAUDE.md کو مختصر رکھیں، کیونکہ یہ ہر session میں load ہوتا ہے۔ اسے ضروری ہدایات تک محدود رکھیں، اور workflow-specific ہدایات ان skills میں منتقل کریں جو ضرورت کے وقت load ہوں۔
• واضح اور مختصر رہیں۔ غیر متعلقہ tasks کے درمیان /clear کریں، کیونکہ پرانا context ہر اگلے message کے ساتھ دوبارہ بھیجا جاتا ہے اور اس کی billing بھی دوبارہ ہوتی ہے۔ ایک طویل task کے دوران /compact Focus on the failing tests and the diff سابقہ گفتگو کو مختصر کرتا رہتا ہے اور آپ کو quadratic curve سے دور رکھتا ہے۔
• ماڈل کا مناسب سائز منتخب کریں۔ زیادہ تر coding کے لیے Sonnet کافی ہے۔ July 2026 تک introductory pricing میں اس کی قیمت $2/$10 فی million tokens ہے ($3/$15 sticker price)، جبکہ Opus کی قیمت $5/$25 ہے۔ Haiku کی قیمت $1/$5 ہے اور log triage جیسے mechanical subagent کاموں کے لیے موزوں ہے۔ دوسری طرف Fable 5 کی قیمت $10/$50 ہے، یعنی meter کے دونوں حصوں پر Opus سے دوگنی۔ اس لیے routine کام کے لیے اسے منتخب رکھنے سے پہلے یہ جاننا مفید ہے کہ کون سے کام واقعی اس قیمت کے متقاضی ہیں۔ /model session کے دوران model تبدیل کرتا ہے۔
• طویل output کو پہلے filter کریں۔ ایسا hook جو Claude کے output دیکھنے سے پہلے test run کو صرف failures تک محدود کر دے، tool result کے 20,000 tokens کو 300 tokens میں بدل دیتا ہے۔ یہ اسی turn کو مستقبل میں دوبارہ بھیجے جانے پر بھی ہر بار یہی کمی کرتا ہے۔
• غیر interactive کام batch میں چلائیں۔ اپنی API pipelines، classification، bulk review اور nightly jobs کے لیے Batches API استعمال کریں۔ یہ asynchronous delivery کے بدلے وہی models 50% کم قیمت پر چلاتا ہے۔
• Cache clock کو ملحوظ رکھیں۔ مسلسل دورانیوں میں کام کریں۔ VPS پر tmux میں detached Claude Code session idle ہونے کے دوران کوئی لاگت نہیں رکھتا؛ tokens صرف turn چلنے پر خرچ ہوتے ہیں۔ لیکن idle وقت warm cache کو برقرار نہیں رکھتا، اس لیے اگلے turn میں context دوبارہ لکھنے کی لاگت ادا کرنا پڑتی ہے۔

FAQ

Claude Code میں coding session کتنے tokens استعمال کرتا ہے؟

اس کی کوئی مقررہ تعداد نہیں ہے۔ جب files اور history جمع ہو جائیں تو session کے دوران ایک turn میں عموماً دسیوں ہزار prompt tokens شامل ہو جاتے ہیں، جبکہ ایک working session لاکھوں tokens تک پہنچ سکتا ہے۔ ان میں سے زیادہ تر tokens cache سے فراہم ہوتے ہیں، جس کی لاگت بنیادی شرح کے تقریباً ایک دسویں حصے کے برابر ہوتی ہے۔ موازنے کے لیے، Anthropic کے جولائی 2026 تک شائع کردہ enterprise اعداد و شمار کے مطابق فی developer فی active day اوسط لاگت تقریباً $13 ہے، جبکہ 90% users کی لاگت $30 سے کم رہتی ہے۔ اپنے session میں /usage چلائیں؛ اسے پانچ منٹ monitor کرنا کسی بھی شائع شدہ اوسط سے زیادہ مفید ہے۔

جب مجھے نظر نہ آئیں تو کیا thinking tokens کی بھی لاگت آتی ہے؟

ہاں۔ thinking tokens کو output tokens کے طور پر، یعنی مہنگی شرح پر، bill کیا جاتا ہے اور یہ max_tokens میں شمار ہوتے ہیں۔ موجودہ models ان tokens کی billing اس وقت بھی کرتے ہیں جب interface reasoning summary کو display میں شامل نہ کرے۔ اگر visible answer مکمل ہونے سے پہلے response stop_reason: "max_tokens" کے ساتھ truncate ہو جائے تو غالب امکان ہے کہ thinking نے budget استعمال کر لیا ہے۔ Claude Code میں ایسے tasks کے لیے جنہیں گہری reasoning درکار نہ ہو، effort level کم کرنے کے لیے /effort استعمال کریں۔

طویل Claude Code session میں ہر message کی لاگت کیوں بڑھ جاتی ہے؟

کیونکہ API stateless ہے۔ ہر turn میں پوری conversation، ہر file read، ہر tool result اور سابقہ exchange کو billed input کے طور پر دوبارہ بھیجا جاتا ہے۔ اس لیے turn 50 میں turns 1 سے 49 تک کا تمام data شامل ہوتا ہے۔ Prompt caching بار بار آنے والے prefix کو بنیادی input price کے تقریباً ایک دسویں حصے پر فراہم کرتی ہے، لیکن prefix خود مسلسل بڑا ہوتا رہتا ہے۔ اگر کوئی idle gap cache TTL سے زیادہ ہو جائے تو اگلا turn full-price rewrite میں تبدیل ہو جاتا ہے۔ /compact history کو مختصر کرتا ہے؛ /clear اسے reset کرتا ہے۔

میں اپنے Claude token usage اور cost کی جانچ کیسے کروں؟

Claude Code میں /usage session کے token statistics، مقامی cost estimate اور subscriptions میں plan-limit bars دکھاتا ہے (/cost اس کا alias ہے)؛ /context دکھاتا ہے کہ window میں کیا data جگہ بھر رہا ہے۔ مستند API billing کے لیے Claude Console میں usage page استعمال کریں۔ اپنے code میں response.usage پڑھیں؛ input_tokens، cache_creation_input_tokens اور cache_read_input_tokens کو جمع کرنے سے prompt کا حقیقی size ملتا ہے۔ پہلے سے estimate کرنے کے لیے count_tokens endpoint استعمال کریں، tiktoken کو کبھی استعمال نہ کریں۔