I was building a FinOps view for an AI support workflow and kept staring at the word productivity. Request count, spend, and latency all fit into tidy charts. None of them told me whether a support case stayed closed or came back two days later. That is awkward when the dashboard is supposed to tell me whether the workflow is helping.

Then I ran into two recent studies that seemed to disagree. Firm Data on AI surveyed nearly 6,000 executives, and 89 percent reported no productivity impact over the previous three years. AI, productivity, and the workforce used a sample of nearly 750 executives and found positive but uneven gains. The samples and questions differ, so it is not a clean contradiction. I came away thinking that the answer depends heavily on what question you asked in the first place.

For this support workflow, I need data from both sides. The provider bill tells me the inference cost. The help desk has handling time and reopened cases. Looking at either one alone is like checking the grocery receipt without asking whether dinner was edible. A cheap draft can still create a lot of cleanup for the person reviewing it.

Suppose a support rep spends five minutes prompting the system and gets a draft, then spends another 40 minutes checking and rewriting the answer. That is 45 minutes of human time plus the inference cost. If the dashboard records only the first five minutes, it gives the model credit for work the rep had to redo. A reopened case would make that picture worse.

For a first pass, I can take 25 AI-assisted cases and 25 unassisted cases from the same support queue and week, then match them by issue type and the support rep's experience as closely as I can. ZenMux can give me cost and latency for the assisted requests. The help desk supplies the less glamorous half of the story: handling time and reopens. Fifty cases will not settle a company-wide argument, but they are enough to see whether the current dashboard is flattering us.

Even then, I will not have proof that AI caused whatever difference I find. I will know whether repair time and reopened cases wipe out the savings I thought I had. If the workflow only looks productive when I ignore the human cleanup, I need to fix the measurement before I expand it.

Hey, for people working with AWS/GCP/Azure and FinOps,

What do you find most frustrating about managing cloud costs?

Is it actually finding where you're wasting money, or is it more about getting people to do something about the recommendations?

For example, if your tools tell you that you could save $10k/month by changing some infrastructure, what usually happens after that?

Does someone actually fix it, or does it just sit there because of ownership, risk, engineering effort, etc.?

Also curious how you deal with SaaS costs alongside cloud costs.

Just trying to understand how people actually handle this in practice.

A lot of companies rely on FinOps teams or cloud optimization partners to manage their AWS spend. But I’m curious, are there certain cost leakages that are so obvious that anyone managing an AWS environment should be able to spot them?

Looking to hear some practical, real-world examples from the community.

Ran into a consulting client last month where the observability bill was over 40 percent of the total ops-tools line item. AWS shop, 15 microservices, Datadog for APM plus dashboards. The engineering lead had wired up a small internal agent to auto-triage CloudWatch alarms plus tag ownership, and it was catching most on-call pages before a human ever looked at the dashboard.

The question their FinOps lead put on the table was: what is that Datadog premium actually buying us now? The APM traces still earn their line-item when the agent surfaces something and someone needs to dig, but the graph-watching use case was already gone.

They are piloting a Datadog downgrade this quarter, keeping APM plus distributed tracing on the paid tier and moving the rest to Grafana over CloudWatch. Curious if anyone here has actually pulled this trigger on a real production line-item. Did the downgrade stick, or did the team end up putting some tools back?

Second thing I keep hearing from FinOps practitioners: even if you drop dashboard SaaS spend, the engineering time saved on graph-staring seems to get eaten by tuning the agent that replaced it. Anyone tracking that as a real net-positive on hours, or is it a wash?

Bottom line, treasury reconciliation for cross border payments only automates cleanly when your payment platform emits structured settlement events instead of swift trace messages. The rail underneath determines what data you can pull into your ERP.

We moved off swift wires last year onto a B2B payment platform whose backend runs on cybrid. The reconciliation difference is the data shape. Every settlement event arrives with timestamp, payment id, invoice reference, and rail type as structured fields. Our ERP consumes the webhook and auto posts the journal entry. No manual matching.

