When the Token Meter is Zero

Perplexity, Nvidia, and taking on AI pricing

Perplexity and Nvidia just shipped a new product on August 25th. If you haven’t been paying attention its goal is businesses whose entire generative AI solution has been what the AI bubble is betting on.

The Portable Computer

The product, referred to as the "Portable Computer," seems logical to me.  It uses the same agentic Perplexity Computer experience but runs entirely on hardware you own.  The build consists of a DGX Spark or a Linux box with an RTX GPU packing at least 24GB of VRAM and does not run in Perplexity’s cloud. It uses local models (Qwen 3.8 27B, with Perplexity’s own PPLX 27B, Nvidia’s Nemotron coming later) to handle the work. When a task genuinely needs more horsepower, the system asks permission before escalating to a frontier cloud model and shows you exactly what data would leave the device before it does, which is a question I hear from those I consult for as an AI Advisor constantly. You’re probably already seeing the biggest benefit of this solution though: zero token cost for anything that stays local. Nate, Perplexity’s VP of Engineering for Infrastructure, could have done a better job selling it when he said it would bring “the exact same UI to a fully local app.” What they built is a demonstration that the metered-token model isn’t the only way to sell AI capability, but it’s just the way that’s been built to make revenue in a service model today.

The AI Budget Line

The timing couldn’t be better, as customers are starting to really focus on AI costs. Perplexity and Nvidia have created a zero-marginal-cost agent, while a good chunk of the SaaS industry is moving the opposite direction away from flat subscriptions and toward consumption-based, per-token pricing.  They were told the subscription era was a loss leader and the bills are now arriving on AI’s initial spending.  Zendesk’s own framing of this shift, which “software value should align directly with customer success, not headcount” is the corporate-speak we’ve been hearing trickle down for a while now.  AI vendors have trained organizations to say to their users, “we’re going to start charging you for how much you actually use this, and it’s going to be less predictable than what you’re used to.” For any enterprise running agentic workflows, where a single task can chain ten to thirty model calls without a human blinking, becoming unsustainable and a budget line many are happy that they can’t forecast.

So, we now have a shift, with one path leading towards AI costs that scale with usage in ways increasingly out of your control, while the other leads toward AI costs that get converted into a fixed, depreciating hardware purchase. That’s not a subtle difference in pricing philosophy for many of these organizations and I think it’s going to turn a few heads. It’s the difference between opex that compounds against you and capex you can plan around, and it’s exactly the kind of thing that gets a CFO’s attention.

AI Data Vulnerability

The privacy angle deserves equal billing and not a footnote, so I want to touch on that, too. For healthcare, and fintech, retail, etc., the pitch isn’t just going to be saved on AI costs but also protect your data more. That’s a different value proposition that most AI vendors have been able to offer, a high priority on most of their lists, and it’s not one that’s easily countered by a cloud vendor saying they have better encryption. The safest data is that which never leaves the premises, so it was never exposed to a leak in the first place.

Expect more vendors to test this playbook over the next year, pairing a capable-enough local model with owned hardware as a sell certainty instead of a meter, and let the cloud handle only the workloads that genuinely justify its cost… and you know how I feel about justifying AI solutions. That’s a healthier industry than one where every vendor’s incentive is to make agentic workflows chew through as many tokens as possible. It’s not a full alternative to cloud AI yet, and it won’t be for a while, but it’s the first shot fired that landed and I feel good about it.

~Peace Out

dbakevlar

John Mount puts together an idea: As of now (late ...

The following article originally appeared on PulseMCP’s blog and is being republished here with the authors’ permission. Most MCP demos feature a single server connecting to a single client....

Bala Priya C avoids the loops: This is one of those places in which people with database development backgrounds can end up understanding the topic…

AI is everywhere, and the pressure to adopt it is relentless. But what does responsible, practical AI adoption actually look like for database and software professionals – the people who live closest to the data?

LIVESTREAM DATE/TIME ??September 4th, 2026 - 9:30 ...

The following article originally appeared on the A...

Anyone who’s spent years writing T-SQL has a mental list of “why doesn’t SQL Server just do this already?” moments. Here are 9 of those from Louis Davidson’s perspective – a wish list of practical, coding-oriented feature requests drawn from real-world pain points.

A T-SQL veteran's wish list: 9 missing SQL Server ...

Do you have a case where you have a named instance...

Cloud database vendor lock-in is one of the most expensive surprises in enterprise infrastructure — not because the dependency is hidden, but because most teams never quantify it before committing to a platform. Each distinct type – engine lock-in, feature lock-in, and operational lock-in – accumulates differently, costs a different amount to exit, and requires a different conversation before you migrate. This article breaks down exactly what each type means, which cloud providers create the deepest dependencies, and introduces a four-question framework for measuring your own lock-in — before a pricing change, service deprecation or organizational shift forces the issue.

I wanted to map where fresh food is hard to reach,...

Presently sponsored by: Report URI: Guarding you f...

I wanted a folder of weather station files as one data frame, and I assumed that part of the job would take one line.…

MSSQLTips ran a good piece this month on when a co...

Video by: Reid HavensDAX has shipped more new surf...

This article describes how to use AI to identify r...

How to use AI to identify relevant test cases in a...

There’s so much going on in the Fabric community...

James Serra hits the ceiling: Microsoft Fabric mak...

Meagan Longoria has a list: Fabric deployment pipe...

Matt Collins shares some advice: Selective deploym...

I’ve had Fabric gnawing at me for too long. Whil...

When we decided to use T-SQL and a Fabric Data War...

Gilbert Quevauvilliers saves some money: Click through for a Python notebook that does this.

Louis Davidson bangs his head against a wall: When we decided to use T-SQL and a Fabric Data Warehouse for our ETL, I started thinking…

John Deardurff has some advice: I’ve been review...

Aaron Bertrand shares examples: This is not anothe...

SQL Server Performance Office Hours Episode 74 To ...

Using historical data to confirm performance impro...

The PostGIS Team is pleased to release PostGIS 3.7...

And now, we put on our waders and venture into the...

Scenario-Tree Testing in PostgreSQL: Every Authore...

It’s hard to say anything new about query optimi...

Chronic bloating, gas, abdominal discomfort, const...

You wanna learn PostgreSQL, and you wanna use a sa...

We're excited to unveil pgwatch v6.0.0-beta — th...

Chris Webb takes a look: There’s so much going o...

AI can perform a lot of interesting tasks these da...

Dualcore DBA learns something new: Today’s post ...

Dealing With DDL and CDC Chapters 00:00:00 – Int...

Jeff Taylor gives us the low-down: A couple of weeks ago, I asked a simple question with a loaded answer: are temp tables a friend…

Steve Jones tries out a function: I was trolling the docs and noticed the SIGN() function. I have never written this in production code, but it is…

Tom Zika waits to pass GO: I deployed a schema cha...