How can a small business control AI API costs?

What is the simplest way to control AI API costs?

A small business should control AI API costs at the request boundary, before a call reaches OpenAI, Anthropic, or Google. Set a monthly budget, attach a project or team to it, record input and output tokens, and route routine work to a cheaper model. Keep a human approval step for anything customer-facing.

That sounds obvious. It is also where most teams get lazy.

I would start with one spreadsheet and one owner, not a six-week governance project. Put the API project, model, workflow, monthly ceiling, alert threshold, and last review date in separate columns. Review it every Friday for the first month. You will learn more from four real invoices than from a policy document nobody opens.

How should a small business set an AI budget?

Start with a ceiling that can interrupt an experiment without interrupting the company. Create separate provider projects or workspaces for production, internal experiments, and agency or client work. That gives you a useful answer to the question, "which workflow spent the money?" rather than a single account total that arrives after the damage.

OpenAI documents project-level budgets and spend alerts in its rate-limit and spend controls documentation. Its hard limits can return HTTP 429 when reached, and the documentation warns that enforcement is asynchronous, so a small overage is possible: OpenAI rate limits and spend. Anthropic lets organizations set workspace spend limits; its documentation says a configured spend limit can return HTTP 400, while a tier spend cap can pause requests with HTTP 429: Anthropic rate limits.

Those error codes matter. Your application should treat a provider cap as a controlled service event, show a useful fallback message, and alert a human. Do not retry a budget error 20 times. That is how a small bill becomes a larger small bill.

Google's Gemini API has spend-based rate limits evaluated over a rolling 10-minute window. Its current documentation lists a $250 billing-tier cap for Tier 1, a $2,000 cap for Tier 2, and a $20,000 to $100,000+ range for Tier 3, with qualification requirements tied to Google Cloud billing history: Gemini API rate limits. Treat those figures as provider documentation, not as a promise that every account is configured identically. Check your project before you build around a limit.

How can model tiering reduce token waste?

Model tiering means deciding which model gets which job before your application sends the request. A short classification, extraction, rewrite, or first-pass support answer usually does not need the same model you use for a difficult analysis. Make the default cheap and make escalation visible.

I use a two-step route for internal automation: a lower-cost model handles classification or drafting, then a stronger model is called only when a confidence check fails or the task needs a longer answer. The confidence rule should be observable, such as a missing required field or a score below a threshold, rather than a vague instruction to "use your judgment." Log the route beside the token count.

Do not compare model prices from a blog post saved six months ago. Put the provider pricing page beside your cost dashboard and review both when you change a model. Provider pricing changes, model names change, and a supposedly cheap fallback can have different context or output behavior. The boring spreadsheet wins again.

For a small team, start with three route labels in code: routine, review, and escalate. routine can answer from a constrained prompt. review sends the draft to a person. escalate uses the stronger model and records why. That is enough structure to stop every request becoming the most expensive request.

When does prompt caching actually save money?

Prompt caching helps when the same long prefix is sent repeatedly, such as a policy, product catalogue, support manual, or tool definition. Put stable instructions and reference material first, then put the changing user request after it. Do not expect caching to fix a prompt that changes from the first token on every call.

OpenAI's prompt caching documentation says cached input tokens still count toward tokens-per-minute limits, and that cached-input pricing varies by model: OpenAI prompt caching. The practical point is easy to miss. Caching can reduce input cost without increasing your throughput allowance. You still need rate-limit handling.

Measure before you celebrate. For each workflow, record total input tokens, cached input tokens if the provider exposes them, output tokens, request count, and cost. Compare a week before and after the change. If a support workflow has a 12,000-token manual but the instruction order changes on every request, the cache may do very little. Fix the prompt layout first.

I would not add a caching layer to a five-request-a-day experiment. It adds another thing to debug. Use it when the same context appears often enough that the provider's cache rules are visible in your usage data.

Should a small business use an AI gateway?

Use a gateway when more than one team, application, or provider needs the same budget and usage rules. A gateway gives you one place to issue keys, tag requests, track spend, apply rate limits, and route to a fallback. It also becomes another service to operate, so do not install one just to feel organised.

LiteLLM is one practical option for teams that want a self-hosted proxy. Its documentation says the proxy tracks spend for keys, users, and teams across more than 100 LLMs, and its user documentation describes budgets and spend tracking for virtual keys: LiteLLM spend tracking and LiteLLM budgets. Verify the current model cost map before relying on its numbers.

A gateway is useful if the marketing app, internal assistant, and client reporting workflow all call different providers. Give each workflow its own key or tag. Set a per-workflow budget. Keep the provider keys behind the gateway so a developer cannot quietly paste a production key into a test script.

For one small application, direct provider calls with project separation may be the better choice. A $20-per-month server does not pay for itself if it creates a new outage category and nobody owns updates. I have seen teams add an internal proxy before they had enough traffic to justify the proxy. It became a very expensive URL with a dashboard.

What should you monitor every week?

Build a small cost report with one row per workflow. Include request count, input tokens, output tokens, estimated cost, model, error count, and the percentage of requests that escalated. Add a note for any change in prompt, model, or traffic. Your aim is to explain movement, not to produce a beautiful finance dashboard.

Set alerts below the hard stop. A budget that only speaks when the provider blocks traffic is a smoke alarm wired to the fire department. Send an alert when a workflow reaches a review threshold, then stop or downgrade it when it reaches the ceiling. Keep the emergency path explicit: who approves more spend, and what gets paused?

Look for three patterns, but do not turn this into a ritual. A sudden request-count increase usually means a loop or retry bug. A token increase with stable requests often means a prompt or retrieved document grew. A cost increase with stable tokens often means routing changed. Each pattern points to a different fix.

What can a team implement this week?

1. Create separate projects, workspaces, or gateway keys for production and experiments.
2. Set a monthly ceiling and an alert below it. Record the provider's behavior when the ceiling is reached.
3. Add model routing labels to every request. Start with routine, review, and escalate.
4. Log input tokens, output tokens, model, workflow, and error type.
5. Test caching only on a workflow with repeated long context.
6. Review the report on Friday and remove one wasteful retry or oversized prompt.

Do the first five in a day. Leave the dashboard polish for later.

If you want someone to map the controls to your existing n8n, CRM, or reporting workflows, contact Deuce Works and we can start with the invoices and request logs you already have.