The first time most people call an AI model from code, it goes like this. Someone sends you a key that looks like a cat walked across a keyboard. You paste it into a script, copy six lines from a docs page, hit run, and a paragraph of surprisingly good English appears in your terminal. It works. You have no idea why it works, what you just spent, or what any of the settings in those six lines actually do. So you change nothing, because changing things you do not understand is how you get paged at midnight.

That gap is worth closing, because almost every decision you will make later depends on it. Which model to use, why your bill tripled, why the same script that worked on Tuesday returns garbage on Friday when someone pastes in a bigger document, why one team's feature costs a hundred times more than another's. All of it comes back to one loop: a request goes out, some text gets counted, a model reads it and writes back, and a meter moves. Nothing in that loop is magic, and none of it requires maths.

Here is the whole thing, explained the way we wish someone had explained it on day one. Every number in this post came from real calls made on 7 August 2026, not from a pricing page, and two of the findings contradict what most explainers on this topic will tell you.

The Whole Loop, Once, Without Jargon

Strip away the vocabulary and calling an AI model is an ordinary web request. Your program opens an HTTPS connection to a URL, sends a small blob of JSON containing your text and a few settings, and includes a key in the headers so the other end knows who to bill. A few seconds later, JSON comes back with the model's reply and a receipt telling you exactly what it cost.

That is genuinely all of it. There is no local install, no model on your laptop, no GPU in your basement. The model lives on someone else's hardware, and you are renting a few seconds of its attention. If you have ever called a weather API or a payments API, you already know the shape of this. The only unusual part is the pricing: instead of paying per request, you pay per unit of text, in both directions, and the price per unit differs wildly by model.

Four things in that loop are worth understanding properly, because they are the four things that will confuse you later: the key, the tokens, the context window, and the settings. Take them one at a time.

An API Key Is a Password That Spends Money

An API key is a string that does two jobs at once. It proves who you are, and it authorizes the charge. There is no username, no second factor, no approval step. Whoever holds the string can spend the money.

You can see both jobs in what happens when the key is wrong. Send a request with a bad one and the server does not even look at your text:

Error code: 401 - Authentication Error, Invalid proxy server token passed.

That is a 401, the standard HTTP status for "I do not know who you are." No tokens counted, no charge, no model involvement. The key is the gate, and everything past the gate is billable.

This is why the advice about not committing keys to Git is stated so insistently, and why it is stated badly. The usual framing is that a leaked key is a security incident. It is more concrete than that: a leaked key is a stranger with your credit card, and the charges look completely legitimate to the provider because they are legitimate. The request had a valid key. That is the entire authorization model.

So the handling rules are unglamorous and non-negotiable. Keep the key in an environment variable or a secrets manager, never in the source file. Add your .env file to .gitignore before you create it, not after. Rotate the key the moment you suspect it has been seen, because rotation is the only real remedy. And if you are working through examples on a laptop, prefer a key with a hard spending ceiling on it over one wired to an open-ended account, so a mistake costs you an afternoon instead of a mortgage payment.

One clarification that saves confusion later: the key identifies your account, not the model. The same key can usually reach several models, and choosing between them is a field in the request body, not a different credential. Hold that thought, because it turns out to be the single most useful property of the whole setup.

Text Becomes Numbers, and the Numbers Are the Bill

A language model cannot read letters. Before your text reaches it, a component called a tokenizer chops the text into tokens, and each token is turned into a number. A token is roughly three quarters of a word in English: common words are usually one token, rarer words split into pieces, punctuation and spaces count too. "Kubernetes" might be two or three tokens. "the" is one.

Tokens matter for exactly one practical reason: they are the unit of billing. You are not charged per request or per question. You are charged for the tokens you send (input) plus the tokens the model writes back (output), and output costs more. Considerably more: across Anthropic's published price list, every single model charges exactly five times as much per output token as per input token. That ratio is why "make the model answer more briefly" is one of the highest-leverage cost optimizations available to you.

Here is where the theory meets reality in a way that surprises people. We sent one identical sentence, Explain what a Kubernetes pod is, in two sentences., to five different models within the same minute. Identical string, identical bytes. The input token counts came back as 11, 17, 20, 27, and 94.

The same text. Counted five different ways. Different labs build different tokenizers, and some providers also wrap your message in their own scaffolding before it reaches the model, which inflates the count further.

This is not an anomaly of our test setup, and the vendors document it when you go looking. Anthropic's own pricing page notes that its newer models use a different tokenizer that "produces approximately 30% more tokens for the same text" than its previous one. That is a 30% swing in the input half of your bill, between two models from the same company, for text you did not change.

The practical consequence: you cannot precisely predict a bill from your word count, and any cost estimate you build from a rule of thumb like "750 words is 1,000 tokens" is an approximation that can be off by a factor of several. Do not budget from arithmetic. Run a hundred representative calls, read the actual usage numbers the API returns, and multiply from there.

