SSD Nodes Learn
Mga Gabay Matt ConnorNi Matt Connor · Na-update 2026-07-24

Ano ang tokens sa Claude at bakit mahal?

Alamin kung bakit ang isang Claude Code turn ay gumagamit ng 80,000 tokens at kung bakit tumataas ang gastos pagkatapos ng five idle minutes sa session.

Ano ang mga token sa Claude?

Ang token ay ang unit ng text na binabasa at sinusulat ng Claude: isang fragment ng salita, na humigit-kumulang 3.5 English characters. Ang figure na ito ay mula sa glossary ng Anthropic, at lumalabas na higit sa isang token bawat salita kapag kasama na ang mga space at punctuation. Dahil dito, ang isang libong salita ng prose ay lampas sa 1,300 tokens. Mas mabigat ang token usage sa code bawat linya: ang mga braces, operators, underscores, at indentation ay naghahati sa mas maraming tokens bawat character kumpara sa English. Ang isang source file na may ilang daang linya ay karaniwang umaabot sa ilang libong tokens. Ang isang 2,000-line file na babasahin ng agent ay nangangailangan na agad ng five-figure token purchase bago pa man makapagsulat ng bagong code.

Dalawang bagay tungkol sa mga tokenizer ang nakakalito sa mga user. Una, ang mga ito ay model-specific. As of July 2026, ang Opus 4.7 at mas bago, Sonnet 5, at Fable 5 ay gumagamit ng mas bagong tokenizer. Ang tokenizer na ito ay gumagawa ng halos 30% na mas maraming tokens para sa parehong text kumpara sa mga naunang Claude models (nag-iiba ang eksaktong pagtaas depende sa content). Dahil dito, nagbabago ang token budget kahit hindi tumaas ang per-token prices. Pangalawa, ang tiktoken, ang library na madalas gamitin sa mga blog post, ay ang tokenizer ng OpenAI. Nagbibigay ito ng undercount para sa Claude nang halos 15–20% sa ordinaryong text, at mas malaki ang discrepancy sa code. Ang tanging mapagkakatiwalaang count ay ang count_tokens endpoint, na tatalakayin sa ibaba.

Bakit ganito kamahal ang iyong coding session

Ang bawat Claude bill, maging API invoice man o subscription limit, ay nakadepende sa isang metro: tokens in, tokens out. Mukhang simple ang pricing page: ganito ang halaga kada isang milyon na input tokens, at ganito naman ang output. Ang hindi sinasabi nito ay sa isang agentic coding session, mas mabilis tumakbo ang input side kaysa sa inaasahan. Nangyayari ito dahil ang buong conversation ay muling ipinapadala sa bawat turn. Labinlimang taon na akong nagbebenta ng metered infrastructure, at ang tokens ang unang metro na nakita ko kung saan hindi talaga masabi ng maraming customer kung ano ang nagpapataas ng gastos. Ito ang aral sa pagbabasa ng metro: ano ang itinuturing na input at output sa isang agentic session, bakit mahal ang resend loop, paano binabago ng prompt caching ang kalkulasyon, at aling mga lever ang tunay na nakakaapekto sa halaga.

Lahat ay input: ang aktwal na binibilang ng meter

Inaakala ng marami na ang binabayaran nila ay ang code na isinusulat ni Claude. Sa isang agentic session, maliit na bahagi lang ito ng kabuuang gastos. Ang input tokens — na may mas murang rate pero mas malaking volume — ay kinabibilangan ng:

  • Ang system prompt. Ang mga harness instructions ng Claude Code, pati na ang iyong CLAUDE.md at memory files, na niloload sa simula ng session at kasama sa bawat request pagkatapos nito.
  • Tool definitions. Bawat tool schema na maaaring i-call ng agent. Ang bawat MCP server na ikokonekta mo ay nagdaragdag sa fixed overhead na ito — bagaman ang Claude Code ay nagdedefer na ng full MCP tool definitions by default, kaya pangalan lang ng tool ang nasa context hangga't hindi ito unang ginagamit, na nagpapababa ngunit hindi nag-aalis sa gastos.
  • Bawat file na binabasa ng agent. Ang isang Read ng isang source file ay naglalagay sa buong file sa context, at mananatili ito doon.
  • Bawat tool result. Test runs, grep output, terminal spew, build logs — lahat ng ito ay bumabalik bilang input tokens. Ang isang failing test suite na nag-print ng 8,000 lines ay katumbas na ng bayad para sa isang maliit na libro.
  • Ang buong conversation hanggang sa kasalukuyan, na muling ipinapadala sa bawat turn. Dapat itong magkaroon ng sariling seksyon.

Ang sanhi ng lumalaking gastos sa bawat turn

