Average monthly AI cloud spend has reached roughly USD 85,000 per organisation, growing 36% year over year. For a Singapore mid-market company that figure sounds like someone else’s problem, until you notice how much of it arrives without a decision being made.
The spend pattern has changed shape since 2023. In the old model, runaway cloud bills came from idle virtual machines, forgotten snapshots and commitments nobody renewed correctly. Those still exist and they are largely solved problems with known tooling. What drives the bill now is different: large models, always-on inference endpoints, bursty training jobs, and hybrid architectures where the same work runs in two places because nobody consolidated it.
This matters because the old playbook does not find the new waste. A cost tool that reports idle compute will report a healthy picture for a workload whose entire problem is that it calls a frontier model forty thousand times a day to classify support tickets into five buckets. Nothing is idle. Everything is running. The architecture is the waste.
The encouraging part is how much room there usually is. Full optimisation across eligible workloads commonly returns 30% to 50% inside 60 days, and teams combining automation with predictive scaling report 30% to 40% efficiency improvements. Those are large numbers for work that rarely requires rewriting an application.
Why the old cost playbook misses
Traditional FinOps asks what is switched on that should be off. AI cost work asks a different question: is this workload shaped correctly for what it does.
Consider the difference in where the money sits. A classic web application’s cost is dominated by provisioned capacity, so the lever is right-sizing. An AI application’s cost is dominated by tokens and GPU hours, and both scale with how the work is routed rather than with how big the instance is. You can right-size every instance in the account and change the bill by a few per cent.
The FinOps Foundation found that 67% of organisations now run a formal FinOps practice. Far fewer have anyone whose job includes reviewing which model handles which task, and that review is usually where the largest single saving sits.
The five levers, in order of payback
Match the model to the task. This is the biggest lever and the least exercised. Classification, extraction, routing, short summarisation and structured-output work are handled well by smaller and cheaper models. Reasoning over long documents, multi-step planning and code generation are where a frontier model earns its price. Most systems built in the last two years route everything to one model because that was simpler to ship, and the bill reflects a capability the work does not use. Splitting a high-volume path onto a smaller model routinely cuts that path’s cost by an order of magnitude with no measurable quality change, which is a claim worth testing on your own traffic rather than taking on faith.
Cache your prompts. If your requests share a long stable prefix, a system prompt, a policy document, a product catalogue, you are paying full input price for the same tokens on every call. Cache reads are priced at roughly a tenth of fresh input tokens at Anthropic, with comparable mechanisms elsewhere. For a system with a 20,000-token system prompt and high call volume, this single change is often the difference between a viable unit economic and an unviable one.
Batch everything that is not interactive. Batch processing is priced at about half the interactive rate at the major providers. Nightly summarisation, bulk enrichment, backfills, report generation and evaluation runs have no human waiting on them, so paying interactive rates for them is a pure loss. The work to move a job to a batch endpoint is usually a day.
Scale training with spot and autoscaling, not reservations. GPU-backed training and fine-tuning is bursty by nature, which makes spot capacity and aggressive autoscaling a good fit and long commitments a poor one. Steady-state inference is the reverse, and that is where provisioned capacity and committed-use discounts pay off. Teams frequently get this backwards, reserving capacity for the bursty half and paying on demand for the predictable half.
Measure cost per outcome, not cost per token. A token price is not a unit economic. Cost per resolved ticket, per processed invoice, per qualified lead is the number a finance team can act on, and it is the only framing that tells you whether a more expensive model is actually more expensive. A model that costs triple per call and halves the escalation rate is cheaper.
What this looks like on a real budget
Put numbers on a modest system. An agentic support workflow handling 30,000 conversations a month, each averaging a 15,000-token system prompt plus 2,000 tokens of conversation, all routed to a frontier model, all interactive.
Apply three levers. Route the intent-classification step to a small model, which removes roughly a third of the calls from the expensive path. Cache the system prompt, which takes 15,000 tokens per call down to near nothing after the first. Move the nightly quality-review pass to batch.
None of that touches the product. The user experience is identical. The arithmetic on a workload shaped like that commonly lands between a half and a third of the original run rate, and the engineering effort is measured in days rather than quarters.
One regional detail shifts the maths for companies here. Workloads pinned to ap-southeast-1 for data residency reasons carry different instance pricing and different model availability than the US regions the published benchmarks assume, and the newest model tiers often reach Singapore later. That occasionally means the cheaper small model you want for a high-volume path is not yet available in-region, and the choice becomes a residency question rather than a cost one. Worth establishing before the architecture is set, because moving a workload across regions after launch is considerably more expensive than choosing correctly at the start.
When to stop
Worth saying plainly, because cost work has a habit of expanding past its value. For Singapore enterprises early in FinOps maturity, or spending below roughly SGD 700,000 a year on AWS, native cloud tooling is sufficient and a third-party platform subscription is premature. Tools earn their cost at higher spend or across multiple clouds.
The same restraint applies to the architecture. Once the five levers above are in place, the remaining savings get small and the complexity cost gets real. A semantic cache that returns a wrong answer to save a fraction of a cent is a bad trade, and so is a routing layer so elaborate that nobody can predict which model served a given request.
Where to start this quarter
Pull a month of request logs and group them by task type, then put the model used and the token volume next to each group. That single table tells you whether you have a model-selection problem, a caching problem, or neither. Most teams have never built it, and building it takes an afternoon.
Webpuppies designs and runs AI systems on AWS, Anthropic and OpenAI infrastructure as an AWS Select Tier Services Partner, an OpenAI Select Partner and a member of the Anthropic Claude Partner Network, which means we see the cost behaviour of the same workload across all three. If your AI spend is growing faster than your usage, get in touch and we will read the logs with you.
Sources
- AI Workload Cloud Cost Management Guide 2026, SquareOps
- Cloud Cost Optimization 2026: Visibility to Automation, Sedai
- Best Cloud Cost Optimization Tools in Singapore, 2026
- Cloud Cost Optimization in 2026: How AI-Driven FinOps Is Transforming Enterprise IT Spending, Intellectt
Frequently Asked Questions
What drives AI inference costs up?
Running a frontier model on work a smaller model handles, sending the same context repeatedly without caching, treating batch work as interactive, and leaving inference capacity provisioned at peak levels around the clock.
How much can AI cloud spend realistically be reduced?
Full optimisation across eligible workloads commonly returns 30% to 50% within 60 days, and combining automation with predictive scaling typically yields 30% to 40% efficiency improvements. The range depends on how much of the spend is inference versus training.
Does prompt caching actually save money?
Yes, substantially, when your prompts share a large stable prefix such as a system prompt or a document. Cache reads are priced at a fraction of fresh input tokens, around a tenth at Anthropic, so a long reused context becomes close to free after the first call.
Should a Singapore company use native cloud cost tools or a third-party platform?
Enterprises early in FinOps maturity or spending below roughly SGD 700,000 a year on AWS should start with native tooling. Third-party platforms earn their subscription at higher spend or across multiple clouds.
What is the difference between AI cost management and traditional FinOps?
Traditional FinOps targets idle resources and unused commitments. AI cost management targets architectural choices such as model selection, caching, batching and scheduling, where the savings come from how the workload is designed rather than from what is switched off.