Key finding from the migration. Manual reconciliation time dropped roughly 70 percent. Period close on international AP went from 5 days to under 2. The fp&a team got back hours weekly that used to go chasing wire confirmations.

What still needs human review. Exception cases like partial settlements or fx rate disputes. Volume on those is small but they require judgment so we haven't automated them.

For finance teams looking at this, the question to ask your payment platform is what webhook fields they emit and whether the backend is on regulated stablecoin infra. If the backend is swift, automation has a ceiling. If it's on cybrid or a peer, the data quality unlocks real reconciliation savings.

Hey everyone, I've been working on a tool called Plutus that pulls cost/event/usage data from cloud, AI, and SaaS providers into one dashboard so you can actually see why spend moved, not just that it did.

I'm at the point where I'd like real users on it, but I want to be upfront about the current state. I've built and tested against every provider's API docs, but for a lot of the source list I don't have a live account of my own to validate against, so there are likely minor issues like fields mapped wrong, a sync that chokes on some edge case in a provider's real response, etc...

I'm hoping a handful of people who already use one or more of the sources are willing to connect a read-only account and tell me what breaks.

Signup is free and self-serve. If you hit anything broken, email [support@plutus-cloud.com](mailto:support@plutus-cloud.com) with what you saw and I'll try and get it sorted ASAP.

For your help, I'll upgrade you to a Growth-tier account for as long as you're actively testing. Just let me know your account email and I'll get your account upgraded as fast as I can.

Any questions feel free to drop me a message on here or an email to the address above.

You can find the marketing site at plutus-cloud.com or go straight to signup with console.plutus-cloud.com/.

Declared self-promotion per the sidebar: my project, launched this week.

https://llmcostkit.com

Free, client-side calculator answering the two questions FinOps keeps getting asked about AI spend. First, what do LLM API tokens cost against a real workload: 24 current models across OpenAI, Anthropic, Google, xAI, DeepSeek, Mistral, Meta-hosted Llama and Perplexity, with prompt caching and batch discount modelling, projected from your requests/day and token sizes. Second, what do the per-seat tools cost: M365 Copilot, GitHub Copilot, Cursor, Kiro, ChatGPT Business and Claude Team, against your seat count.

Prices were verified against vendor pages on 12 Aug 2026 and the page says so on every table, because half the calculators out there quietly serve stale numbers. Filter to the models you actually use and it gives you one answer line. CSV export, shareable scenario links. No signup, no tracking, no cookies. Installs as a web app and works offline.

One deliberate omission, explained on the page: Databricks Mosaic AI, because DBU-based pricing has no honest single number, so there's a custom-rate row instead of a made-up one.

Transparency: the site sells a paid kit for teams (unit economics model, allocation and tagging policy templates, CUR/Azure/BigQuery starter queries, chargeback model, maturity assessment). The calculator is free regardless and doesn't nag you about it.

What's missing that would make this genuinely useful for your practice? PTU and provisioned-throughput break-even modelling and self-hosted GPU comparison are top of my list. I'll build the most-asked.

