HR, IT, and Finance data all on one platform, so AI can answer questions, automate work, and help teams get more done. Rippling empowers your business to save time, reduce costs, and enhance efficiency, so you can focus on growth.
This is the 5th launch from Rippling. View more
AI Spend Console by Rippling
Launched this week
AI Spend Console gives Finance and Engineering leaders one place to track AI spend across tools (such as Claude and Cursor) and connect it to business outcomes. Break costs down by vendor, model, or employee, then connect spend to GitHub output data like pull request volume and the # of code revisions. You can get started for free–no Rippling subscription required.
Free Options
Launch Team
I've been tracking AI tool costs manually in spreadsheets for months. Connecting spend to actual PR output is exactly the missing piece I needed.
Rippling
@ayla_reynolds Glad to hear it! Would love for you to try out AI Spend Console and let us know what you think. Once you connect your data, I would recommend trying out a prompt like this: Build a dashboard that catches low-quality AI output before it ships. Combine GitHub data with AI usage to surface the pull requests, developers, teams, and repos where AI-assisted code shows high rework, reverts, review churn, and reopened bugs, so I can spot AI slop early.
Rippling
@ayla_reynolds That's great! Would love to hear how it goes once you get it connected.
Its interesting bcz managing HR, payroll and IT in separate systems can get messy quickly. What was the biggest challenge you wanted to solve when building this platform?
Congrats @kevinmason and team!
Rippling
@kevinmason @hamza_afzal_butt The biggest challenge was ensuring users have a magical onboarding experience and can get value from the tool. For example, we spent a lot of time testing and tuning our recommended prompts so the platform surfaces interesting AI spend and usage patterns. For example, you can see which engineers spend the most on AI but have the highest number of code revisions.
Rippling
@hamza_afzal_butt "Managing HR, payroll, and IT in separate systems can get messy quickly" is basically the Rippling mantra 🙂 The goal is always giving people tools to spend less time on manual reconciliation and more time on hard problems. AI Spend Console extends that same idea, giving you one view of your costs and a clearer path to making that spend more efficient.
Wow! This is super exciting! Is Rippling already using this internally? Has it influenced any vendor spend decisions?
Rippling
@quinn_knoblock1 Yes, Rippling is! It has already. We've already cut back our spend significantly and plan to keep using the tool to help us track spend and usage patterns.
Rippling
@quinn_knoblock1 Rippling loves to use our own products. We have some exciting products that will be released later this year that are based on tools that we had to build ourselves to solve problems like this.
First version is how we're using our Data Cloud products to answer AI spend! So we built this AI Spend Console to tie the products up together in a simple use case.
@rachel_cantor3 What made you focus on AI spend visibility instead of just usage tracking?
Rippling
@landon_matthew AI Spend Console really focuses on both! You can see metrics like daily active users but also AI spend across vendors, teams, roles. Spend and usage are both critical, so we show you both.
This is one of my favorite Rippling AI prompts I'd recommend trying: Build a dashboard that shows AI usage and spend over the last 90 days by team, manager, provider, and model. Include total spend, active users, adoption rate, requests/tokens, and spend per employee.
Rippling
@rachel_cantor3 @landon_matthew
We were finding that usage tracking tells you what happened. It doesn't tell you what you can do about it.
We kept seeing the same thing: a team gets told to cut AI costs, so they open a usage dashboard, and... then they're stuck Knowing how many tokens or calls you used doesn't tell you if that spend actually makes sense. What people kept telling us is they wanted to see costs by model and by use case, so they could actually tell if they were using a more expensive model than they needed. That's really it: seeing the number isn't useful on its own. You need to know what to do about it.
How did you decide which GitHub metrics actually show AI value?
Rippling
@nathaniel_george We worked very closely with Rippling Engineering leaders to understand what would actually be valuable. They wanted to see core metrics like PR volume or cost per PR and then interestingly, metrics like AI-assisted code that shows high rework/high revisions.
@kevinmason What was the hardest part of connecting spend with outcomes?
Rippling
@kevinmason @gideon_henry There were definitely a few challenges. Here are 2 that come to mind on my end:
Tracking progress and coordinating lots of different kinds of asynchronous events
APIs can be slow to connect and also stream data from so we had to fix that
@kevinmason @rachel_cantor3 Makes sense!
Which dashboard insight surprised your own team the most?
Rippling
@alice_hayes2 For me, it was interesting to see which teams and roles are using which models. For example, some teams and roles were using expensive models and they really don't need to for their use cases. This has helped us better control spend. I'll let the other makers chime in too!
Rippling
@alice_hayes2 Building on that, another common surprise is just how concentrated spend tends to be, often within a specific team, or even with a handful of team members. Once you can see that, it's a lot easier to build a targeted efficiency plan instead of guessing at the org level.
@lkroll Nice one!
@rachel_cantor3 Glad to know that.
Rippling
@alice_hayes2
Two things stood out to me: On my own usage, I could see that I don't open up new chats very often, I just keep working in the same conversation. The dashboard showed me that a few of those conversations were burning through context just because I didn't restart them.
On the team side, it flagged a couple of people weren't using the models at all. The dashboard actually highlighted that this wasn't a problem with cost, but rather an enablement one. Turned out to be an onboarding gap we hadn't caught, and we were able to go fix it directly.