API keys, tokens, and why the AI model you pick changes your bill

One of the easiest ways to get surprised by AI is to think the model choice is just a quality choice. It is not. It is also a billing choice. The same workflow can cost almost nothing or real money depending on which model you call, how much context you send, how long the answer is, and how many times the workflow runs.

This matters more once you move from chatting with AI to building agents. A chatbot answer happens when you ask for it. An agent may run every time an email arrives, every morning at 7:00, every time a customer fills out a form, or every time a file lands in a folder. Small per-run costs compound fast when the work repeats.

Here is the practical version: what an API key is, what tokens are, how model pricing works, and how to do the math before a useful automation turns into an ugly bill.

First: what is an API key?

An API key is a secret password that lets your software call an outside service. For AI, that usually means your app, agent, website, or workflow can send text to a provider's model and get a response back. The provider bills the account tied to that key.

Treat an API key like a company credit card for software. Do not paste it into public code. Do not put it in screenshots. Do not give it to every tool you test. Store it in environment variables or a secret manager, and set spend caps or usage limits wherever the provider allows it.

If a key leaks, someone else can use your account and spend your money. If an agent loops because of a bug, it can spend your money too. Different problem, same result. That is why cost caps are not a nice-to-have. They are part of the build.

Tokens: the thing you actually pay for

AI providers usually bill by tokens. A token is a small chunk of text. As a rough mental model, one token is about three-quarters of an English word. That is not exact, because punctuation, code, numbers, and unusual words can split differently, but it is close enough for planning.

You pay for two directions:

• Input tokens: what you send to the model - your prompt, instructions, chat history, pasted documents, retrieved context, tool results, and examples.
• Output tokens: what the model writes back - the answer, summary, JSON, code, email draft, or report.

That distinction matters because many models charge different rates for input and output. Output is often more expensive. A workflow that asks for long reports will cost more than a workflow that asks for a short classification label, even if both read the same email.

Model cost: flagship vs. cheap

Provider prices change constantly, and each provider has its own rate card. So the numbers below are representative planning rates, not gospel. Check current pricing before you build a budget around any exact figure.

Those sample rates are intentionally far apart because that is the real lesson. The expensive model may be worth it when the job is difficult. But if you use it for every easy step, you are paying flagship prices for work a smaller model could handle.

At Valgard, the default pattern is simple: use the cheapest model that clears the bar for the task, then reserve the stronger model for the places where judgment actually matters. A model that sorts obvious emails does not need the same brain as a model reviewing a messy contract clause.

A worked example

Let's make the math concrete. Imagine a small agent step for a contractor. It receives a bid invitation email and returns a short routing decision.

Prompt sent to the model:
You are reviewing a bid invitation for a commercial contractor. Extract the job name, location, bid date, apparent scope, sender, and whether this should be reviewed by an estimator. Keep the answer short. Here is the email:
[about 650 words of email text]

Model response:
Job: Northside Warehouse Addition
Location: Memphis, TN
Bid date: Aug. 14, 2026 at 2:00 PM CT
Apparent scope: access gates and site fence mentioned
Decision: estimator review needed
Reason: fence/gate scope appears relevant and the job is local

A rough token count for that run might be 900 input tokens and 250 output tokens. The formula is:

input cost = input_tokens / 1,000,000 * input_rate
output cost = output_tokens / 1,000,000 * output_rate
total cost = input cost + output cost

Using the representative rates above:

• Flagship run: 900 / 1,000,000 * $15.00 = $0.0135 input, plus 250 / 1,000,000 * $75.00 = $0.01875 output, for $0.03225 total.
• Cheap run: 900 / 1,000,000 * $0.15 = $0.000135 input, plus 250 / 1,000,000 * $0.60 = $0.00015 output, for $0.000285 total.

Neither number is scary once. The difference shows up when the automation runs all day.

Now scale it

Same prompt. Same task. Same number of runs. The difference is model choice. That is why a serious AI workflow needs routing, not just a favorite model.

The right answer is not always the cheap model. If the task involves ambiguous documents, business judgment, legal risk, safety, customer commitments, final pricing, or anything expensive to get wrong, paying for a stronger model can be the responsible choice. But if the task is 'is this email a receipt, a newsletter, a bid invite, or a customer question?', a cheap model may be perfectly adequate after testing.

The cost traps

• Sending too much context every time. If the model only needs one email, do not send a whole mailbox history.
• Asking for long answers when a short label would do.
• Using a flagship model for every simple step because it feels safer.
• Letting agents retry failures without a limit.
• Leaving API keys uncapped during testing.
• Forgetting that scheduled jobs keep running even when nobody is watching the screen.

Most surprise bills are not caused by one big, impressive AI request. They come from a small automation running repeatedly with no cap, too much context, and the wrong model for the job.

A safer build pattern

1. Start with a copy of real work, not live actions.
2. Estimate input and output tokens for one run.
3. Multiply by your real expected volume.
4. Use representative rates first, then replace them with current provider prices.
5. Test a cheap model against real examples.
6. Escalate only the hard or risky cases to a stronger model.
7. Set spend caps, rate limits, retry limits, and alerts before connecting production data.
8. Review actual usage after the first week and adjust routing.

That last step is where a lot of people get lazy. The first version of an AI workflow is a hypothesis. Usage logs tell you whether the hypothesis was right. Maybe the cheap model is good enough. Maybe it misses too much and needs an upgrade. Maybe the output is too long. Maybe you are sending ten times more context than needed. You only know if you look.

Why this matters for agents

If you read our post on the difference between a model and an agent, this is the money side of that same idea. A model is one call. An agent is a system that may make many calls: classify the email, fetch the attachment, summarize the document, decide the next step, write the CRM note, draft the customer reply, and log the result.

That does not mean agents are too expensive. It means they need design. Our first-agent setup guide talks about permissions and safety; cost is part of the same discipline. A well-built agent uses small models for simple work, saves context instead of resending it blindly, stops when it is done, and asks for human approval before expensive or risky actions.

For contractors, this is also why the practical AI wins are usually boring at first: email triage, bid intake, document extraction, quote comparison, CRM cleanup, report drafts. They happen often, they are easy to verify, and they can usually be routed through cheap models with a human reviewing the important calls. That is the difference between a useful operating system and a demo that looks good once.

The bottom line

An API key lets your software call a model and bill your account. Tokens are the units you pay for. Input and output both count. Model prices vary widely. Prices change, so check current provider pricing before you budget. But the math is always the same: tokens divided by one million, multiplied by the rate, multiplied by the number of runs.

The model you pick changes your bill because volume compounds every design choice. Use cheap models for high-volume simple work, stronger models for the hard calls, and hard caps on every key. That is how you get the value of AI without waking up to a bill that makes you hate the thing you just built.

If you are still getting oriented, start with our plain-English model-vs-agent explainer, then read the first-agent setup guide for the safety side, and the AI-for-contractors post for where these workflows actually save time in a trade business.