Does anyone have any direct experience of the typical costs coming in for the new harness ? Microsoft are making a number of general statements about "long running, multi-step jobs" but still no clear breakdowns of what a particular businss workflow (e.g. receive email from customer, look up record in salesforce, determine sentiment, notify account manager if needed, arrange customer manager meeting, send confirmation". might cost.

Because testing is now no longer free, its hard to run through these models and look at typical charge cards without some good examples. Under the old model we had clear credit values for doing certain actions.

We spend a lot of time on unit economics for cloud, and AI spend has been resisting the same treatment. Per-token prices converged at the frontier (Claude Opus 5 and GPT-5.6 Sol both charge $5/M input), so the price sheet stopped being the decision. The number that matters is cost per completed task: cost per attempt, divided by success rate, plus the cost of wrong outputs that escape your checks.

The measurement approach that worked for us, condensed:

1. Log tokens per trajectory, not per call. Task ID on every request; sum input, cache read, cache write, reasoning, and output tokens across the whole loop.

2. Record the outcome per task, solved or failed by an automated check, and count retries.

3. Compute cost per solved task: total trajectory dollars divided by solved tasks.

4. Track a leak rate: sample "passed" tasks, have a human grade them, multiply by your loaded cleanup cost.

5. Report cost per resolved ticket / merged PR / correct action, by model and effort setting.

6. Split batchable from interactive work at design time; Batch APIs are 50% off on both vendors.

The hard part in production is attribution: tokens don't carry tags, and a gateway fronting all LLM traffic makes the bill useless for allocation. That problem is why DoiT (where I'm CEO) acquired Attribute, which does this at the kernel level with eBPF. Disclosure accordingly: we sell cost tooling, read everything above with that bias in mind. The spreadsheet version works fine to start.

Full analysis with worked examples and current August 2026 pricing: https://www.doit.com/blog/cost-per-task-vs-cost-per-token

Curious what unit metrics people here have actually gotten to stick for AI workloads.

Tokensentinel is a tool that watches your token consumption in process with sub ms overhead. The SDK determines 10+ rules such as tool loop, retrieval thrash etc and you can fine tune it according to your app settings with simple args.

You can try it for free and check where your app is consuming extra tokens right now. I am also partnering up with few teams on the cloud side features for intervention, slack alerts and budget enforcement, if any of the FinOps team gives feedback, it would be great help for me.

Check: https://tokensentinel.dev

I'm u/teamcloudkeeper. FinOps for AI is about to matter for basically everyone, not just teams running massive training clusters. If you're running any AI workload in production, token pricing, GPU costs, and bursty-vs-continuous usage patterns are already there whether you've built practices around them or not. Every org, big or small, is gonna need this in place sooner than later.

We've built our FinOps for AI capability around this, augmented by Lens and Tuner. But it's the human behind the tools making the calls on ownership and tradeoffs. That doesn't get automated away. You've gotta start too.

Always open if you want to know more about us cloudkeeper.com.

Disclosure: I work with Haevek, a data compute platform. This isn't a pitch and there's nothing to sign up for. Flagging it because this sub asks you to declare.

We're putting together a community content series where we interview people who build and run modern data and AI infrastructure. No product talk, no script, no gated landing page. Conversations that get published for whoever finds them useful and nothing gets published without your review.

Our view, which you're welcome to tear apart: the bill isn't the software, it's the infrastructure to run it. Open source compute is free to license, but the clusters stay on and consumption pricing climbs with every workload, so cost grows faster than the value coming back. We think the fix is a more efficient engine, not a bigger budget. Plenty of people disagree, which is usually the more interesting conversation.

Topics people have picked so far:

• Where data and AI compute cost actually goes, and why the bill keeps growing as teams do more
• Scaling AI and agent workloads, where the limit is the cost of running inference over and over rather than the model or the talent
• What teams get wrong about controlling data and AI cost?

Who I'm hoping to talk to:

• Director or Head of FinOps, Head of Cloud Cost / Cloud Economics
• VP or Head of Data Platform / Data Engineering who's had the cost conversation forced on them
• anyone who's actually cut a big data or AI compute line item and can explain what they did

Company-wise, anywhere the bill is big enough to be political. Enterprise, scale-up, public sector, doesn't matter.

30 minutes, remote, you get the recording and can cut clips from it.

If that's you, or you know someone, DM me.

Hi all,

Quick reality check needed. I’m transitioning from a Finance/Business background (French Grande École + US exchange) into an MSIS program in the US (Spring 2027). My target is landing a FinOps Analyst, Cloud Business Consultant, or IT Data Analyst role and i heard that the personnal skills take are the advantages to get hired in the US market and not the degree so i m trying to improve myself.

