标签：#cost

The cloud bill is the only number in most companies that nobody on the team owns until it's already a problem. Engineering owns latency. It owns error rates, p99, uptime, the whole observability wall. Finance owns the invoice. And between those two ownerships there's a gap wide enough to drive a fifth to a third of your cloud spend straight into a wall — which, across the industry, is roughly what happens. The fix isn't a smarter spreadsheet at month-end. Real cloud cost management isn't an accounting function at all — the fix is to stop treating the bill as accounting and start treating it as a product metric: cost per request, cost per tenant, cost per feature, sitting on the same dashboard as latency and error rate, owned by the same people who own those numbers. That's the whole argument. The rest of this post is why it's true and how it's done. The bill is a lagging accounting artifact, and that's the bug Here's how cloud cost is treated almost everywhere. A bill arrives. Someone in finance reconciles it against a budget. If it's higher than expected, a thread gets opened, an engineer gets pulled in, and everyone spends a week spelunking through Cost Explorer trying to reconstruct why a number that's already been spent is what it is. Then it happens again next month. Every part of that loop is broken. The signal arrives weeks after the decision that caused it. The person reading the signal can't act on it. The person who can act on it never sees it. And the unit of measurement — total dollars — tells you nothing about whether the spend was good . A bill that doubled because you doubled revenue is a triumph. A bill that doubled because someone left a debug log streaming to an expensive tier is a fire. Total dollars can't tell those two apart. They look identical on the invoice. This is the same mistake we'd never make with any other production signal. Nobody reviews latency once a month from a PDF. Nobody waits for finance to tell engineering that p99 regressed.

Most S3 bills are wrong, and the fix takes an afternoon. The data sits in the most expensive class AWS offers (S3 Standard, $0.023/GB-month), nobody set a lifecycle policy, incomplete multipart uploads are silently billing for storage you can't even see in the console, and every byte your EC2 fleet pulls from S3 is routed out through a NAT Gateway when a free VPC Gateway Endpoint would do the same job for $0. None of this needs an architecture rewrite. It needs a checklist run in the right order. Here is the order. The savings depend entirely on your access pattern — I will not promise you a number I can't see — but the mistakes below are so common that the question is usually how much , not whether . One number is just arithmetic: cold data that moves from S3 Standard ($0.023/GB-month) to Glacier Deep Archive ($0.00099/GB-month) drops about 96% on the storage line for those bytes, and on an observability platform I ran — logs aged past 90 days into Deep Archive — that is exactly the lever that did the work. S3 cost optimization is the same boring discipline as the rest of the bill: see it, then decide what each byte should actually cost. First, see the bill before you touch it You cannot optimize what you cannot measure, and S3's default billing view tells you nearly nothing useful. Turn on S3 Storage Lens before anything else. The free tier gives you 62 metrics at the bucket level with 14 days of history, and crucially it includes cost-optimization metrics out of the box — including "Incomplete multipart upload bytes greater than 7 days old," which is the single most common source of money disappearing into storage nobody knows exists ( AWS S3 Storage Lens docs , accessed 2026-06-18). Storage Lens free metrics answer the three questions that decide everything that follows: Which buckets hold the most bytes? What storage class is that data sitting in right now? Where are the incomplete multipart uploads? For deeper per-prefix analysis or a longer history, Advanced