Ang Claude API ay stateless. Hindi nito natatandaan ang iyong session sa pagitan ng mga request — walang anumang memorya ang system. Kaya sa turn 2, ipinapadala ng client ang turn 1, ang response nito, at ang iyong bagong message. Sa turn 50, muling ipinapadala ang turn 1 hanggang 49 — bawat file read, bawat tool result, bawat diff — kasama ang turn 50. Binabasa muli ng model ang buong transcript sa bawat pagkakataon, at ang bawat token na binasa ay sisingilin bilang input.

Ang resulta: ang cost per turn ay lumalaki nang linear base sa haba ng session, at ang total session cost ay lumalaki nang quadratic. Ang isang message na nagkakahalaga ng kalahating sent sa turn 3 ay maaaring magkakahalaga ng dalawampung beses nito sa turn 60 para sa parehong isang-linya na tanong, dahil dala nito ang sixty turns ng data. Ito ang pangunahing dahilan sa karamihan ng mga ticket na "bakit ang taas ng bill ko," at hindi ito quirk ng Claude — ang bawat LLM product na tila stateful ay isang stateless API na may resend loop sa ilalim.

Output: ang nakikita mo, pati ang hindi mo nakikita

Ang output tokens ang pinakamahal — limang beses ang rate nito kumpara sa input sa kasalukuyang lineup ($5/$25 sa Opus 4.8, $3/$15 sa Sonnet 5, $1/$5 sa Haiku 4.5, as of July 2026). Kasama sa output ang text at code na generate ng Claude, at ang thinking tokens: ang internal reasoning na ginagawa ng model bago sumagot. May dalawang mahalagang katotohanan dito. Ang thinking ay sisingilin sa output rates at kasama sa max_tokens — ang isang API response na nagtatapos sa stop_reason: "max_tokens" at ang isang truncated na sagot ay madalas na nangangahulugang naubos ng thinking ang budget bago pa ang sagot. At sa mga kasalukuyang model, maaaring hindi talaga ipakita ang reasoning summary — ang Opus 4.8, Sonnet 5, at Fable 5 ay hindi ito ipinapakita by default — pero nangyari pa rin ang thinking at sisingilin pa rin ito. Ang invisible ay hindi libre.

Naka-enable ang extended thinking sa Claude Code by default dahil sinusukat na nagpapabuti ito sa multi-step work, at ang default budget ay maaaring umabot sa tens of thousands ng tokens bawat request. Sa mas simpleng mga task, maaari itong babaan: i-lower ang effort level gamit ang /effort o sa /model, o i-adjust ang thinking settings sa /config. Ito ay isang tunay na cost lever, hindi isang superstition.

Binabago ng prompt caching ang kalkulasyon

Dahil sa prompt caching kaya hindi masyadong mahal ang paulit-ulit na pag-send ng request. Maaaring i-cache ng API ang stable na prefix ng iyong prompt — system prompt, tool definitions, at conversation history — at sa susunod na request ay ibibigay ito sa mas mababang presyo. Simula noong July 2026, ito ang mga multiplier: ang cache write ay nagkakahalaga ng 1.25× ng base input rate (2× para sa 1-hour variant), at ang cache read ay 0.1× lamang. Mas mahal ang writes; may 90% discount naman ang reads. Ang isang read ay sapat na para mabawi ang premium sa 5-minute write.

Pinamamahalaan ng Claude Code ang caching para sa iyo, at sa isang maayos na session, halos lahat ng malalaking resend ay galing sa cache. Ngunit ang default cache ay tumatagal lamang ng five minutes mula sa huling paggamit. Kung matagal kang lumayo, pagbalik mo at pag-send ng message — expired na ang cache, at ang buong accumulated prefix ay muling isusulat (re-written) sa 1.25× sa halip na basahin (read) sa 0.1×. Sa isang 150K-token session, ang isang cold turn na ito ay mas mahal kaysa sa dose-dosena ng warm turns. Ito ang mahalagang konsepto: ang paghinto at pagpapatuloy ay maaaring mas mahal kaysa sa tuloy-tuloy na trabaho, dahil ang bawat gap na lumampas sa TTL ay gagawing mahal na re-write ang iyong susunod na turn mula sa isang murang read. Gawin ang trabaho nang tuloy-tuloy; huwag magpadala ng malalaking session nang paisa-isang message kada sampung minuto.

Kung tinatawag mo ang API mula sa iyong sariling application sa isang VPS, hindi mo makukuha ang mga benepisyong ito nang libre — at ang karaniwang pagkakamali ay ang paglalagay ng timestamp o request ID sa loob ng system prompt. Binabago nito ang prefix bytes sa bawat request at tahimik na bina-block ang caching. Malalaman mong may problema kung ang usage.cache_read_input_tokens ay nananatiling zero sa mga magkakatulad na calls.