The Tokens You Pay For But Never See

This one is not in most explainers, and it is the single most expensive thing to be ignorant of.

Some modern models "think" before they answer. They generate a private chain of internal reasoning, discard it, and show you only the final answer. You are billed for the private part.

From the same batch of calls, one model returned 283 characters of visible text, about two sentences. Its usage receipt said 497 output tokens. The breakdown field explained the gap:

completion_tokens: 497
completion_tokens_details: { reasoning_tokens: 445 }

445 of those 497 tokens were reasoning you never saw and cannot read. You paid for all of them. On this particular call, roughly 90% of the output charge bought thinking that was thrown away before it reached you.

This is not a scam, and the thinking is often why the answer is good. But it wrecks naive cost estimates, because the visible response length tells you nothing about what you were charged. A two-sentence answer can cost more than a two-page one from a different model.

Two things follow. First, when you compare models on price, compare on measured total tokens, never on how long the answers look. Second, not every model does this, and the ones that do often let you turn it down or off for simple tasks. If you are asking a model to reformat a date, you are not buying deep reasoning, and you should not be paying for it.

Context Window: Working Memory, Not Knowledge

The context window is the maximum number of tokens a model can hold in a single request. It covers everything: your instructions, the document you pasted, the conversation history you are replaying, and the answer it is about to write. All of it has to fit in one budget.

The most common misunderstanding is that the context window is how much the model knows. It is not. The model's knowledge is baked in from training and does not change. The context window is how much it can look at right now, for this one request. It is closer to the amount of paper you can fit on a desk than to the size of the library.

The other misunderstanding is what happens when you exceed it. People expect the model to gracefully read what fits, or summarize, or truncate the middle. It does not. You get a hard error before the model runs at all. Here is a real one, from pushing an oversized log into a model with a 200,000-token window:

Your input is 453239 tokens, which exceeds the model's maximum of 200000 tokens.
Please reduce your input and try again.

Blunt, and helpfully specific. It tells you the actual size of what you sent and the actual limit, which is the fastest debugging information you will get all day.

Three consequences worth internalizing. A long chat is not free memory. Most chat implementations resend the entire conversation history on every turn, so a long conversation gets more expensive with each message and eventually hits the wall. Big windows are a capability, not a strategy. A model that accepts a million tokens will happily take your whole handbook and charge you for all of it, every single time you ask a question about it, which is why serious document systems retrieve the three relevant pages instead of resending the book. Window sizes vary enormously between models, from tens of thousands of tokens to over a million, and this is often the real reason a team ends up needing a second model.

Why the Same Question Costs 170x More on One Model Than Another

Now put the pieces together. Every model has its own price per input token, its own price per output token, its own tokenizer, and its own habits about answer length and invisible reasoning. Multiply those together and the spread on an identical question gets genuinely absurd.

These are real receipts. One prompt, five models, same minute, costs as reported by the API's own usage accounting on 7 August 2026:

Read the top and bottom rows together. The cheapest call cost $0.00003 and the most expensive cost $0.00509, a difference of roughly 170x, and all five answers were correct. They differed in polish and detail, not in accuracy, because "what is a pod" is a question every one of these models can answer in its sleep.

That is the lesson people take too long to learn. The expensive model is not 170 times better. It is better at hard things, and this was not a hard thing. At one call a day the difference is meaningless. At a million calls a month it is the difference between $30 and $5,000, for the identical result.

The corollary is that price and speed do not track quality in the way you would expect either. The cheapest model here was not the fastest, and the slowest was the most expensive. There is no single "best" model, only a best fit for a specific job, which is why experienced teams end up using several.

Temperature: What It Actually Changes

Temperature is the setting people fiddle with first and understand last. It is usually described as a "creativity" dial, which is misleading enough to be worth correcting.

Underneath, a model does not pick the next word. It produces a probability distribution over all possible next tokens, then samples one. Temperature reshapes that distribution before sampling. Low temperature makes the likely tokens even more likely, so the model plays it safe. Higher temperature flattens the curve, giving less likely tokens a real chance, so the wording gets more varied and more surprising.

What it does not do is make the model smarter, better informed, or more accurate. It changes how adventurously the model picks its words. A high temperature will not help it recall a fact it does not have, it will just make it phrase the wrong answer more colorfully.

Two practical findings from testing this live, both of which will save you an afternoon.

The range is not what you assume. Asking for a temperature of 2.0 on one model returned a flat rejection:

Error code: 400 - temperature: range: 0..1

Valid ranges differ by model and provider. Some accept 0 to 2, some cap at 1, and some newer reasoning models reject the parameter entirely. Check per model rather than assuming.