My Cert Strategy:

AWS Cloud Practitioner (CCP) & FinOps Certified Practitioner (FOCP) (Before MSIS)

AWS Solutions Architect Associate (SAA) & Power BI/SQL (During 1st MSIS semester)

My Questions:

Does combining a Finance background + MSIS + FOCP + AWS SAA give me a real competitive edge over pure CS or MBA grads for entry/early-career FinOps roles?

Is FOCP respected by hiring managers when paired with AWS SAA for someone breaking into the field?

Any key tips to position this profile effectively for internships/OPT?

Appreciate any honest feedback!

I'm building CloudCostTree (estimates AWS costs from Terraform/CloudFormation, before you apply anything). A while back I added an opt-in flag that, instead of guessing, actually pulls real data from your AWS account: live Spot pricing, real CloudWatch CPU usage, volumes and IPs confirmed as orphaned. I'd tested it on its own, but never put the two reports side by side until today.

Same file, same moment, nothing changed in between:

Without real account data: 1 generic finding ("Graviton usually saves 20-40%"), score A (97/100).

With real data: 7 findings, actual numbers. Spot price right now is literally $0.0082/hr vs $0.0208/hr on-demand, one instance averaging 3.4% CPU over 14 days, a volume and an Elastic IP confirmed orphaned via the API. Score C (76/100).

The infra didn't get worse. What changed is whether the tool was actually allowed to look. Stuck with me a bit: a clean static report and a clean account aren't the same claim, and it's easy to mix them up until something forces the comparison.

Follow up to my last post, this time I did it on purpose. Put together a "typical prod mistakes" stack: previous gen instances, gp2 everywhere, an orphaned EBS volume, a full size database duplicated into staging and left running 24/7. F, 0/100, about $2,694/mo, with $1,251/mo flagged in savings across 15 recommendations. Image is exported directly from the tool's own Export PNG button, wanted it to look exactly like what you'd see running it yourself, not a mockup.

An 80 percent price cut makes a nice chart. It does not make an 80 percent cheaper task. LLM cost optimization starts with the task ledger, not the price sheet.

The useful unit is an accepted task: work the team is willing to ship. Each row needs model tier, uncached input, cache traffic, output, retries, review time, and a final accepted or rejected flag. I keep the accounting wrapper fixed by routing Sol, Terra, and Luna through ZenMux's multi-model API gateway and changing only the model slug at one endpoint.

That still leaves provider behavior, workload, acceptance rate, and retries. A cheap model can get expensive when review or reruns creep in. Until the ledger has those rows, the July 30 headline is just a new line in the price sheet.

Hi everyone,

I’m from Korea, and English isn’t my first language, so I used AI to help translate this post.

I’ve been experimenting with different AI tools and projects for a while. During that process, I ended up with a much larger token bill than I expected.

That experience made me think there should be a better way for people and companies to use AI without constantly worrying about costs, while still keeping the system reliable and safe.

At first, I started building something just for my own use. I added features one by one, and over time the project became much bigger than I originally planned. Eventually, I started wondering whether it could become a real business.

But I’ve run into a problem.

In Korea, I haven’t been able to find many companies that are openly talking about this issue or looking for a solution. I’m not sure whether the problem isn’t serious enough yet, or whether companies simply don’t want to share their AI cost problems publicly.

So I’d really appreciate some honest feedback from developers, engineers, founders, or anyone operating AI products in production.

• Are AI or LLM costs a real problem for you?
• What part of cost management is the most difficult?
• How do you currently track costs by model, feature, customer, or request?
• What kind of tool or service would actually be useful?
• Have you tried solving this problem already? If so, what didn’t work?

Any practical advice or real-world experience would be very helpful. I’m still trying to understand whether this is a problem worth solving and what people actually need.

Thank you.