Ang formula, kasama ang isang worked example

Huwag maniwala sa sinumang nagsasabi na "ang isang session ay nagkakahalaga ng $X." Nag-iiba ang presyo ng mga session nang hanggang dalawang order of magnitude. Ang mahalaga ay ang formula na ito:

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

Worked example gamit ang Claude Opus 4.8, na sa July 2026 ay $5 bawat isang milyong input tokens at $25 bawat isang milyong output tokens. Isang mid-session turn na may 80,000 tokens ng accumulated context: 75,000 ang binasa mula sa cache, 3,000 ang bagong isinulat, 2,000 ang uncached fresh input, at 1,500 output tokens kasama ang 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

Humigit-kumulang $0.10 para sa turn na ito; kung may limampung turn na katulad nito, aabot ito sa $5. Ngayon, gawin ang parehong turn pagkatapos ma-expire ang cache: ang buong 80,000 tokens na muling isinulat sa $6.25/M ay $0.50 bago ang output — halos limang beses ang laki kumpara sa buong warm turn para sa parehong trabaho. Ang gap na iyon ang kabuuan ng caching sa isang numero.

Para sa calibration sa halip na prediction: Ang mga inilathalang figure ng Anthropic para sa enterprise Claude Code deployments, base sa July 2026, ay may average na $13 bawat developer bawat active day — $150–250 bawat buwan — kung saan 90% ng mga user ay nananatili sa ilalim ng $30 bawat araw. Ang iyong gastos ay nakadepende sa model choice, session hygiene, at codebase size, kung kaya't mahalaga ang mga lever sa ibaba.

Pagtingin sa iyong usage

Sa Claude Code, ang command ay /usage (gumagana pa rin ang /cost — isa itong alias). Ang Session block sa itaas ay nagpapakita ng token statistics at local cost estimate para sa kasalukuyang session; para sa mga subscription plan, ang parehong screen ay nagpapakita ng iyong plan-limit bars at breakdown ng usage para sa mga skills, subagents, plugins, at mga indibidwal na MCP server. Para sa authoritative billing sa mga API account, ang usage page sa Claude Console ang source of truth — ang figure sa CLI ay isang estimate lamang. Ang /context ay nagpapakita ng colored grid ng kung ano ang kumakain sa context window — system prompt, tools, MCP definitions, files, at history — at ito ang pinakamabilis na paraan para makita ang bloated na CLAUDE.md o isang chatty na MCP server; gamitin ang all para makita ang buong breakdown bawat item.

Mula sa API, ang bawat response ay nagsasabi ng eksaktong nangyari:

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}")

Tandaan na ang input_tokens ay ang uncached remainder lamang — ang tunay na prompt size ay ang kabuuan ng tatlong input fields. Ang agent na tumakbo nang isang oras na nagpapakita ng input_tokens: 4000 ay hindi mura; ang ibang 200,000 tokens ay galing sa cache. Para mag-estimate bago mag-send, gamitin ang token-counting endpoint — libre itong i-call, may sariling rate limit, at nagbibilang gamit ang tokenizer ng anumang model na itatalaga mo (ituring ang resulta bilang malapit na estimate; ang billing ay base sa real request):

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

Huwag na huwag gagamit ng tiktoken, dahil sa dahilan na nabanggit sa itaas.

Subscription plans versus pay-as-you-go

Pareho ang mechanics sa guide na ito kahit saan; ang settlement lang ang nagkakaiba. Gamit ang API key, ang Anthropic ay nagbi-bill ng pay-as-you-go, per token, base sa published rates — ang bawat numero sa itaas ay totoong pera. Sa Claude subscription (Pro, Max, Team, Enterprise), ang Claude Code usage ay kumukuha sa allowance ng iyong plan: simula July 2026, ito ay isang rolling five-hour session window plus isang weekly window, na shared sa mga models at sa claude.ai chat, at ang /usage dollar figure ay informational lamang at hindi bill. Kapag naubos ang window, makikita mo ang "You've hit your session limit" o "You've hit your weekly limit" kasama ang reset time — at ang pagpapalit ng models gamit ang /model ay hindi magbabalik ng access, dahil shared ang mga windows sa lahat ng models. Maaaring i-enable ng mga plan ang usage credits, na mina-manage gamit ang /usage-credits, para bumili ng usage lampas sa ceiling. Hindi ko sadyang ilalagay ang mga plan quota: ang mga ito ang pinaka-volatile na numero sa paksang ito, kaya i-check na lang ang claude.com/pricing at ang iyong sariling /usage bars. Mahalaga pa rin ang token mechanics sa isang subscription — ang isang wasteful session ay uubos sa iyong window gaya ng pag-ubos nito sa dollars. Para sa subscription side, tingnan ang which Claude plan fits your usage.

