By the end of this lesson you will understand what tokens are, why AI models use them instead of words or characters, and how to reason about token counts in your own Spring Boot applications.
You're on the EngineerPrep team. A new feature just shipped: an AI tutor that answers practice questions in real time. Users love it. Usage grows fast. Then someone opens the AWS cost dashboard. The Bedrock line item is climbing steeply. You dig into the logs. Every call to Claude reports two numbers: inputTokens and outputTokens . The billing formula is simple — you pay per token. But nobody on the team agreed on what a token actually is , so nobody budgeted for it correctly. Your first guess is probably the same one most engineers make: "a token is a word." That would make the math easy. Count the words, multiply by the price, done. But that guess is wrong — and being wrong about it produces incorrect budgets and unexpected billing surprises. So: what is a token, and why does every large language model use tokens instead of words?
Think about how you learned to read as a child. Your teacher didn't hand you a dictionary on day one. Instead, you learned small, reusable pieces — letters first, then common letter combinations like "th", "ing", and "tion". Those small pieces snapped together to form any word. A token is exactly that: a small, reusable chunk of text. Not a full word, not a single character — something in between. The word "running" might be one token. The word "unbelievably" might be split into two or three tokens because it is less common. The word "HashMap" might become two tokens — "Hash" and "Map" — because the model learned those pieces separately. A tokenizer is the tool that does the splitting. Think of it as a slicer that cuts raw text into these chunks before the AI model ever sees a single letter. Why chunks instead of characters? Characters are too fine-grained…
Picture a short sentence sitting on a workbench: "HashMap stores key-value pairs efficiently." Before the tokenizer touches it, it is just a string of characters. No meaning yet — just 39 characters in a row. Step 1 — The tokenizer scans left to right. Imagine a small cursor moving along the sentence, one character at a time, looking for known patterns. It is consulting a lookup table called a vocabulary — a list of all the text chunks the model was trained to recognize. Step 2 — Common words snap off cleanly. The cursor reaches "stores" . That exact string is in the vocabulary. It snaps off as a single token: stores . The cursor advances past it. After this step you have: HashMap ... maybe ... stores key - value pairs efficiently . Step 3 — Less common words get split. Now the cursor reaches "HashMap" . This is a technical term. It may not appear as one entry in the vocabulary.…
EngineerPrep calls Claude through Spring AI, which wraps Amazon Bedrock. After every call, the response object carries a ChatResponse that includes metadata about token usage. Here is a minimal, realistic service that sends a question to the AI tutor and logs the token cost. Line by line: @Service marks this class as a Spring-managed bean. Spring creates one instance and injects it wherever it is needed. The constructor receives a ChatClient — Spring AI's abstraction over the underlying LLM provider. EngineerPrep configures this client to point at Claude on Amazon Bedrock via application.yml . No AWS SDK wiring in this class. answerQuestion sends the user's question and returns the text answer. That is the only thing the caller cares about. Inside the method, .call() blocks until Claude responds. The result is a ChatResponse .…