AWS Bedrock count tokens functionality helps developers measure how many input tokens a request will consume before sending it to a foundation model.
This matters when you need to control inference costs, stay within model context limits, prevent quota problems, or understand why an application is being throttled.
Amazon Bedrock provides the CountTokens API for this purpose.
Instead of estimating tokens from character or word counts, the API calculates tokens according to the tokenizer used by the selected model.
AWS states that tokenization is model-specific, so the same text can produce different token counts across models.
This guide explains how token counting works, how to use the Bedrock CountTokens API with Boto3, how max_tokens affects quotas, and how to monitor AWS Bedrock token usage in production.
What Does AWS Bedrock Count Tokens Do?
CountTokens API tells you how many input tokens a Bedrock model would process before you actually invoke that model.
You provide the model ID and the same input you intend to send through InvokeModel or Converse.
Bedrock returns an inputTokens value based on that model tokenization rules.
This gives developers a reliable way to:
- Check whether a prompt fits within the model token limit.
- Estimate input-related inference costs.
- Control prompt size before sending a request.
- Manage context windows in chat applications.
- Prevent oversized requests.
- Plan AWS Bedrock TPM consumption.
- Compare prompt sizes during optimization.
CountTokens operation itself does not incur a charge, according to AWS.
That makes it useful as a validation step before expensive or large inference calls.
How Does Bedrock Token Count Work?
Bedrock token count is model-specific rather than based on a universal words-to-tokens formula.
A token can represent a complete word, part of a word, punctuation, whitespace, or another text element.
Different model providers use different tokenization methods.
For this reason, estimating that 100 words always equal a fixed number of tokens can produce inaccurate results.
When you call the Bedrock CountTokens API, you identify the model that will handle the request.
Bedrock then calculates the input using that model tokenization rules.
AWS says the returned count matches the input-token count that would apply if the same request were used for inference.
For example, API response is simple:
{
“inputTokens”: 1250
}
Important point is that this value represents input tokens.
It does not predict exactly how many output tokens the model will generate.
How to Use the Bedrock CountTokens API
Use CountTokens immediately before inference when prompt size needs to be validated or recorded.
Runtime API uses this endpoint pattern:
POST /model/{modelId}/count-tokens
Request contains an input object.
Format depends on whether app uses InvokeModel or Converse.
For InvokeModel, provide the model-specific inference request inside invokeModel.
For Converse, provide the conversation data inside converse.
API then returns the number of input tokens.
Boto3 Bedrock Count Tokens Example
Python applications can call CountTokens directly through the bedrock-runtime Boto3 client for supported models.
Implementation looks like this:
import boto3
client = boto3.client(
“bedrock-runtime”,
region_name=”us-east-1″
)
messages = [
{
“role”: “user”,
“content”: [
{
“text”: “Explain how Amazon Bedrock token quotas work.”
}
]
}
]
response = client.count_tokens(
modelId=”YOUR_MODEL_ID”,
input={
“converse”: {
“messages”: messages
}
}
)
print(“Input tokens:”, response[“inputTokens”])
Boto3 Bedrock Runtime client exposes count_tokens() with support for both invokeModel and converse input structures.
Use the same messages, system instructions, documents, or other supported content that you intend to send during inference.
Otherwise, count may not represent the final request.
Count Tokens Before Calling Converse
For conversational applications, count the complete conversation rather than only the newest user message.
Common mistake is to count only this:
What is my order status?
while the actual Bedrock request contains a system prompt, previous user messages, previous assistant responses, and the question.
Real token usage can therefore be much larger than the newest message suggests.
With Converse, CountTokens accepts conversation messages and system content so that token measurement reflects the actual inference input.
This is particularly important for:
- Customer-support assistants
- RAG applications
- Long-running chat sessions
- AI agents
- Document analysis
- Multi-turn workflows
As conversation history grows, token usage should be checked before context-window problems appear.
AWS Bedrock Token Limit vs. max_tokens
Bedrock token limit defines what the selected model can support, while max_tokens controls how much output you permit for a request.
These concepts should not be treated as interchangeable.
AWS Bedrock token limit varies by model.
Models can have different context windows and maximum output sizes, so there is no single universal Bedrock token limit.
max_tokens, by comparison, is an inference parameter that limits the maximum response length.
For Anthropic Claude Messages requests, for example, max_tokens specifies the maximum number of tokens the model may generate, although the model can stop before reaching that value.
Same general concept may use different parameter names for other model families.
This is why developers should check the specific model Bedrock documentation rather than assuming one max tokens Bedrock value applies everywhere.
Why max_tokens Can Affect AWS Bedrock TPM
Setting max_tokens unnecessarily high can consume available quota capacity at the start of a request and reduce throughput.
AWS Bedrock runtime inference uses model-level token quotas such as tokens per minute, or TPM.
Runtime endpoint combines input and output token consumption against a per-model TPM quota.
AWS reserves quota based on:
Input tokens + max_tokens
During and after generation, that quota calculation is adjusted according to actual output and the applicable burndown rate.
Suppose normal output is around 800 tokens, but you configure:
max_tokens = 32000
Application may reserve far more TPM capacity than it needs when the request begins.
Result can be lower concurrency and earlier throttling even though responses are much shorter.
Better approach is to examine real output usage and set max_tokens close enough to your legitimate response requirements.
What Is the Bedrock Burndown Rate?
Burndown rate determines how generated tokens translate into quota consumption for models using the bedrock-runtime endpoint.
It is important to distinguish quota consumption from billing.
AWS documents model-specific output-token burndown rates.
As of August 2026, certain Anthropic models use multipliers greater than 1:1.
AWS currently documents 15x output-token burndown for Claude 4.8 models, 10x for Claude Sonnet 5 and Opus 5, and 5x for other Anthropic models version 4.7 and earlier.
Other models use a 1:1 rate under the documented runtime rules.
Final quota calculation for the runtime endpoint can include:
InputTokenCount
+ CacheWriteInputTokens
+ (OutputTokenCount × burndown rate)
Cached input tokens read from the cache do not contribute to this particular quota calculation.
AWS also makes an important distinction: billing remains based on actual token usage rather than this quota multiplier.
How to Track AWS Bedrock Token Usage After Inference
Use actual inference usage and CloudWatch metrics when you need to know what the model really consumed.
CountTokens is primarily a pre-inference tool.
After inference, Bedrock token-usage structure can report:
- inputTokens
- outputTokens
- totalTokens
- cacheReadInputTokens
- cacheWriteInputTokens
Availability of cache-related values depends on the request and caching behavior.
Amazon CloudWatch also exposes runtime token metrics.
AWS documents InputTokenCount and OutputTokenCount for monitoring token consumption and recommends examining token metrics when deciding how to configure max_tokens.
Production system should therefore use both approaches:
Before inference:
Use CountTokens for validation and estimation.
After inference:
Record actual token usage for monitoring, optimization, and cost analysis.
Is There an AWS Bedrock Token Calculator?
CountTokens API is the safest AWS-native option when you need an AWS Bedrock token calculator for supported models.
Third-party calculators and local tokenizers can be useful during development, but they may not match Bedrock final token accounting if they use different tokenizer versions or assumptions.
Because AWS explicitly states that counting is model-specific, the Bedrock API is preferable when exact request sizing matters.
This also explains why searching for an AWS Bedrock tokenizer or AWS Bedrock count tokens GitHub implementation may not always produce a universal solution.
Locally implemented tokenizer can become outdated.
Service-side CountTokens API keeps token counting tied to the model being invoked.
CountTokens and Anthropic Models on bedrock-mantle
Not every Anthropic model can necessarily use bedrock-runtime CountTokens.
AWS notes that some Claude models, including models launched only through cross-Region inference on bedrock-runtime, may require Anthropic token-counting endpoint through bedrock-mantle instead.
For those models, AWS documents:
POST /anthropic/v1/messages/count_tokens
through the regional bedrock-mantle endpoint.
AWS also notes that its SDK do not currently expose a method targeting this specific mantle endpoint.
Applications can instead send a signed HTTP request or authenticate with a supported Bedrock API key.
Always check support for exact model rather than assuming boto3.client(“bedrock-runtirme”).count_tokens() works for every model available through Bedrock.
Best Practices for Counting Tokens in Amazon Bedrock
Token counting works best when it is part of request management rather than a debugging step added after throttling begins.
Use these practices in production:
- Count the complete prompt, including system instructions and history.
- Use the same model ID for counting and inference.
- Check token size before sending large documents or RAG context.
- Avoid configuring excessively high max_tokens.
- Record actual input and output token usage after inference.
- Monitor TPM usage in CloudWatch.
- Account for model-specific burndown rates when planning throughput.
- Check model-specific token and context limits.
- Trim unnecessary conversation history.
- Use prompt caching where it fits your workload and model capabilities.
These controls help keep Bedrock applications predictable as traffic and context sizes grow.
Frequently Asked Questions – Max_tokens Bedrock
How do I count tokens in AWS Bedrock?
Use the Amazon Bedrock CountTokens API with the model ID and the same input you plan to send through InvokeModel or Converse.
Response contains an inputTokens value calculated using that model tokenizer.
Does AWS Bedrock have a Count Tokens API?
Yes. Bedrock CountTokens API is available through bedrock-runtime for supported models.
AWS also documents a separate Anthropic token-counting route through bedrock-mantle for certain Claude models that do not support runtime CountTokens.
Does the CountTokens API cost money?
AWS states that using the CountTokens API does not incur charges.
Inference request itself remains subject to the applicable Bedrock pricing.
What is max_tokens in Amazon Bedrock?
max_tokens defines the maximum number of output tokens a model is allowed to generate for a request.
Permitted maximum depends on the selected model.
Setting it unnecessarily high can also reserve excessive TPM quota capacity when a request begins.
What is AWS Bedrock TPM?
TPM means tokens per minute.
On the bedrock-runtime endpoint, AWS applies per-model TPM quotas that govern how many input and output tokens your account can process within a minute.
Exact quotas depend on factors including the model, Region, and inference mode.
What is a token burndown rate in Amazon Bedrock?
Burndown rate converts generated tokens into quota consumption for throttling purposes.
Some models consume quota at more than one quota token per output token.
This quota calculation is separate from actual token billing.
Can I count tokens with Boto3?
Yes. For supported bedrock-runtime models, use BedrockRuntime.Client.count_tokens() and provide the model ID together with an invokeModel or converse input.
Is there one AWS Bedrock tokenizer for every model?
No.
Amazon Bedrock supports models from different providers, and AWS states that token counting is model-specific.
Using CountTokens with the model you intend to invoke is therefore more reliable than assuming one tokenizer produces the correct count for every Bedrock model.
How can I reduce AWS Bedrock token usage?
Reduce unnecessary system instructions, remove irrelevant conversation history, limit retrieved RAG context, use appropriate max_tokens values, consider prompt caching where supported, and monitor actual input and output usage in CloudWatch.
AWS recommends using its token metrics to help optimize max_tokens.
Relevant Guides
How to Integrate Fiber Optics in AI Driven Automation
AI Tools for Automating Python Data Analysis Pipelines
How to Choose AI Solutions for Frontline Support Automation
How Can i Use AI to Automate Prior Authorization Calls
Naveed Ahmed is the founder of Qualix Solutions, a custom software and AI solutions company helping founders and operations leaders turn complex business problems into reliable, scalable software. A former Microsoft Technical Leader with 17 years at the company, Naveed held roles spanning software development management, technical product management, data architecture, and information architecture, delivering platforms for deal management, services product data, SAP integration, and workforce skills systems.
At Qualix, he leads a distributed team building SaaS products, web and mobile applications, AI and machine learning solutions, intelligent automation, and data engineering platforms for clients across professional services, healthcare, and telecommunications. Naveed writes about custom software development, AI solutions for mid-market businesses, product strategy, SaaS architecture, and the operational realities of running a modern software company.