Ang mga epektibong paraan

  • Limitahan ang binabasa ng agent. Ang "Fix the validation bug in auth.py" ay nagbabasa lang ng isang file; ang "improve this codebase" ay nagbabasa ng apatnapu. Panatilihing lean ang CLAUDE.md — dahil niloload ito sa bawat session, limitahan lang sa mga mahahalagang impormasyon — at ilipat ang mga workflow-specific na instruction sa mga skills na niloload on demand.
  • Malinaw at compact. Gumamit ng /clear sa pagitan ng mga hindi magkakaugnay na task — ang stale context ay muling ipinapadala, at muling binabayaran, sa bawat susunod na message. Sa loob ng isang mahabang task, ginagamit ang /compact Focus on the failing tests and the diff para i-summarize ang history para maiwasan ang quadratic curve.
  • Piliin ang tamang laki ng model. Kaya ng Sonnet ang karamihan sa coding sa $2/$10 bawat million tokens base sa introductory pricing noong July 2026 ($3/$15 sticker, kumpara sa Opus na $5/$25), at ang Haiku sa $1/$5 ang tamang tool para sa mga mechanical subagent work gaya ng log triage. Kayang mag-switch ng /model mid-session.
  • I-pre-filter ang mahabang output. Ang paggamit ng hook na nag-ge-grep sa test run para ipakita lang ang mga failures bago ito makita ng Claude ay nagpapababa sa 20,000 tokens ng tool result tungo sa 300, at ginagawa ito sa bawat susunod na resend ng turn na iyon.
  • I-batch ang mga hindi interactive. Para sa sarili mong API pipelines — classification, bulk review, nightly jobs — ang Batches API ay nagpapatakbo ng parehong models nang may 50% discount kapalit ng asynchronous delivery.
  • Irespeto ang cache clock. Magtrabaho sa mga tuloy-tuloy na stints. Ang isang detached Claude Code session sa tmux sa isang VPS ay walang gastos habang idle — ang tokens ay nagagamit lang kapag may tumatakbong turn — ngunit ang warm cache ang nawawala kapag idle, at ang susunod na turn ang magbabayad sa re-write.

FAQ

Ilang tokens ang ginagamit ng isang coding session sa Claude Code?

Walang fixed na bilang — ang isang mid-session turn ay karaniwang gumagamit ng tens of thousands ng prompt tokens kapag naipon na ang mga file at history. Ang isang working session ay umaabot sa millions, kung saan karamihan ay galing sa cache sa tenth ng base rate. Para sa calibration, ang published enterprise figures ng Anthropic as of July 2026 ay average na $13 bawat developer bawat active day, at 90% ng mga users ay nasa ilalim ng $30. I-run ang /usage sa sarili mong session; mas mainam ang limang minuto ng pag-obserba rito kaysa sa anumang published average.

May bayad ba ang thinking tokens kahit hindi ko sila nakikita?

Oo. Ang thinking tokens ay binibilang bilang output tokens — ang mas mahal na rate — at kasama sa max_tokens. Binibilang sila ng mga current models kahit hindi ipakita ng interface ang reasoning summary. Kung ang response ay nag-truncate gamit ang stop_reason: "max_tokens" bago matapos ang visible answer, malamang na naubos ng thinking ang budget. Sa Claude Code, ibaba ang effort level gamit ang /effort para sa mga task na hindi nangangailangan ng deep reasoning.

Bakit nagiging mas mahal ang bawat message sa mahabang Claude Code session?

Dahil ang API ay stateless: ang bawat turn ay muling nagpapadala ng buong conversation — bawat file read, tool result, at nakaraang exchange — bilang billed input. Dahil dito, ang turn 50 ay may dalang freight mula sa turns 1 hanggang 49. Ang prompt caching ay nagbibigay ng paulit-ulit na prefix sa halos tenth ng base input price, ngunit patuloy na lumalaki ang prefix na ito. Kapag lumampas sa cache TTL ang idle gap, ang susunod na turn ay magiging full-price re-write. Pinapaliit ng /compact ang history; nire-reset naman ito ng /clear.

Paano ko masusuri ang aking Claude token usage at cost?

Sa Claude Code, ipinapakita ng /usage ang session token statistics, local cost estimate, at plan-limit bars para sa mga subscription (ang /cost ay isang alias); ipinapakita naman ng /context kung ano ang nagpupuno sa window. Para sa authoritative API billing, gamitin ang usage page sa Claude Console. Sa sarili mong code, basahin ang response.usage — ang pagsasama-sama ng input_tokens, cache_creation_input_tokens, at cache_read_input_tokens ang magbibigay ng tunay na prompt size — at mag-estimate nang maaga gamit ang count_tokens endpoint, hindi gamit ang tiktoken.