Ask ten Australian businesses evaluating Claude for a production workload what it will cost per month, and eight will guess. The other two will run a pilot for a few weeks and extrapolate from an invoice. Neither approach holds up when a board or a finance lead asks for a hard number before sign-off. Anthropic ships a token counting endpoint specifically so nobody has to guess: send it the exact prompt, system instructions, and tool definitions you plan to use in production, and it returns the input token count before you spend a cent on the real call.
What token counting actually measures
A token is roughly three-quarters of an English word, so a 1,000-word brief works out to around 1,300 tokens once punctuation and formatting are included. The count_tokens endpoint on the Messages API takes the full assembled request, including the system prompt, any tool schemas wired in through MCP, and the conversation history, and returns the exact input token count Claude will bill against. That matters because the system prompt and tool definitions for a well-built Cowork or Claude Code integration are often larger than the user's actual message, and teams consistently underestimate that fixed overhead when they cost a project from the user-facing prompt alone.
For an Australian business running Claude Code for internal engineering work, or a Cowork setup handling client email triage, the token count is the single lever that determines both latency and spend. Prompt caching is the practical fix for the fixed-overhead problem: cache a stable system prompt and tool schema once, and every subsequent call in that session only pays for new content rather than re-sending the same instruction block on every message. On a high-volume workload that alone can cut the effective input cost by more than half.
Building a cost model your finance team will accept
A defensible estimate doesn't come from a single test prompt sent through the console. It comes from sampling the actual workload the feature will run against, and treating token counting as a budgeting exercise rather than a curiosity.
Sample at least 20 real conversations, documents, or support tickets from the live use case, not synthetic test prompts written to look tidy.
Run count_tokens against the fully assembled request, system prompt, tool schemas, and conversation history included, not just the user's message.
Separate the input and output token estimates, because output tokens are priced at a materially higher rate than input tokens on every current Claude model.
Add a 15 to 20 percent buffer for prompt growth as the feature evolves and edge cases get handled.
Track actual spend weekly for the first month and reconcile it against the estimate before reporting a steady-state number upward.
Take a Sydney-based accounting firm triaging around 500 client emails a month through a Claude-powered inbox assistant. A representative sample shows an average assembled prompt of roughly 2,400 input tokens (email body, a 600-token system prompt, and a short tool schema for the CRM lookup) and an average output of 400 tokens per reply. At current published rates for a mid-tier Claude model, that workload lands somewhere between \$180 and \$260 a month once caching is applied to the repeated system prompt, a fraction of the \$45,000 a bespoke NLP build was quoted at eighteen months earlier. The gap between those two numbers is usually the strongest argument in the room.
Where the estimates go wrong
Most cost blowouts trace back to the same handful of causes, and none of them require complicated forecasting to catch early.
Unbounded conversation history: a chat feature that keeps appending every prior turn to the context window sees its per-call cost climb steadily across a session instead of staying flat.
Retry loops on validation failures: a tool call that fails schema validation and silently retries three times bills three times, and the failure rate rarely shows up until someone reads the logs.
Skipping prompt caching on a stable system prompt, which leaves the fixed overhead uncached on every single call.
Defaulting to the largest available model tier for tasks a smaller, faster model handles just as well, an easy \$10,000 a year difference at moderate volume.
There's a compliance angle too. Any Australian business logging prompts and token counts for cost auditing is handling data that may fall under the Privacy Act 1988, and APRA-regulated entities in financial services carry extra obligations around what gets retained and for how long. Keep cost-audit logs scoped to token counts and metadata rather than full prompt content wherever the workload allows it, and set a retention window instead of keeping everything indefinitely.
None of this requires a data science team. It requires running the actual workload through count_tokens before committing budget, not after the first invoice lands.
If you're weighing a Claude build for your business and want the real number before you scope it, book a session and we'll run the estimate with you.