For AWS Savings Plans vs Reserved Instances, the default answer is: buy a Savings Plan, not a Reserved Instance. The exception is OpenSearch, Redshift, and (until December 2025) databases, which still need the older Reserved model. That is the whole decision. For most teams a Compute Savings Plan is the right default: same discount as a Convertible Reserved Instance, far less to manage, and it follows your workload across instance families, regions, Fargate, and Lambda. The cases where a Reserved Instance still wins are narrow and specific, and the December 2025 launch of Database Savings Plans shrank them further. This post is the decision — RI vs Savings Plan, when each wins. It is not a deep-dive on how Savings Plans work under the hood; I cover the mechanics — how the $/hour commitment gets applied, the billing-hour math, the queue order against On-Demand — in a separate post. Here I only want to answer the question you actually have when the Cost Explorer recommendation pops up: which one do I buy? (Commitments are step three of a full bill audit — where they sit in the order is in what I'd audit first on a $50K AWS bill .) The short version Both Reserved Instances and Savings Plans are the same trade: you promise AWS a one- or three-year commitment, AWS gives you a discount over On-Demand. The difference is what you commit to . A Reserved Instance commits you to a specific instance configuration — family, and depending on type, size, region, OS, tenancy. A Savings Plan commits you to a dollar amount of usage per hour (e.g. "$10/hour of compute"), and AWS applies that discount to whatever matching usage you actually run. The Savings Plan is the more flexible instrument at the same discount level, which is why AWS itself now recommends Savings Plans over Reserved Instances for compute. ( AWS, Compute Savings Plans and Reserved Instances , accessed June 2026.) The Reserved Instance has not gone away — but for EC2 compute, it is mostly the legacy choice now. The d

If your AWS bill has a NAT Gateway line, you are paying twice for the same packet: once for the gateway to merely exist, and again for every gigabyte it carries. The fix for most teams is dull and free. Add an S3 and a DynamoDB gateway endpoint, route the heavy traffic away from NAT, and only then argue about anything fancier. That single change is free to turn on, takes minutes, and stops the most expensive traffic from ever touching the meter. This is a playbook, not a lecture. The trick with NAT Gateway pricing is that the two charges hide in different places on the bill, so most teams only ever see half of it. Numbers first, then the fixes, in the order I would actually do them. What you are actually being charged for NAT Gateway has two charges, and people forget the second one until they read the bill closely. Hourly charge — you pay for every hour the gateway is provisioned and available, whether or not a single byte moves through it. In us-east-1 (N. Virginia) and us-east-2 (Ohio) this is $0.045 per NAT Gateway-hour . That is roughly $32.85 a month per gateway just to keep the lights on. Partial hours bill as full hours. Data processing charge — you pay $0.045 per GB processed through the gateway, in the same region, on top of the hourly charge. This applies to every gigabyte, inbound or outbound, regardless of source or destination. And then there is the part the pricing page mentions almost in passing: standard AWS data transfer charges still apply on top. NAT processing is an extra meter on traffic you were already paying to move. The hourly charge is fixed and visible. The per-GB charge is the one that catches teams out, because it scales with traffic you mostly cannot see: package installs, container image pulls, S3 reads from private subnets, telemetry shipped out, cross-region calls. The rate varies by region (it runs higher in places like São Paulo, where both the hourly and per-GB rates sit around $0.093), so check your own region rather than trusti

Give me read access to a $50,000/month AWS account and I will tell you within a day where the first 20-30% is hiding, because on a mid-size bill it is almost always hiding in the same four places, in the same order: data transfer you can't see in the console, instances sized for a load test that ran two years ago, on-demand pricing on a baseline that never moves, and storage rotting in the most expensive class AWS sells. None of this needs an architecture rewrite. AWS cost optimization, at least the first and biggest pass of it, is just the bill read in the right order by someone who knows where AWS buries the meter. This is the order I work. It is the same audit I run on every account I'm handed, and it is the offer — if you want me to run it on yours, the post ends with how. But you can run most of it yourself today, and you should, because nobody is going to care about your bill as much as you do. A note before the recipe: I deal in ranges, not promises. The exact saving on your account depends on what you've built. What I can promise is that the mistakes below are common enough that the question is usually how much , not whether . Hour zero: get the real bill, not the dashboard Before touching a single resource, I want the granular data. The AWS console's cost dashboard rounds, groups, and hides the things that matter. Two tools give you the truth. Cost Explorer , with rightsizing recommendations turned on, is the fast view — group by service, then by usage type, and the bill stops being one big number and starts being a list of decisions. Resource-level and hourly granularity costs extra ($0.01 per 1,000 usage records per month), but for one audit pass it's worth pennies. The Cost and Usage Report (CUR) is the ground truth — line-item, hourly, every charge AWS makes, delivered to your own S3 bucket. Generating it is free; you pay only the few cents of S3 storage. If you're going to do this seriously, set up CUR (now delivered via AWS Data Exports) on day one. E

If you are an active user of AI-powered IDEs like Cursor, VS Code with Copilot, or Windsurf, you already know the sinking feeling of seeing this notification: "You have used 100% of your fast premium requests for this billing cycle." Suddenly, your snappy, context-aware coding assistant slows to a crawl or starts racking up expensive pay-as-you-go API bills. At the same time, you are likely paying $20/month for a ChatGPT Plus or Team subscription that sits underutilized in a browser tab. You use it for general questions, but it lacks direct, real-time access to your local codebase, forcing you to engage in a tedious dance of copying and pasting code blocks. What if you could bridge this gap? What if you could let ChatGPT Web do the heavy reasoning and planning using your local context, while saving your premium IDE tokens for fast auto-completions ? In this article, we’ll explore a highly novel, intermediate-level setup that does exactly this. By leveraging the Model Context Protocol (MCP) , Node.js , and secure Cloudflare Tunnels , you can route heavy code-planning tasks directly to your web-based ChatGPT Plus subscription safely and completely free of extra token charges. The Philosophy: Let ChatGPT Think, Let Your IDE Work When building complex software with AI, your workflow generally splits into two distinct phases: Reasoning & Planning (High Token Usage): This is where you ask the AI to read 10 source files, understand the architecture, design a new feature, or find a subtle bug. This consumes massive amounts of context window tokens. Execution & Autocomplete (Low Latency): This is where the AI writes single lines of code, refactors a function, or autocompletes your imports. This requires fast, inline API queries. Paying premium API rates (per token) for Phase 1 is incredibly expensive. This is where this open-source MCP bridge project shines. It exposes a read-only view of your local project as an MCP server. Your web-based ChatGPT (via custom GPTs or MCP int

Microsoft expanded Foundry's model router from two regions to 28 for global standard and 21 for data zone deployments, while adding Claude Opus 4.8 and GPT-5.6 and removing four deprecated models. Default deployments receive pool changes automatically; configured subsets exclude new models until added. The effective context window equals the smallest model in the pool. By Steef-Jan Wiggers

₹85,000 per month. That was the AI API bill sitting in my client's inbox when they called me in a mild panic last quarter. They run a mid-sized e-commerce operation in Pune — about 4,000 orders a day — and had integrated AI into customer support, product descriptions, and internal reporting. The AI was working beautifully. The invoice was not. Three weeks later, their monthly bill was ₹12,400. Same tasks. Same quality. No corners cut. Here's exactly what changed. The real problem: every task was using the most expensive model When I audited their setup, the issue was obvious within five minutes. Every single API call — whether it was classifying a customer complaint into one of 8 categories or generating a 2,000-word product description — was hitting the same premium model. It's the most common mistake I see with businesses adopting AI: they pick one model during the proof-of-concept phase and never revisit that decision as they scale. You wouldn't hire a senior chartered accountant to do data entry. But that's essentially what was happening — a top-tier reasoning model answering "Is this complaint about shipping or billing?" Fix 1: Model routing — the single biggest cost lever Model routing means sending each task to the cheapest model that can handle it at acceptable quality. I categorised their ~47 distinct API call types into three tiers. 68% of calls moved to the lightweight tier, 20% to mid-tier, only 12% stayed on premium. That single change dropped the bill from ₹85K to roughly ₹38K — no quality loss, verified with two weeks of A/B testing on customer satisfaction scores before switching fully. Fix 2: Prompt caching — stop paying for the same context twice Their support bot sent the same 1,200-token system prompt with every call — policies, tone, catalogue context, all identical across thousands of daily calls. Caching processes it once and references it cheaply on subsequent calls within the window. At ~6,000 support interactions a day, this alone saved ₹8,

Cloudflare announced Wallets, giving agents a stablecoin balance and spending controls, though only handle claiming is live and squatting complaints have already surfaced. Payments run on x402, now hosted by the Linux Foundation. The controls bound single payments, not sequences, leaving composition to the application above. By Steef-Jan Wiggers

Every AI video pipeline eventually has to answer an unglamorous question: what did we actually pay for that clip? On the main video-generation service, the answer for months had been "a hardcoded constant." That's fine until the vendor changes its own pricing, or a code path pays for the same synthesis twice, or a voice engine mints a clone, bills for it, and never sends it downstream. Over a ten-PR run I audited and rebuilt the voice and lip-sync pipeline from the billing layer up, then used the vendor's own SKU tiers to cut cost 7x without touching output quality. A cost model built from hardcoded constants isn't a cost model. It's a guess that happens to compile. Billing what the vendor actually charges PR #224 was workstream one of three from a sibling-tool audit: port the cost-accounting fixes that Presenter Generation and Variant Multiplier had already found, verifying each one against this repo's own code rather than assuming the same defect existed in the same place. Anthropic returns exact token counts on every response. Nothing in the pipeline read them — every charge was a hardcoded per-call constant, so the ledger and the vendor invoice diverged the moment usage drifted from whatever number had been typed in at launch. The same PR closed a second gap: two editor-facing routes could spend money — kicking off a generation, retrying a step — outside any run . A run is the unit everything else (budgets, audit trail, the cost ledger) is keyed to. A spend with no run attached is a spend the ledger can't even see, which is worse than a wrong number. Paying twice for a take the model returns unchanged PR #225 found the sibling bug's twin: some vendor calls return the exact same asset on a retry — no new synthesis happened — and the pipeline billed a second time anyway because "call succeeded" and "call did new work" were treated as the same fact. The fix is the boring, correct kind: hash the output, and only charge when the hash changes from the take you already

How We Cut AWS Staging Costs by 87% With EventBridge Scheduler No code changes. No Lambda functions. No complex scripts. Just 4 schedulers and a realization that nobody uses staging at 3am. Here's a question every engineering team should ask themselves: "When was the last time someone actually used our staging environment at 2am?" For us? Never. Not once. Yet we were paying for it — EC2 running, ECS Fargate tasks spinning, compute burning money — every single hour of every single day, including weekends, holidays, and the 21 hours per day when nobody on our team was even awake. That's the hidden tax of staging environments. And most teams never fix it because the solution feels complicated. It isn't. This is how we cut our staging compute costs by 87.5% — using AWS EventBridge Scheduler, zero Lambda functions, and zero lines of application code. The Problem: Staging Was Running 24/7 For No Reason Our staging environment had two resources running around the clock: EC2 instance — our staging app server ECS Fargate service — our backend API container Our team actively uses staging for roughly 3 hours a day . That's it. The math was embarrassing: Running: 24 hours/day Used: 3 hours/day Wasted: 21 hours/day = 87.5% of compute going nowhere Monthly cost breakdown: EC2 + ECS Fargate (24x7): ~$19.18/month EC2 + ECS Fargate (3hr/day): ~$2.40/month Monthly saving: $16.78 Yearly saving: $201.35 Reduction: 87.5% $201/year saved on staging compute alone — with 45 minutes of setup and zero application code changes. Multiply that across dev environments, QA clusters, review apps, and load test environments. The savings compound fast. The Solution: AWS EventBridge Scheduler Most engineers reach for Lambda when they need to automate AWS tasks on a schedule. That works — but it means writing code, managing runtimes, setting up CloudWatch Logs, and maintaining a function forever. EventBridge Scheduler is the better tool here. It lets you call any AWS SDK action directly on a cron sche

OVHcloud will raise prices from September, with 2026-edition gaming servers up 87 percent and other recent servers 40 to 59 percent. Founder Octave Klaba says memory cost six times more in June than a year earlier, as RAM suppliers shifted capacity toward high-bandwidth memory for AI. AWS, buying years ahead, has repriced one reserved GPU product. By Steef-Jan Wiggers

Bruna Pereira explains how DoorDash built a content-agnostic AI moderation platform. She covers replacing costly LLM-only pipelines with a hybrid pattern: using fast internal models to filter obvious cases, LLM multi-axis scoring for nuanced decisions, and no-code workflows with backtesting. Discover how this architectural pattern cut safety incidents while scaling to millions of daily messages. By Bruna Pereira

The Nvidia Cloverleaf data center partnership announced on Friday tells you where the real constraint in AI has moved, and it is not the chip. TechCrunch reported that Nvidia has taken a minority stake in Cloverleaf , a company founded in 2024 that raised $300 million that year and sits between utility companies and data centers, arranging power and site infrastructure. Nvidia did not buy a chip designer. It bought a piece of the electricity supply chain. That reframing is worth thinking about if you build software from anywhere outside a well-supplied grid. 🔌 The bottleneck moved from silicon to substations Read the deal literally. Cloverleaf's product is not compute. It is power sourcing and site infrastructure — the interconnect agreements, the substations, the land next to a utility that can actually deliver load. Nvidia buying into that layer is an admission that shipping more GPUs does not help if nobody can plug them in. This was not a one-off either. The same week, per the reporting: Deal Announced Reported size What Nvidia bought into SB Energy (OpenAI-linked, Ohio) 17 Aug 2026 $1.5 billion Data center project with an energy parent Cloverleaf 21 Aug 2026 Several hundred million (WSJ), minority stake (Reuters) Utility-to-data-center power intermediary Terms were not disclosed by either company, so treat the dollar figures as press reporting rather than filings. Key takeaway: When the company that sells the shovels starts buying the mines, the scarce input is no longer shovels. For AI in 2026, the scarce input is grid capacity. 💰 The circular money problem you should price in Here is the part I would not skip over. Nvidia sells GPUs to data centers. Nvidia is now also investing in the companies that build and power those data centers . Some of that capital flows back as GPU orders. That is not illegal or even unusual in capital-intensive industries. Telecom vendors financed carriers for decades. But it has a specific consequence for you as a buyer of compute:

Short answer: the best way to reduce LLM cost for a product catalog is to measure cost per accepted record, then route each job by difficulty. Count prompt tokens before the call, use a small model for the easy summarize/classify/extract-JSON cases, reserve a stronger model for exceptions, and batch work that can wait. The winning option is the one that preserves the required fields at the lowest cost per accepted result, not the one with the lowest token rate. I build RAG and agent features in Python, so I want this decision to survive contact with production. A catalog description such as “blue jacket, recycled nylon, sizes S–XL” looks easy until one tenant sends HTML, another sends translated attributes, and a third puts three products in one paragraph. The useful unit is therefore a tenant-scoped record with an outcome, a token count, a retry count, and a review decision. Start with the record, not the model For this workflow, the data path is short: normalize a description, count the tokens in the planned prompt, choose a route, request a typed result, validate it, and write the result and its cost to an append-only ledger. A rejected result must remain visible. Otherwise, a cheap model can appear successful simply because invalid JSON and missing attributes disappeared from the report. The ledger needs enough identity to answer a boring but important question: which tenant paid for this retry? I use a job ID, tenant ID, source revision, model route, input token count, output token count, latency, validation status, and review status. Keep the raw description out of ordinary cost dashboards when it contains customer data; the ledger can hold a reference to the source revision instead. Prompt-token counting is a gate, not a decorative metric. If an HTML description expands the prompt beyond its budget, the worker can strip markup, split the record, send it to review, or select a different route. Those choices have different quality consequences, so record the re

El 7 de abril de 2026 escribí el primer commit de lo que iba a ser mi orquestador de agentes. Era, básicamente, una pantalla. Un servidor que gestionaba varios proyectos a la vez y desde el cual podía disparar tareas de un agente de código, con un tablero al medio que mostraba en qué etapa estaba cada cosa. Si me hubieran preguntado ese día cuál era el problema que estaba resolviendo, habría contestado sin dudar: ver y lanzar . Necesitaba un lugar desde donde disparar el trabajo y mirar cómo avanzaba. Cuatro meses después, con más de dos mil tareas cerradas por ese sistema, puedo decir que esa respuesta estaba equivocada, y que el primer indicio de por qué llegó a los tres días. Los dos primeros días fueron todos de interfaz Si miro el historial de esa primera semana, es casi cómico. El ancho del panel lateral. Los tooltips con las fechas completas al pasar el mouse. Los badges de "en progreso" sobre cada etapa. Los colores por etapa del pipeline, para que se distinguieran de un vistazo. Hay un par de commits consecutivos que me gusta especialmente como retrato de ese momento. El primero pone un emoji como ícono del botón de repetición. El segundo lo reemplaza por un carácter Unicode, porque el emoji ignoraba el color que le definía por CSS y se veía siempre igual, sin importar el estado. No lo cuento para burlarme de mí mismo. Lo cuento porque es exactamente cómo se ve un proyecto cuando todavía no sabés cuál es el problema. Estaba puliendo la superficie del sistema con mucho cuidado porque la superficie era lo único que tenía enfrente. La pregunta de fondo —qué parte de este flujo tiene que decidir un modelo y qué parte no— ni siquiera me la había hecho. El 10 de abril cambió el foco Para entonces el pipeline ya tenía forma: una cadena de pasos donde un agente elegía la próxima tarea pendiente, la implementaba y después la marcaba como terminada. Los tres pasos los hacía el modelo, porque los tres estaban escritos como instrucciones dentro de las habilidades que l

JetBrains has described how it began centralising AI usage after development-related spending increased roughly tenfold in six months. Rather than restricting engineers to a small set of approved tools, the company built a shared access and accounting layer intended to preserve tool choice while giving teams greater visibility and control over consumption. By Matt Foster

We've all done it. You spin up an RDS instance to test something on a Friday afternoon. You attach an EBS volume to a t3.micro that you kill three days later — but the volume just... stays. You allocate a static IP for a load test, and the load test ends, but the IP doesn't know that. None of this shows up as an error. Nothing crashes. There's no red banner in the console screaming at you. It just quietly sits there, accruing charges, until you open your AWS bill a month later and go "wait, why are we paying for that ?" I call these zombie resources — infrastructure that's technically alive (and billing you) but functionally dead. It's happened to me enough times on side projects and client work that I've started designing a small tool to stop it: CloudZombie . Heads up: this is early. There's no working product yet — I'm validating the idea and building in the open, starting with a waitlist. If that's not your thing, no hard feelings, but if you've felt this exact pain before, I'd love your take. The problem, more specifically Cloud waste isn't usually one big dramatic mistake. It's death by a thousand cuts: Orphaned EBS volumes — you terminate an EC2 instance, but the attached volume doesn't get deleted with it, so it just sits in an "available" state forever. Idle databases — that staging or QA RDS instance nobody remembers spinning up, quietly running at under 1.5% CPU for weeks. Abandoned static IPs and load balancers — cloud providers actually charge more for an Elastic IP that isn't attached to anything, which feels like a small act of cruelty. Individually, each one is a few dollars a month. Collectively, across a handful of side projects or a growing team's sprawl of staging environments, it adds up to real money leaking out of your runway — with zero warning. What CloudZombie is meant to do The plan is for CloudZombie to connect (read-only) to your AWS account and scan specifically for these patterns: Unattached EBS volumes sitting idle Databases with sust

A payroll and HR software team rebuilt three monoliths into over 120 smaller services over five years, with no dedicated migration budget. Every new feature was built as its own service instead of changing the old ones. The article covers the pull-based migration, the tools that made this possible, how costs were kept down, and the problems the team ran into along the way. By Prashanth Pasham

Uber's "Zero Growth Stack" focuses on scalable infrastructure that separates capacity growth from business demand, reducing hardware needs while enhancing service scaling. Central to this is garbage collection optimisation. Additionally, generative AI is integrated into development, elevating developer productivity while introducing cost management measures to maintain economic efficiency. By Olimpiu Pop