Repeating the exact same request can return a cached answer, which makes temperature look broken. This one genuinely surprised us. We sent an identical creative prompt three times at temperature 1.0 and got byte-identical text every time. That looks like proof that temperature does nothing. It is not. The responses carried the same response ID, and the second and third calls came back much faster than the first. That is a cache serving the stored answer, not the model re-rolling.

Change a single character in the prompt and the illusion breaks. Four nonce-varied versions of the same creative request at temperature 1.0 produced four genuinely different answers. The model samples exactly as advertised; a caching layer in front of it was hiding the evidence.

There is a third, subtler finding. On a question where the model is overwhelmingly confident, temperature barely matters. We asked "name one animal" repeatedly, at temperature 1.0, varying the prompt each time to defeat caching, and got "Lion" every single time. Temperature reshapes a distribution, but if one option towers over all the others, reshaping it still leaves that option on top. Temperature adds variety where the model is genuinely uncertain. It cannot manufacture doubt the model does not have.

Practical guidance: use a low temperature (0 to 0.3) for anything where you want the same input to produce the same shape of output, which is most engineering work: extraction, classification, formatting, code. Use a higher one for brainstorming and drafting, where variety is the point. And if you are testing the difference, vary your prompt between runs or you may be reading a cache.

Now Make One Call Yourself

Reading about this only gets you so far. The loop stops being abstract the moment you see your own receipt. This takes about two minutes.

Almost every provider now speaks the same request format, originally OpenAI's, so one library covers most of them. Install it:

pip install openai

Then the whole loop, in eleven lines:

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["MY_API_KEY"],        # the password that spends money
    base_url="https://your-provider/v1",      # where the request goes
)

response = client.chat.completions.create(
    model="claude-haiku-4-5-20251001",        # which model reads it
    messages=[{"role": "user", "content": "Explain what a Kubernetes pod is, in two sentences."}],
)

print(response.choices[0].message.content)    # the answer
print(response.usage)                         # the receipt

Set your key as an environment variable first, so it never lands in the file:

export MY_API_KEY="your-key-here"
python call.py

Do not skip that second print. The answer is the interesting part for about ten seconds; the receipt is the part that changes how you build things. Here is the real one from that exact call, with the empty detail fields trimmed for readability:

CompletionUsage(completion_tokens=72, prompt_tokens=20, total_tokens=92, cost=0.00038)

Twenty tokens in, seventy-two out, ninety-two total, and it cost 38 hundredths of a cent. That is the entire economic model of AI development on one line. Every architecture decision you make from here, whether to summarize before sending, whether to cache, whether to use the cheap model for the bulk and the expensive one for the hard cases, is an argument about how to make that line smaller.

Now change one thing and run it again. Change model to a different value and nothing else. Same key, same code, same question, different brain answering it, different receipt. That single property, that the model is a string in the request rather than a different account and a different SDK, turns out to matter more than anything else in this post, and it is where things get interesting.

Common Errors and What They Mean

The four you will actually hit, with what they are really telling you.

The pattern worth noticing: a 4xx means the request was rejected before the model did any work, so you were not charged. A slow, expensive, disappointing answer is a different class of problem entirely, and no error code will tell you about it.

Conclusion

The loop is small enough to hold in your head. A key proves who is paying. Your text becomes tokens, which are the unit of the bill in both directions, and the count depends on which model is reading. Everything for one request has to fit inside that model's context window or it fails outright. Temperature changes how adventurous the wording is, not how correct it is. And the receipt that comes back tells you exactly what you spent, which is the number that should drive your decisions.

The thing worth carrying forward is the size of the spread. A 170x cost difference on an identical question, with identical correctness, means model choice is an engineering decision with real money attached, not a matter of picking the one with the best reputation and moving on. Which leads directly to the awkward part: the moment you want to compare two models properly, or use a cheap one for bulk work and a strong one for the hard cases, you discover that each one lives behind its own signup, its own key, and its own invoice. That problem is the subject of the next post in this series.

Go make one call. Print the usage line. Everything else in AI engineering is built on that receipt.

Where to Go From Here

If this was your first real look under the hood, the natural next step is to run the same prompt through a few different models and watch the receipts change, because that is the fastest way to build an intuition for what "good enough" actually costs you. Doing that used to be tedious, since it meant a separate signup, a separate key, and a separate invoice for every lab you wanted to compare. That is the part that has genuinely improved.

KodeKey is KodeKloud's answer to it: one key and one endpoint that reach a few dozen models from about ten different labs, including the five in the table above, so switching models really is changing a string in your code. It is built for learning, testing, and prototyping rather than production traffic, which is exactly the phase you are in when you are running experiments like this one. You can generate a key from your KodeKloud account and paste it straight into the eleven lines above, and the official examples repo has runnable Python, JavaScript, and curl versions. If you would rather build the underlying skills in order, the AI Learning Path covers prompt engineering through RAG and agents, and the AI-powered roadmap for DevOps and cloud engineers maps where this fits into an engineering career.

FAQs