# Enterprise AI Costs 101: A primer on what drives AI costs > A primer on what drives enterprise AI costs: tokens, inference, GPUs and memory — why the API bill is only 15-30% of year one, and an estimator you can point at your own business. Source: https://theaidaily.in/analysis/llm-cost.html Published: 2026-07-18 --- ## The pilot-to-production surprise Most AI projects start the same way: a small team, a few thousand test queries, a monthly bill that barely registers. Then the decision gets made to roll it out. Usage goes from hundreds to hundreds of thousands of queries per month. And the bill that felt like nothing is suddenly a line item someone has to explain. This guide is for the executive who is about to approve that rollout — or who is already asking "why does this cost so much?" It explains how AI is actually priced, where costs hide, and what your deployment will realistically cost before you find out the hard way. ## How the whole thing actually works Before any of the cost makes sense, it helps to see the machine end to end. Strip away the branding and every AI product on the market runs the same four steps. - **Your text is broken into pieces** — the unit you're billed in. - **The pieces go to a model that's already sitting in memory** — expensive memory, standing by whether anyone asks it anything or not. - **The model predicts the next piece. Once.** That's genuinely all it does. - **It repeats step 3 until the answer is finished.** That's it. No database of answers, no retrieval of a stored reply. Every response is computed from scratch, word by word, at the moment you ask. **Three ideas explain almost every number in this guide:** the **token** (what you're billed in), **inference** (the work of producing an answer), and **memory** (the thing that's actually scarce). The rest of this section covers the first two. Section 2 covers the third, because that's where most of the money hides. ## What a "token" actually is — and why it costs you more than you'd guess A token is roughly three-quarters of a word. That's the approximation to carry around, and it's the unit every AI price list is quoted in. Here's the part that costs money: AI models can't read words at all. They read **pieces**, drawn from a fixed dictionary of roughly 100,000 to 250,000 fragments, depending on the model, decided before it was ever trained. Common English words — "the", "policy", "customer" — each got their own entry in that dictionary, so they cost one piece. Anything the dictionary didn't anticipate gets chopped into fragments until it fits. Your product codes, customer IDs, internal jargon, and any language that isn't English were not anticipated. **Think of it as a typesetter's tray:** common words have their own pre-cast block. Everything else has to be spelled out letter by letter from spare pieces. You're billed per piece pulled from the tray, not per word printed. Type into the box below to see it happen. Each coloured block is one piece — one unit on your bill. Live tokeniser — see what you're actually billed for What is your return policy? **Plain English Same sentence, Hindi Same sentence, Tamil Order IDs & SKUs Structured output Legal jargon 0**pieces (tokens) billed **0**words a human would count **0**tokens per word **$0 (₹0)**to send this 1 million times Approximate. Real tokenisers use a fixed 100,000-entry dictionary that can't be shipped to a web page, so this reproduces the behaviour rather than the exact vocabulary. Counts land within roughly 10–15% on ordinary prose — the right precision for a budgeting conversation, not for reconciling an invoice. Ordinary English runs at roughly 1.2–1.3 tokens per word. That's the number every published price list quietly assumes. Now click the Hindi and Tamil samples and watch the ratio move. **⚠ The vernacular tax nobody budgets for** Indian language scripts weren't well represented when these dictionaries were built, so they fragment close to syllable-by-syllable. The same sentence in Hindi typically costs **2–3× the tokens** of its English equivalent, and scripts like Tamil can run higher still. If your rollout plan says "and then we add vernacular support in phase two," your cost model needs to grow with it. A support bot serving eight Indian languages does not cost the same as one serving English. The same effect hits anything else the dictionary didn't expect. Order IDs and SKUs shatter into fragments. Structured output — the JSON your systems actually consume — pays for every brace, quote and colon. Specialist vocabulary in pharma, law and insurance fragments harder than everyday English. None of this is waste you can eliminate, but all of it is cost you should see coming. **⚠ The dictionary changes between models — and so does your bill** Providers periodically ship a new dictionary. Anthropic's newer models use one that produces **roughly 30% more tokens for the same text** than the previous generation. Read that carefully: identical text, identical work, about 30% more billable units. So when you compare two models on their headline per-token price, you are not comparing like with like — the cheaper-looking one may chop your text into more pieces. Ask your team to compare cost *per completed task* on your own content, not price per million tokens on a pricing page. ## What "inference" actually means — and what one query takes There are exactly two things anyone does with an AI model, and only one of them is on your invoice. - **Training** is building the model: feeding it a large fraction of the written internet over months, across thousands of chips, to produce a finished set of numbers. It costs well over $100 million for a frontier model, happens once, and you never see it as a line item. It's amortised into the per-token price everyone pays. - **Inference** is using the finished model to answer a question. It happens every single time anyone touches your system. **This is your bill.** Every cost in this guide is an inference cost. The distinction matters because the intuition most executives carry is that AI is expensive to build and then basically free to run, the way software normally works. Software is written once and copied for nothing. AI is different: *every single answer is freshly computed.* There is no library of pre-written replies to hand out. You can cache the repeated *setup* — more on that shortly, and it matters — but the answer itself is new work every time. ### What one query costs you When a query arrives, three things have to happen: - **The model has to already be in memory.** Hundreds of gigabytes of numbers, loaded onto the chips and standing by. This is a standing cost, paid whether or not a query ever arrives. It's the floor under everything. - **The model reads your prompt.** It takes the whole thing in one go rather than word by word, which makes reading far more efficient than writing — though a longer prompt still costs proportionally more. - **The model writes the reply, one word at a time.** And here's the part that determines your bill: *each word requires another full trip through the model.* Not a lookup, not a shortcut. Modern models are built to wake only the portion of themselves a given word needs, but that still means an enormous quantity of numbers hauled out of memory, hundreds of times per answer. **What that means in practice:** a 200-word answer is not one operation. It's roughly 260 separate trips through the model, each one waiting on the last, because the model can't know its fifth word until it has committed to its fourth. This is the fundamental unit of cost in the entire industry. That's why the two halves of your query are priced so differently: Reading — all at once #### Your prompt goes in Read in one go rather than word by word. Cheap *per word* — but a prompt ten times longer still costs about ten times more. $0.50–$3 (₹42–₹252) per million tokens in Writing — one word at a time #### The answer comes out Another trip through the model for every word, each depending on the last. Cannot be parallelised or rushed. This half is expensive. $2–$15 (₹168–₹1,260) per million tokens out That asymmetry explains a line on every invoice you'll ever see: **output costs about 5× more than input**. It also hands you a cheap lever. Telling the system "answer in three bullet points, not three paragraphs" is not a style preference — it's a direct cut to the expensive half of the bill. Verbose AI is expensive AI, and most teams never tune this. The price ranges above span the cheapest models to the most expensive; Section 2 explains what sets your position in that spread. **⚠ The invisible half of your output bill** Some models now "think" before they answer — working through the problem in writing before producing the reply you actually see. You are billed for that thinking at the full output rate, and you never see a word of it. On a hard question it can quietly multiply the expensive half of the bill several times over, and telling it to "answer in three bullets" does nothing about it. Ask your team two things: does the model we've chosen do this, and is it turned up higher than the task needs? ### Why it's affordable at all: you're carpooling If every query needed its own dedicated machine, none of this would be economic. It works because the provider runs **many customers' queries through the same pass simultaneously**. The expensive part — hauling the model's numbers out of memory — happens once and serves dozens of unrelated users at the same instant. You are carpooling on someone else's chip, and the per-token price is your share of the ride. Nearly every cost dynamic in this guide falls out of that one fact: prices drop when providers pack the car more efficiently, and self-hosting is expensive because you'd be driving alone. ## A worked example: what one customer query really contains Tokens and inference in one picture. When a customer types a 6-word question to your AI support bot, the AI reads far more than 6 words — and this single diagram explains why pilots feel cheap and deployments don't. Anatomy of one customer query — "What is your return policy?" User's actual question 6 6 words AI's instruction manual 600 ~600 words Relevant policy document 500 ~500 words Conversation history 300 ~300 words The user contributed 0.4% of what the AI was charged to read. In a production deployment, this overhead is present on *every single query*. Every production AI system has three layers of hidden "overhead" on top of the user's message: - **The instruction manual** — also called the "system prompt." This is where you tell the AI how to behave: your brand tone, what it can and can't say, escalation rules. It's typically 500–1,500 words, and the AI reads it on *every query*. - **The knowledge context** — if your AI is pulling from your product docs, policies, or knowledge base, those relevant sections are also passed to the AI on each call. - **Conversation history** — in a multi-turn chat, the AI receives the full prior conversation every time to maintain context. The result: a "simple chatbot" that handles 5,000 queries per day is not sending 5,000 short messages. It's sending 5,000 large packets, each several times bigger than the user's actual words. The sticker price assumes none of this. Your real bill reflects all of it. **The pilot vs. production gap** In a pilot, engineers test with single queries and no production context loaded. In deployment, every query carries the full instruction manual, policy docs, and conversation history. That's often a 5× cost difference or more — not because the model changed, but because the setup did. ## How the meter runs You now know what a token is and what inference does. Pricing follows directly from both: every AI interaction is billed like a courier shipment, charged by weight, in both directions. You pay to send the package — your question, plus everything the system attaches to it. Then you pay again for the reply to come back. Nobody asks how valuable the contents are; the meter only measures how much was moved. A one-line question wrapped in a 600-word instruction manual is billed as the whole bundle, not the one line. And as Section 1 showed, the return leg is the expensive one. ## The model you choose determines 90% of the cost Not all AI is priced the same. There's a 100× price difference between the cheapest and most expensive models from major providers. Think of it like flights: economy gets you there, business class is more comfortable, and a private jet costs orders of magnitude more. Most of the time, economy works fine. ✅ Economy tier $0.10–$1 (₹8–₹84) per million tokens in · output runs ~5× higher Claude Haiku 4.5 ($1/M), Gemini Flash, and the small/fast tier from OpenAI Best for: classification, routing, simple Q&A, high-volume tasks where accuracy doesn't need to be perfect 📉 Standard tier $2–$3 (₹168–₹252) per million tokens in · output runs ~5× higher Claude Sonnet 5 ($2/M) and Sonnet 4.6 ($3/M), Gemini Pro, and the mid tier from OpenAI Best for: customer-facing replies, document analysis, content generation where quality matters 👑 Flagship tier $5–$10 (₹420–₹840) per million tokens in · output runs ~5× higher Claude Opus 4.8 ($5/M) and Fable 5 ($10/M), and the frontier model from each other provider Best for: complex reasoning, legal/financial analysis, tasks where a wrong answer has real consequences **⚠ The most common expensive mistake** Pilot projects default to flagship models because the team wants the best results and the cost at small scale is negligible. Then the rollout happens and nobody changed the default. Ask your team: which model is this actually running on? ## Where the money physically goes: GPUs The chips that run inference are GPUs, and the economics of your bill are the economics of that hardware. A single top-end AI chip costs roughly $25,000–$40,000 to buy and rents for a few dollars an hour, more through the big cloud providers. Large models don't fit on one — they need several chips wired together, standing by as a unit. Your per-token price is the provider taking that hourly cost and dividing it across everyone sharing the machine. When you hear that AI prices keep falling, that's the reason: better hardware and denser packing of queries onto each chip, not generosity. **✅ Where this changes a decision** It's why "let's just run it ourselves on our own GPUs" usually costs more, not less, until you have very high and very steady volume. A rented chip bills 24 hours a day whether or not your users are awake, and a model sitting in memory overnight costs the same as one answering questions. Providers stay cheap by keeping their chips loaded with everyone's traffic at once. Unless you can keep a GPU near-continuously busy, you're paying for idle silicon — and the break-even usually sits much higher than teams expect. Ask for the utilisation assumption behind any self-hosting proposal. ## Why memory, not speed, is the real constraint Here's the thing most cost conversations miss entirely. The scarce resource inside an AI system isn't processing speed. It's **memory on the chip** — and it gets consumed in two places. **First, the model has to sit there.** We covered this as the standing cost, but it's worth naming what it buys you: this is most of why the flagship tier costs 100× the economy tier. A flagship model is simply a much larger pile of numbers that has to be held in expensive memory and hauled through on every word it writes. You're not paying 100× for a cleverer answer so much as for a far bigger thing being kept resident and re-read constantly. Which is exactly why matching the tier to the task matters so much: on a routine classification job, you're renting a warehouse to store an envelope. **Second, every live conversation holds a working memory of its own.** As the model reads your prompt, it builds up notes on everything it has seen so it doesn't have to re-read the conversation from scratch for every new word it writes. Those notes live in chip memory for the duration of the conversation, and they grow with every turn. **Why long chats get slower and pricier:** the model keeps a running notebook on your conversation. Turn one, it's a page. Turn twenty, it's a folder that has to be carried into every subsequent word. Nothing was re-read, but something got heavier — and the meter reflects it. This single mechanism explains most of the behaviour you've noticed and been unable to explain: - **Why context windows have limits.** The advertised limit isn't arbitrary — it's partly how much working memory one conversation is allowed to occupy, and partly the point beyond which the model was never trained to stay reliable. - **Why long conversations get slower and more expensive.** Turn twenty genuinely costs more than turn one, on the same model, for the same question length. - **Why "just give the AI all our documents" is expensive advice.** Every document you stuff into the prompt occupies memory on every query, forever. Retrieving the three relevant paragraphs beats sending the whole handbook. **✅ The cost lever most teams have switched off** Remember the 600-word instruction manual sent on every single query? It's identical every time — so providers let you **cache** it. The model keeps its notes on that fixed portion instead of rebuilding them per query, and charges a fraction — often 10–25% — for the cached part. On a high-volume assistant where instructions and policy docs dominate every request, this cuts the bill substantially with no change to what the user sees. Two caveats worth knowing before you ask for it: the cache only lives for a few minutes, so it pays off on steady traffic rather than occasional use, and the unchanging text has to sit at the front of every prompt, which is usually a small change and occasionally a real one. Ask your team whether prompt caching is on — the answer is often no, simply because nobody asked. ### Why this needs a special kind of memory (HBM) Here's the part that connects everything above to a physical component you'll see in the news. Remember that writing an answer means running the entire model again for every single word. That means the chip has to read hundreds of gigabytes of numbers, from memory, per word. Ordinary computer memory cannot feed a chip that fast. It isn't a matter of capacity — it's a matter of how quickly bytes can be moved. So AI chips use **High Bandwidth Memory**, or HBM: memory stacked in layers and bonded directly onto the processor package, sitting millimetres away instead of centimetres, with a far wider path between the two. **Why the distance matters:** normal memory is a warehouse across town connected by a two-lane road. HBM is the same goods stacked in the room next door, connected by a hundred-lane road. The model has to be fetched in full for every word it writes, so the width of that road — not the speed of the processor — sets how fast and how cheaply the answer comes out. This is why inference is described as *memory-bound* rather than compute-bound: the chip usually isn't thinking hard, it's waiting for numbers to arrive. That is precisely why providers pack many customers into the same pass — it's the one thing that puts a waiting chip back to work. It also explains three things you may have read about without the connection being made. HBM is the genuine bottleneck in AI hardware — the constrained component the entire industry is fighting over, and a large share of what an AI chip costs to build. It's why memory manufacturers became AI stocks. And it's why your per-token price is what it is: you are renting bandwidth to a very expensive piece of silicon, shared with everyone else on that chip. For why this constraint is reshaping the whole hardware market, see our companion piece: [The Memory Boom](/analysis/memory-boom.html). ## The work that isn't the model Here's where most cost models break. Everything so far has priced the AI. Almost none of the work in a real deployment *is* the AI. A demo takes an afternoon: point a model at some documents, ask it questions, show the room. It works because a demo has no wrong answers, no unauthorised users, no systems of record, and no auditor. Production has all four. ### What the demo quietly skipped - **Your documents are not ready.** They're scanned PDFs, three conflicting versions of the same policy, and a SharePoint nobody has pruned since 2019. If the AI retrieves the superseded policy, it will state it with total confidence. Cleaning and structuring this is usually the single largest work item, and it is unglamorous enough that nobody scopes it. - **Permissions are the hard part.** This is where enterprise projects actually stall. Your existing access rules live in your applications — they do not automatically apply to a search index built from your documents. Build the retrieval layer without rebuilding entitlements into it, and the system will eventually show someone a salary band, a board pack, or another customer's file. Not as a bug, but as designed behaviour nobody specified. - **It has to write back.** An assistant that reads is a toy. One that raises the ticket, updates the CRM, and books the follow-up is a system — and now you're integrating with systems of record, which brings their release cycles and their change boards with it. - **You need a way to know it's right.** AI needs a graded set of real questions with known-good answers, re-run on every change. Teams that skip this cannot tell whether last week's prompt tweak improved things or quietly broke them. - **Somebody has to be in the loop.** Where does it escalate, who reviews low-confidence answers, and what does the user see when it doesn't know? Answer this early or your support team inherits it. - **Your monitoring doesn't cover this.** Existing tools watch uptime and latency. They do not watch token spend per feature, or answer quality drifting after a model update. Both will surprise you, one on the invoice and one in front of a customer. **⚠ The ratio nobody puts in the business case** Across enterprise deployments, the model work — prompts, model choice, tuning — is a small minority of the effort. The majority is data preparation, permissions, integration, evaluation and change management. This is why a pilot lands in weeks and production lands months later, and why "the AI part already works" is the most expensive sentence in the project. ### Where the first year's money goes Everything priced in this guide so far is the API bill. For a first serious deployment, that is typically the *smaller* share of what you spend in year one. Rough shape of a first-year budget: Where the money goes | Share of year one | What it actually is Engineering & integration | 40–50% | Building it, wiring it into systems of record, rebuilding entitlements into the retrieval layer Data preparation | 15–25% | Cleaning, structuring, deduplicating and permissioning the content the AI reads The API bill | 15–30% | Everything this guide has priced — tokens in, tokens out Evaluation & monitoring | 10–15% | Test sets, quality regression, spend and drift observability Change management | 5–10% | Training, rollout, handling what happens when it's wrong Indicative shares for a first enterprise deployment. The API share rises in later years as build costs fall away and usage grows — which is exactly when the model-tier and caching decisions in Section 2 start compounding. **✅ What to ask for** When a team brings you a number, ask which of these five rows it covers. If the answer is only the third one, you are looking at somewhere between a sixth and a third of the real figure. ## The layered stack, before and after Your enterprise stack has looked roughly the same for two decades. GenAI does not replace those layers. It *adds* six of them, and changes the character of three you already run. #### Your stack today Familiar, deterministic, well-understood Channel / UI*Web, mobile, branch, call centre* Application & business logic*Rules you wrote, behaving the same way every time* Integration*APIs, middleware, service bus* Data*Transactional systems, warehouse, lake* Infrastructure*Cloud or on-prem compute and storage* Identity & access*Who is allowed to see and do what* #### With GenAI enabled Every existing layer still there, six new ones added Channel / UI*Now also conversational* Guardrails*Stopping it leaking personal data, being tricked, or making things up* Orchestration*Assembling each prompt and deciding which systems to call* Model*The AI itself — rented by the token, or run on your own chips* Context & caching*Remembering the conversation, and not paying twice for the same instructions* Retrieval*Finding the three paragraphs that matter out of your whole document store* Application & business logic*No longer deterministic — same input, different output* Integration*Unchanged, but now called by the model, not just by you* Data*Same systems — now also a source for retrieval* Infrastructure*Unchanged, plus GPU capacity if self-hosting* Identity & access*Must now be enforced inside retrieval, not just the app* Evaluation & observability*Is it still right, what is it costing, and did the last model update break anything* **Blue** layers are genuinely new — nobody on your team has operated them before. **Yellow** layers already exist but change character — and those three are the ones most likely to be missed in planning. ### The three that will bite you **1. Your application layer stops being deterministic.** This is the deep one. Traditional software is a promise: the same input produces the same output, forever, and you test it with assertions that pass or fail. A model gives you a different answer to the same question on Tuesday than it did on Monday — and a model update you didn't control can shift behaviour across every feature at once. Testing becomes statistical rather than binary: not "does it pass" but "is it still right often enough." That changes QA, your release process, and what your on-call engineer can even do at 2am. **2. Access control moves down the stack.** As above: your existing rules live in the application, and the retrieval index does not inherit them. Retrofitting this after launch is painful, and it is a common reason pilots never reach production. **3. Caching stops working the way you know.** You can't cache answers when every question is phrased differently. What you cache is the repeated *input* instead — and your CDN knows nothing about it. **The uncomfortable summary** You are adding six operational layers your organisation has never run, changing the security properties of two you already have, and giving up determinism in the application tier. That is not an argument against doing it — the economics in this guide are genuinely compelling. It is an argument for scoping it as the platform change it is, rather than as a feature. ## Four use cases, four cost shapes "AI" isn't one thing on your bill. Each use case assembles the same pieces into a different shape, and each shape has its own cost signature. Here's what's running behind the four most common enterprise deployments — and where the meter actually sits in each. ### 💬 Chat & customer support Cost grows per turn User message*~6 words* → Search your docs*find 2–3 relevant bits* → Assemble prompt*instructions + docs + history* → Model call*the billed step* → Reply Moderate input, short output, but multiplied by every turn in the conversation — and the input grows as history accumulates. The search step before the model call is cheap and often overlooked, but it's what keeps the prompt small; without it you'd be sending the entire knowledge base every time. **Budget by conversation, not by message.** Caching absorbs the repeated instructions, but not the conversation history — so every turn carries everything said before it, and the last turn costs meaningfully more than the first. Teams that model cost as "queries × price per query" underestimate consistently, because real users don't ask one question and leave. ### 📄 Summarisation Input-heavy, cheapest per unit of value Long document*50 pages* → Split into chunks*if it exceeds the window* → Model call per chunk*the billed step* → Combine pass*billed again* → Summary Enormous input, tiny output. Since input tokens are the cheap half, this is the best value per unit of work in the entire catalogue — and it's why document summarisation is usually the highest-ROI first deployment. An economy-tier model handles most summarisation indistinguishably from a flagship one. **Watch for the second pass.** A document too long for the context window gets split, summarised in parts, and then the summaries get summarised. That's not one model call, it's N+1. And you pay every time you run it — summarising the same contract twice costs twice. Cache the output, not just the prompt. ### 📊 Insights & analytics Low volume, high value, flagship-worthy Business question*"why did North sales drop?"* → Model writes a query*billed* → Run against your database*not billed by the AI* → Model interprets results*billed* → Narrative answer The rare case where flagship tier is genuinely justified. Volume is low — a handful of analysts asking a few dozen questions a day — while the cost of a confidently wrong answer is high. Paying 20× more per query is trivially worth it when the query count is small and the decision is large. **The agentic multiplier.** When the model can't answer in one shot, it retries: rewrite the query, look at the result, try again. One business question can quietly become 8–15 model calls. That's fine at analyst volume and ruinous if you expose the same feature to 50,000 users. Ask your team what the cap on retries is — there should be one. ### 🎤 Voicebots Three meters, not one Caller speaks → Speech → text*billed per minute* → Model call*billed per token* → Text → speech*billed per character* → Caller hears reply This is the one that surprises people, because the AI model is often the *smallest* of three separate bills. Every spoken exchange pays a transcription meter, a language model meter, and a synthesis meter — each on a different unit. (Newer speech-to-speech models collapse all three into a single billed stream. That simplifies the invoice, not the economics — ask which architecture your team is proposing, because the cost shape differs.) Speech → text ~$0.004–$0.01 (~₹0.35–₹0.85) per minute of audio, including silence The model ~$0.002–$0.01 (~₹0.17–₹0.85) per exchange — usually the smallest line Text → speech ~$10–$30 (~₹840–₹2,500) per million characters spoken; more for premium or cloned voices **Latency forces your model choice, and your model choice was your budget.** A caller tolerates roughly 800 milliseconds before they need to hear *something*. The reply doesn't have to be finished — speech streams out as it's generated — but it has to have begun, and that budget still covers transcription plus the model's first words. In practice this rules the flagship tier out of real-time voice almost entirely: you'll be on economy or standard whether you planned to be or not. The second trap: you're billed per minute of call, not per question. Hold music, hesitation and dead air all run the transcription meter. **⚠ The pattern across all four** In every case, the model call is only one step in a pipeline — and it is frequently not the most expensive one. Voice pays three meters. Analytics pays a retry multiplier. Chat pays for accumulated history. When your team presents "the API cost," ask what else is in the pipeline. The gap between the model bill and the system bill is where budgets break. ## What it costs by use case — real numbers at 5,000 queries/day Here is the API bill on its own, at a realistic production volume. Keep the budget table from Section 3 in mind: this is the 15–30% row, not the whole invoice. It is, however, the row that scales with every new user you add — and the only one you can change with a configuration decision rather than a project. What you're building | Economy tier | Standard tier | Flagship tier | For context Customer support chatbot | $380–$600 (₹32K–₹50K)/mo | $1,200–$1,800 (₹97K–₹1.5L)/mo | $1,900–$3,000 (₹1.6L–₹2.5L)/mo | One support agent: ~$3,500 (₹40,000)/mo Document summarizer | $960–$1,500 (₹81K–₹1.3L)/mo | $2,900–$4,500 (₹2.4L–₹3.8L)/mo | $4,800–$7,500 (₹4.0L–₹6.3L)/mo | Analyst reading time: 30–60 min/document Internal knowledge Q&A | $630–$980 (₹53K–₹83K)/mo | $1,900–$3,000 (₹1.6L–₹2.5L)/mo | $3,200–$4,900 (₹2.6L–₹4.1L)/mo | Saves ~2–3 hrs/employee/week Email / content drafting | $390–$610 (₹33K–₹51K)/mo | $1,200–$1,800 (₹98K–₹1.5L)/mo | $2,000–$3,000 (₹1.6L–₹2.6L)/mo | ~20 min/day per knowledge worker Agentic AI (takes actions, uses tools) | $4,800–$7,500 (₹4.0L–₹6.3L)/mo | $14,000–$22,000 (₹12.1L–₹18.9L)/mo | $24,000–$38,000 (₹20.2L–₹31.5L)/mo | 5–15 AI calls per user action — costs multiply Voicebot (5,000 calls/day, ~3 min each) | $5,000–$8,000 (₹4.2L–₹6.7L)/mo | $12,000–$18,000 (₹10L–₹15L)/mo | Latency rules it out | Speech-to-text and text-to-speech included; the model is the smallest of the three Agentic AI (takes actions, uses tools) | $200–$400 (₹17K–₹34K)/mo | $1,800–$3,000 (₹1.5L–₹2.5L)/mo | $3,500–$6,000 (₹2.9L–₹5L)/mo | 5–15 AI calls per user action — costs multiply Computed from published list prices (July 2026) at 5,000 queries/day, or ~150,000/month, carrying the production context overhead from the worked example in Section 1 — roughly 1,900 tokens in and 260 out for a chat query. Tiers priced on Claude Haiku 4.5, Sonnet 4.6 and Opus 4.8 respectively; other providers sit in similar bands. Agentic estimates assume ~8 AI calls per task. Ranges are lean vs. full-context implementations. **✅ Two things that move these numbers a lot** These are **uncached list prices**, which is the honest starting point but rarely the final bill. Turn on prompt caching for the instruction manual and policy documents that repeat on every query and the cached portion bills at roughly a tenth — on a chat workload, where that repeated context dominates, this can cut the input half substantially. Batch processing takes another 50% off work that doesn't need an answer in the next second: overnight document processing, bulk summarisation, back-catalogue analysis. Neither changes what the user sees. Both are configuration decisions rather than projects, and together they are the difference between the numbers above and a bill you're comfortable defending. **💡 The agentic AI wildcard** A standard chatbot answers a question in one AI call. An "agentic" AI — one that takes actions, searches databases, or coordinates multiple steps — may make 8–15 AI calls per user request. Before you greenlight an agentic deployment, ask for the per-task cost model, not the per-call cost model. ## Three questions to answer before you approve the budget You don't need to understand any of the machinery in this guide to run a good approval conversation. You need three questions, and the confidence to keep asking until the answers are specific. Question 01 Which model tier is your team actually using? Most pilots default to flagship models. For many tasks — simple Q&A, classification, routing — an economy model at $0.15/M (₹13/M) tokens is indistinguishable to the user from one at $5.00/M (₹420/M). Ask your team to audit each use case and justify any flagship usage. The savings can be 20–50× for the right tasks. Question 02 Have you built a cost model at production volume? Take the pilot cost, multiply by your target user volume, and add 5× for production context overhead. That's your first rough estimate. If nobody on the team has done this before the rollout decision, the number will be a surprise. The estimator above is a starting point — ask for a more precise model from the engineering team before sign-off. Question 03 What does "cost per outcome" look like? Cost per query is a technical metric. Cost per resolved ticket, per drafted contract, per reviewed document — those are business metrics. Require the team to present AI costs in outcome terms, not API terms. A support bot that costs $500 (₹42,000)/month to handle 150,000 tickets is a very different conversation from "it costs $0.003 (₹0.25) per API call." ## The bottom line The economics here are genuinely good. A support bot that costs a few hundred dollars a month against a contact centre that costs thousands is not a marginal case, and the models keep getting cheaper for the same quality. The surprise is not the price of the AI. It's that the AI is the small part. Most of what you will spend goes on getting your documents in order, rebuilding who-can-see-what into a new layer, wiring the thing into systems that already exist, and learning to tell whether it is still right. None of that appears on the invoice you have been shown, and all of it appears on the one you eventually pay. So when the number comes back and someone has to explain it: ask which of those it covers. That single question is the whole guide. Share [LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Ftheaidaily.in%2Fanalysis%2Fllm-cost.html) [𝕏](https://twitter.com/intent/tweet?url=https%3A%2F%2Ftheaidaily.in%2Fanalysis%2Fllm-cost.html&text=Enterprise+AI+Costs+101%3A+a+primer+on+what+drives+AI+costs.+Only+0.4%25+of+what+you+are+billed+for+is+the+customer%27s+actual+words+via+%40AIDailyNews) [WhatsApp](https://wa.me/?text=Enterprise+AI+Costs+101+%E2%80%94+a+primer+on+what+drives+AI+costs+%E2%80%94+https%3A%2F%2Ftheaidaily.in%2Fanalysis%2Fllm-cost.html) **Data and methodology** Model pricing from Anthropic, OpenAI, and Google published documentation as of July 2026. The live tokeniser is a behavioural approximation, not a production tokeniser: it reproduces how common words stay whole while rare strings, identifiers and non-Latin scripts fragment, and lands within roughly 10–15% of GPT and Claude tokenisers on ordinary English prose. Treat its counts as indicative. Speech-to-text and text-to-speech rates reflect commonly published provider pricing and vary widely by vendor and quality tier; GPU purchase and rental figures are market ranges, not quotes. Use case cost estimates include typical production context overhead (system prompts, knowledge context, conversation history) based on common enterprise deployment patterns. Cost ranges (low/high) reflect lean vs. full-context implementations. Agentic AI estimates assume 8 AI calls per user task. All figures are indicative — actual costs vary by implementation. Prices are subject to change; validate against current provider documentation before budgeting.