--- title: "How to track LLM costs per feature: a worked example | Len P. van der Hof" description: Track LLM costs per feature with route labels, cost per request and budget alerts. Work through a flat-bill example and test one route today. image: "https://lenvanderhof.com/media/generated/blog-hero-cost-per-route-vs-monthly-bill.cb3817ad0d8e.wide.webp" --- [AI Systems](https://lenvanderhof.com/en/blog/category/ai-systems/) Research guide # Cost per route vs the monthly AI bill: meter where the money goes A flat monthly bill can hide a route that doubled its spend. Attribute each charge, separate volume from cost per request, and give the route an owner. Len P. van der HofPublished 7 November 202610 min read Four meters, each with its own dial. Meter each route, not only the total. Direct answer To track LLM costs per feature, tag every model attempt, including retries, with its route, feature and original request ID. Record the model, provider, billable usage, rates and latency. Sum each charge once by route, then by feature, and reconcile the total with the provider bill. Compare route totals with budgets, keep volume and cost per request beside them, and give each alert a named owner. ## Key takeaways - Attribute model spend to the routing rule first, then roll it up to the feature and budget owner. A model name alone does not identify the work. - Keep request volume beside total cost and cost per request. More traffic and a more expensive request require different investigations. - Count each billable attempt once, including retries and escalations. Route, feature and team totals are successive views of those charges. - Chapter 9 of The Model Portfolio proposes a warning at 75% of a route's weekly budget. A route on plan crosses it late in the week, so an early crossing is the signal. The warning neither proves waste nor enforces a cap. - Read cost beside latency and test quality separately. A cheaper route has not earned its place until it still meets the task's requirements. **A monthly AI total tells you how much you spent; per-route metering tells you which work spent it.** One route can double its cost while a reduction elsewhere keeps the bill flat. Even a rising total leaves the decision open: did you serve more requests, send more tokens, retry more often or change the model assignment? Chapter 9 of [The Model Portfolio](https://lenvanderhof.com/books/the-model-portfolio/) builds the distinction around attribution: measure the routing rule that spent the money, then connect it to the feature and team responsible. That turns a vague instruction to cut costs into a review of one named route. The meter narrows the investigation; logs and tests still have to establish the cause. ## How do I track LLM costs per feature instead of one monthly bill? Give each model call a route label, a feature label and an owner. Record its usage and timing, calculate its cost, and sum the records by route over a stated period. Add the route costs belonging to each feature to get the feature total. A **route** here is a named routing rule or task type, such as `knowledge.answer`. A **feature**, or product surface, is what that work serves: an internal knowledge assistant, for example. One feature can use several routes. If a route serves several features, retain the feature label on each invocation so you can split its cost correctly. These are successive views of the same charges: **attempt → route → feature → budget owner**. Do not add the route subtotal to the feature subtotal and count the money twice. Here, “cost per route” means a route’s total over a stated period; “cost per request” is a separate calculation. Keep the route name stable when its model changes, and record the model separately. Otherwise a comparison across months also becomes a reconstruction of renamed work. [What is model routing?](https://lenvanderhof.com/en/blog/what-is-model-routing/) covers the policy behind the label; here the job is to measure its consequences. Use your existing logs to capture these groups of fields: RecordWhat to retainWhat it lets you checkAttributionRoute, feature, budget ownerWhich work generated the chargeIdentityOriginal request ID, individual attempt ID, timestampWhich calls belong to the same requestAssignmentActual model, provider and service tierWhether the assignment changedUsageInput, output and relevant billing-category breakdownsWhich usage component grewTimingEnd-to-end duration; first-token time for streamingWhether users are waiting longerExecutionResult, retry count and escalation flagWhether extra attempts explain the spend A model-only report cannot provide this attribution when several features share the model. A spreadsheet built from labelled log exports can. Start with the labels and the decision you need to make. ## How do I calculate cost per route and per request? For each billable usage category, divide the count by the rate’s billing unit and multiply by the applicable rate. Add the categories once. Keep the rate and its effective date with the calculation so you can distinguish changed usage from changed pricing. Build non-overlapping billing lines from the provider’s definitions. A total and its component breakdown are not separate amounts to add together. Check how cached input and reasoning are included before pricing them; [How to read an AI bill](https://lenvanderhof.com/en/blog/ai-token-pricing-explained/) covers those distinctions. Sum every billable attempt attributed to the route, then add any route charges billed against elapsed time rather than traffic, such as hourly cache storage. A failed attempt with a charge still belongs in the cost. Missing usage is unknown, not zero. Keep the denominator explicit: **Cost per route request = all attributed route charges ÷ original requests entering that route.** Include billable retries and escalation calls in the cost, while counting the original request once. Track attempts separately. For **cost per completed feature task**, sum the charges attributed to that feature across all its routes and divide by completed tasks over the same period. Label the measure clearly: a request, an attempt and a completed task are different units. Reconcile the attributed totals against provider billing for the same period and billing basis. Keep fees, credits and unexplained differences visible on separate lines. If older records lack feature labels, label any reconstruction as an estimate and retain an unallocated balance. An exact monthly total does not make an estimated split exact. ## What can a flat monthly bill hide? A hypothetical example Imagine a small software product with three routes. All figures below are hypothetical. Each request makes one successful billable model call; there are no retries, caching, hidden reasoning or other charges. Each route serves one feature. RoutePrevious requestsPrevious costCurrent requestsCurrent costsupport.chat40,000€80040,000€800knowledge.answer10,000€60010,000€1,200catalogue.enrich20,000€1,60020,000€1,000Total70,000€3,00070,000€3,000 The bill and total request count are unchanged. Within them, `knowledge.answer` has doubled its cost per request from €0.06 to €0.12. The €600 reduction on `catalogue.enrich` cancels the €600 increase on `knowledge.answer`. Work through the knowledge route. Assume invented rates of €2 per million input tokens and €6 per million output tokens, unchanged across both months. Previously, each request used 24,000 input tokens and 2,000 output tokens: **24,000 ÷ 1,000,000 × €2 + 2,000 ÷ 1,000,000 × €6 = €0.06.** Now each request sends 54,000 input tokens while output stays at 2,000: **54,000 ÷ 1,000,000 × €2 + 2,000 ÷ 1,000,000 × €6 = €0.12.** At 10,000 requests, those costs become €600 and €1,200. The unchanged volume rules out traffic growth as the explanation within this example. The category breakdown locates the increase in input usage. Suppose the traces identify a 30,000-token context block added by a prompt edit. Chapter 9 opens with a composite case of the same shape: a prompt refactor added a full document summary to every request on an internal knowledge route, and nobody noticed for weeks because the answers looked the same to users. Test whether the block is needed for correct answers before removing it. The calculation establishes its cost, not its value. Had the request count doubled while cost per request stayed constant, the first investigation would concern what generated the extra requests. Changing models would address a different question. ## Which signals belong beside cost? Chapter 9 groups the operating measurements into five signals: token volume, cost, latency percentiles, routing-decision volume and escalation rate. Keep them together. Cost ranks the money involved; the other measurements help explain what moved. Use one dashboard row per route. Show cost over the last seven days against its weekly budget, p95 latency against its service-level objective, escalation rate where applicable, and request-volume trend. Add how long a breach has lasted, its owner and the next review date. The **p95 latency** is the duration at or below which approximately 95% of measured requests finish. Measure the full route from arrival to delivered response. Keep p50 and p99 available for investigation, and first-token time separately for streaming responses. Choose an observation window and minimum sample size that fit the route’s traffic. Return to the hypothetical product. Suppose `support.chat` still costs €800, but its p95 rises from 0.8 seconds to 1.4 seconds against a one-second target. The cost line is unchanged; the latency line requires attention. A cost-only view misses that failure. For a route that escalates requests to another model, record the fraction escalated and the charges from both stages. An increase points to changed inputs, quality or escalation criteria, without telling you which. ## When should a route alert trigger a review? Set the budget from expected traffic and intended usage, including planned retries and escalations. Do not turn an inefficient observed cost into an acceptable target simply because it is familiar. Sum route budgets over the same period and check that they fit the product’s overall model budget. Chapter 9 offers **75% of a weekly route budget** as an illustrative early-warning threshold, low enough to leave time to act before the budget is gone. For the hypothetical knowledge route, suppose the weekly plan is 2,500 requests at the intended €0.06 each. The budget is €150; the warning threshold is €112.50. Fix the clock first. Counted from the start of the budget week, a route spending evenly to plan crosses €112.50 on day six. A crossing by midweek means it is spending well ahead of plan: that is the signal. On a rolling seven-day total, the chapter’s dashboard view, a route on plan sits near €150 every day, so a 75% warning would never clear. Put the warning on the budget week. It asks someone to inspect the route; it does not prove waste. The chapter’s initial budget-review heuristic is an overrun lasting beyond 72 hours. That clock starts after spending exceeds the budget, not after the 75% warning. Adjust the review window for the route’s volume, latency class and risk. An obvious runaway needs attention immediately. Latency has its own warning: the chapter starts it at 80% of the p95 target and tunes it after false alarms and missed incidents. A breach of the target itself that persists across the route’s window, from hours for real-time routes to up to seven days for batch, triggers review. So does an escalation rate above 150% of baseline for seven or more days, and so does any new route or model without a budget and latency target. Those belong in place before production traffic, or within 24 hours at the outside if the route slipped past the gate. Give the alert an owner and a first action: compare volume, token categories, assignments and retries with the previous period. Close the review with what changed, why, and when to check again. An alert reports a condition. Enforcing a spending ceiling is a separate control; [agent runtime budgets](https://lenvanderhof.com/en/blog/agent-runtime-budget/) cover that task-level boundary. ## What does this dashboard leave unanswered? The most expensive route is a useful starting point, not automatically the worst allocation. It may serve the most valuable work. A cheaper model, shorter prompt or altered escalation rule needs its own quality test before you accept the change. Model charges also leave out the rest of a feature’s economics unless you explicitly add them: infrastructure, paid tools and human review, for example. Keep the scope visible. Calling a model-cost total “profitability” would claim more than you measured. The book’s evidence ledger records this dashboard as the author’s own design and clears no claim that it reduces cost. Judge the first implementation by whether it produces attributable records and actionable alerts; measure any resulting savings separately. ## Try this today Split last month’s model spend by route or feature, even roughly. Rank the routes, and give the top one the book’s starting budget alert this week. 1. **Make the first attribution table.** Match last month’s billing and usage records to route and feature labels. Write one row per route with cost, original requests, owner and whether the amount is measured or estimated. Keep unsupported attribution unallocated and reconcile the sum to the bill on the same basis. 2. **Rank the rows.** Sort by total cost, then calculate cost per request. Pick the top route. If you only have feature totals, choose the top feature and identify the route labels it needs. 3. **Set an intended weekly budget.** Use expected requests and target usage at the applicable rates, with additional calls included. Compare it with observed spend. Check that route allocations and the product ceiling use the same period. 4. **Write the 75% warning.** State the clock (spending since the start of the budget week), the threshold amount, the owner and the first investigation. Add the route’s p95 target and a review date. If you lack historical labels, start collecting them now; leave the past split marked as an estimate. 5. **Test the boundary offline.** For the example’s €112.50 threshold, feed a test copy of the rule week-to-date totals of €112.49, €112.50 and €112.51. Under “exceeds”, only the third should warn. Check that the result names the right route, amount and owner. Record this as a rule test, not proof of production coverage. 6. **Trace one real request.** Follow its ID through every charged attempt into the route and feature totals. Check the usage, rates and retry count against the source records. Each charge must appear once in each view. If you cannot trace the request, name the missing label or usage field and assign the fix. If you cannot reconcile the totals, leave the difference visible. Finish with one accountable route and an explicit record of what its meter can and cannot yet show. Cite this:Cost per route vs the monthly AI bill: meter where the money goes.Len P. van der Hof. [https://lenvanderhof.com/en/blog/cost-per-route-vs-monthly-bill/](https://lenvanderhof.com/en/blog/cost-per-route-vs-monthly-bill/) · Published 7 November 2026. ## Sources 1. [The Model Portfolio, chapter 9: Track Cost and Latency](https://lenvanderhof.com/books/the-model-portfolio/) 2. [What does '$3 per million tokens' mean? How to read an AI bill](https://lenvanderhof.com/en/blog/ai-token-pricing-explained/) 3. [Agent runtime budget: keep retries inside the same ceiling](https://lenvanderhof.com/en/blog/agent-runtime-budget/) 4. [What is model routing? A policy, not a default](https://lenvanderhof.com/en/blog/what-is-model-routing/) ## Further reading - [What does '$3 per million tokens' mean? How to read an AI bill](https://lenvanderhof.com/en/blog/ai-token-pricing-explained/) - [Agent runtime budget: keep retries inside the same ceiling](https://lenvanderhof.com/en/blog/agent-runtime-budget/) - [What is model routing? A policy, not a default](https://lenvanderhof.com/en/blog/what-is-model-routing/) - [The Model Portfolio](https://lenvanderhof.com/books/the-model-portfolio/) About the author ## [Len P. van der Hof](https://lenvanderhof.com/en/authors/len-p-van-der-hof/) Entrepreneur, AI Innovator and Venture Builder Len P. van der Hof builds practical AI systems, digital ventures and evidence-informed tools for founders. ```json { "@context": "https://schema.org", "@graph": [ { "@type": "Person", "@id": "https://lenvanderhof.com/#person", "name": "Len P. van der Hof", "alternateName": [ "Len van der Hof", "L.P. van der Hof", "Leendert Pieter van der Hof" ], "honorificSuffix": "MSc", "url": "https://lenvanderhof.com/", "image": [ "https://lenvanderhof.com/photos/len-portrait-1.jpg", "https://lenvanderhof.com/photos/len-portrait-2.jpg", "https://lenvanderhof.com/photos/len-portrait-3.jpg", "https://lenvanderhof.com/photos/len-portrait-4.jpg", "https://lenvanderhof.com/photos/len-speaking.jpg", "https://lenvanderhof.com/photos/len-hero.jpg" ], "jobTitle": "Entrepreneur, AI Innovator and Venture Builder", "description": "Len P. van der Hof, MSc, is a Dutch entrepreneur and AI innovator in Zwijndrecht. He builds ReasonKit, MindSesh, Undominated.ai, books under his name, the fiction imprint LPH98.lifestyle, and technology ventures through LPH98.ventures. Eleven titles in Systems for the Strategic Self are available now, in English and Dutch.", "address": { "@type": "PostalAddress", "addressLocality": "Zwijndrecht", "addressCountry": "NL" }, "alumniOf": { "@type": "CollegeOrUniversity", "name": "Rotterdam School of Management, Erasmus University" }, "knowsAbout": [ "Artificial intelligence", "AI agents", "Agentic AI systems", "LLM routing", "SEO", "Generative engine optimization", "Answer engine optimization", "Venture building", "Founder performance", "Founder psychology", "Evidence-based decision-making" ], "sameAs": [ "https://www.linkedin.com/in/lenvanderhof/", "https://x.com/LenvanderHof", "https://www.youtube.com/channel/UCTG20buKqYYbitqqf7l3zJA", "https://www.instagram.com/Lenvanderhof/", "https://www.threads.com/@lenvanderhof", "https://github.com/Lenvanderhof", "https://huggingface.co/LPH98", "https://www.npmjs.com/~lenvanderhof", "https://www.goodreads.com/author/show/70983905.Len_P_van_der_Hof", "https://www.amazon.com/author/lenvanderhof", "https://www.bol.com/nl/nl/b/len-p-van-der-hof-msc/609879394/", "https://bsky.app/profile/lenvanderhof.com", "https://mastodon.social/@Lenvanderhof", "https://crates.io/users/Lenvanderhof", "https://cursor.com/@Lenvanderhof", "https://medium.com/@Lenvanderhof", "https://gitlab.com/Lenvanderhof", "https://hub.docker.com/u/lenvanderhof/", "https://dev.to/lenvanderhof", "https://www.facebook.com/Lenvanderhof", "https://soundcloud.com/Lenvanderhof" ], "affiliation": [ { "@id": "https://lenvanderhof.com/#publisher" }, { "@id": "https://lenvanderhof.com/#mindsesh" }, { "@id": "https://lenvanderhof.com/#lifestyle" } ] }, { "@type": "WebSite", "@id": "https://lenvanderhof.com/#website", "url": "https://lenvanderhof.com/", "name": "Len P. van der Hof", "description": "Len P. van der Hof, MSc, is a Dutch entrepreneur and AI innovator in Zwijndrecht. He builds ReasonKit, MindSesh, Undominated.ai, books under his name, the fiction imprint LPH98.lifestyle, and technology ventures through LPH98.ventures. Eleven titles in Systems for the Strategic Self are available now, in English and Dutch.", "inLanguage": [ "en", "nl" ], "publisher": { "@id": "https://lenvanderhof.com/#person" } }, { "@type": "Organization", "@id": "https://lenvanderhof.com/#publisher", "name": "LPH98.ventures", "url": "https://lph98.ventures", "founder": { "@id": "https://lenvanderhof.com/#person" } }, { "@type": "Organization", "@id": "https://lenvanderhof.com/#mindsesh", "name": "MindSesh", "url": "https://mindsesh.net", "founder": { "@id": "https://lenvanderhof.com/#person" } }, { "@type": "SoftwareApplication", "@id": "https://lenvanderhof.com/#reasonkit", "name": "ReasonKit", "url": "https://reasonkit.sh", "creator": { "@id": "https://lenvanderhof.com/#person" } }, { "@type": "SoftwareApplication", "@id": "https://lenvanderhof.com/#undominated", "name": "Undominated.ai", "url": "https://undominated.ai", "creator": { "@id": "https://lenvanderhof.com/#person" } }, { "@type": "Organization", "@id": "https://lenvanderhof.com/#lifestyle", "name": "LPH98.lifestyle", "url": "https://lph98.lifestyle", "founder": { "@id": "https://lenvanderhof.com/#person" } }, { "@type": "ImageObject", "@id": "https://lenvanderhof.com/en/blog/cost-per-route-vs-monthly-bill/#primaryimage", "url": "https://lenvanderhof.com/media/generated/blog-hero-cost-per-route-vs-monthly-bill.cb3817ad0d8e.wide.webp", "contentUrl": "https://lenvanderhof.com/media/generated/blog-hero-cost-per-route-vs-monthly-bill.cb3817ad0d8e.wide.webp", "representativeOfPage": true }, { "@type": "BreadcrumbList", "@id": "https://lenvanderhof.com/en/blog/cost-per-route-vs-monthly-bill/#breadcrumb", "itemListElement": [ { "@type": "ListItem", "position": 1, "name": "Home", "item": "https://lenvanderhof.com/" }, { "@type": "ListItem", "position": 2, "name": "Blog", "item": "https://lenvanderhof.com/en/blog/" }, { "@type": "ListItem", "position": 3, "name": "AI Systems", "item": "https://lenvanderhof.com/en/blog/category/ai-systems/" }, { "@type": "ListItem", "position": 4, "name": "Cost per route vs the monthly AI bill: meter where the money goes", "item": "https://lenvanderhof.com/en/blog/cost-per-route-vs-monthly-bill/" } ] }, { "@type": "WebPage", "@id": "https://lenvanderhof.com/en/blog/cost-per-route-vs-monthly-bill/#webpage", "url": "https://lenvanderhof.com/en/blog/cost-per-route-vs-monthly-bill/", "name": "Cost per route vs the monthly AI bill: meter where the money goes", "description": "Track LLM costs per feature with route labels, cost per request and budget alerts. Work through a flat-bill example and test one route today.", "isPartOf": { "@id": "https://lenvanderhof.com/#website" }, "primaryImageOfPage": { "@id": "https://lenvanderhof.com/en/blog/cost-per-route-vs-monthly-bill/#primaryimage" }, "breadcrumb": { "@id": "https://lenvanderhof.com/en/blog/cost-per-route-vs-monthly-bill/#breadcrumb" }, "inLanguage": "en-GB" }, { "@type": "BlogPosting", "@id": "https://lenvanderhof.com/en/blog/cost-per-route-vs-monthly-bill/#article", "mainEntityOfPage": { "@id": "https://lenvanderhof.com/en/blog/cost-per-route-vs-monthly-bill/#webpage" }, "headline": "Cost per route vs the monthly AI bill: meter where the money goes", "description": "Track LLM costs per feature with route labels, cost per request and budget alerts. Work through a flat-bill example and test one route today.", "datePublished": "2026-11-07T15:00:00.000Z", "author": { "@id": "https://lenvanderhof.com/#person" }, "publisher": { "@id": "https://lenvanderhof.com/#person" }, "image": [ "https://lenvanderhof.com/media/generated/blog-hero-cost-per-route-vs-monthly-bill.cb3817ad0d8e.square.webp", "https://lenvanderhof.com/media/generated/blog-hero-cost-per-route-vs-monthly-bill.cb3817ad0d8e.landscape.webp", "https://lenvanderhof.com/media/generated/blog-hero-cost-per-route-vs-monthly-bill.cb3817ad0d8e.wide.webp" ], "articleSection": "AI Systems", "inLanguage": "en-GB" } ] } ```