The $0.09 question: when a cheaper model is the right call

Most AI budgets are built on one quiet assumption: that you need the best model for everything. You pick a strong general-purpose model, wire it into every workflow, and watch the monthly invoice climb. It works. It is also, for a lot of the work, more than you need.

NVIDIA released a model in March that makes this worth a second look. It's called Nemotron 3 Super, and on the kind of tasks that fill most enterprise pipelines it performs close to Claude Sonnet while costing somewhere between a tenth and a thirtieth as much. That gap is large enough to change how you think about which model goes where.

This is not a "switch everything" argument. Sonnet is the better model overall, and for some work the difference is stark. But "better overall" and "better for this specific task at this specific price" are two different questions — and the second one is the one that shows up on your bill. Most of this article is about telling those two apart, because the companies that save real money are the ones that stop conflating them.

What Nemotron 3 Super actually is

Start with the plain description, because the name is a mouthful. The full version is "Nemotron 3 Super 120B A12B," and once you decode it the model gets easy to reason about.

The "120B / 12B" split is the part worth understanding, because it explains the price. Nemotron uses a mixture-of-experts design. Picture a consulting firm with 500 specialists on staff. When a question comes in, you don't put all 500 in the room — you pull in the handful who actually know the subject. The firm has deep expertise on call, but any single meeting is cheap to run.

That's what mixture-of-experts does. The model holds 120 billion parameters' worth of knowledge, but it only fires up about 12 billion of them for any given request. You pay for a 12-billion-parameter model and get answers shaped by a much larger one. This is the same architectural trick behind other recent open models like DeepSeek and the latest Llama and Qwen releases, so Nemotron sits in good company.

The model class, in plain terms: an open-weight, frontier-adjacent reasoning model. Not the absolute top of the leaderboard, but close enough that the price difference becomes the headline.

Why it's so cheap and so fast

You don't need the engineering to make the decision, but a little of it explains why the price gap is real and not a temporary discount that will evaporate next quarter. Three design choices do most of the work.

For a chatbot or any feature where a person is waiting, that responsiveness is a feature in its own right, separate from the cost. For a batch job grinding through ten thousand documents overnight, it means the job finishes in half the wall-clock time.

There's also the one-million-token context window. In day-to-day terms, you can hand the model a very large document, or a long stretch of conversation history, without chopping it into pieces and stitching the answers back together. Long-context work used to be where cheaper models fell apart. That's less true now, and it removes one of the old reasons to reach for the premium option by default.

The price gap, in numbers your CFO will recognize

Here's the comparison that started all of this. Per million tokens (the unit AI providers bill in, where a million tokens is very roughly 750,000 words):

That's roughly a 33× difference on published API rates. I ran my own head-to-head on a small batch of everyday business tasks, and the gap came out even wider per job — with Nemotron landing close to an order of magnitude cheaper once you count the full request. Your real numbers will sit somewhere in that band depending on how chatty your prompts are.

A quick reality check on that arithmetic, because the headline multiple can mislead. Your actual savings depend on the mix of input and output tokens in your workload. A task that reads a long document and writes a short answer is mostly input tokens, where the ratio is most favorable. A task that writes long outputs from short prompts leans on the output price — also far cheaper, but the larger number to watch. Either way the direction is the same. The size of the win just varies by workload, which is one more reason to measure your own before you forecast.

Where Nemotron is as good as Sonnet, or better

I tested both models on a spread of common tasks and scored the outputs against a fixed rubric. The pattern was consistent, and it matches what the public benchmarks show. On structured, technical, unambiguous work, the two models are hard to tell apart.

A concrete example. I gave both models a messy customer order written in plain English ("3 large blue widgets, a couple of the small red ones, ship to Sydney, budget $200, no gift wrap") and asked for clean JSON with no commentary. Nemotron returned exactly that. Sonnet returned the same correct data but wrapped it in a code block the instructions told it to skip. On that one, the cheaper model followed the brief more precisely.

Another. I dropped in a meeting transcript full of cross-talk, a few decisions, some small talk about a broken coffee machine, and four action items with different owners. Both models pulled out the right decisions and the right owners, correctly attached a deadline to each task, and both correctly ignored the coffee machine. If you handed those two summaries to a manager, there'd be no way to tell which model wrote which.

A third, because reasoning is where people assume cheap models fall down. The old trap question: a widget and a gadget cost $1.10 together, the widget costs a dollar more than the gadget, how much for three widgets and two gadgets? The intuitive wrong answer is everywhere on the internet, so a model that just pattern-matches tends to fall for it. Both models set up the algebra, avoided the trap, and got the same correct total. Nemotron did it while generating tokens at roughly twice the speed.

This is the part that should get attention in a planning meeting. A large share of production AI work is exactly this kind of task: pull fields out of an email, turn a transcript into a to-do list, classify a support ticket, summarize a contract, run a calculation, generate a first-draft function. For all of that, you're paying premium rates for a result a much cheaper model delivers just as well. The premium model isn't doing anything extra here — it's just costing more.

Where Sonnet earns its premium

Now the other side, because this is where pretending otherwise would cost you.

The two models split hard on writing, especially writing with rules attached. I gave both a classic constraint test: write a short paragraph about a beach without ever using the letter "e." Sonnet produced clean, readable prose that held the constraint. Nemotron wrote a nice paragraph and broke the rule in the first sentence. Same story, smaller gap, when the task was to soften a blunt internal note for a customer without inventing new promises. Sonnet stayed disciplined. Nemotron drifted and added commitments nobody authorized.

That second failure is the one worth dwelling on, because it's subtle and it's expensive. The note was an internal message saying, in effect, "their CSV is malformed, we can't look at it until Thursday." The task was to rewrite it politely for the customer without adding anything that wasn't already true. Nemotron's version was perfectly courteous, but it offered to send the customer a sample file and a formatting specification — neither of which anyone had agreed to provide. A polite email that quietly commits your team to unplanned work is worse than a blunt one, because someone now has to either honor the promise or walk it back.

The takeaway is not "Nemotron can't write." It's that Sonnet is noticeably better at holding a constraint while writing, and at the careful, reputation-sensitive judgment calls that go into customer-facing prose. When a wrong word carries legal, brand, or relationship risk, that reliability is worth paying for.

There's a related, quieter gap in strict instruction-following. On a tightly specified formatting task (a numbered list, exactly two sentences each, under thirty words, certain words banned), Sonnet hit every rule. Nemotron got most of them right but was a touch looser. For a lot of internal work, "mostly right" is fine. For an automated pipeline where the next system expects an exact shape, "mostly" is the thing that pages someone at 2am. Know which situation you're in.

The costs nobody puts in the deck

The per-token comparison is the easy part. A few costs sit outside that table, and they decide whether the savings are real.

Running it on your own hardware

Because Nemotron is open-weight, you have an option Sonnet doesn't give you: run it inside your own walls. For regulated industries, that alone can be the deciding factor. Your data never leaves your network, there's no third party in the loop, and there's no per-token meter running.

For a production deployment, plan on a server with eight H100-class GPUs (80GB each), which is NVIDIA's stated baseline for serving this model at full quality and throughput. In practical terms that's a single high-end inference node — the kind your infrastructure team can spec, or rent from a cloud provider by the hour, without much drama.

The capital question is straightforward arithmetic, and it's worth doing rather than guessing. A node like that runs in the low tens of dollars per hour if you rent it, or a sizable one-time purchase if you buy. Against that, set what you'd otherwise pay per token at your real volume. At heavy, steady, around-the-clock usage, owning or reserving the hardware can beat paying per token by a wide margin, because you're paying for capacity instead of consumption. At light or spiky volume, the hosted API almost always wins, because an idle GPU you've already paid for is pure waste. The crossover point is specific to your usage, so run the math against your actual traffic before anyone signs a purchase order.

A note for the technically curious: smaller quantized builds of the model can run on far less hardware, down to a couple of consumer GPUs — but treat those as evaluation setups rather than production. They trade quality and speed for accessibility, which is great for a proof of concept and wrong for a live system.

Security, residency, and the compliance angle

For some organizations the deciding factor isn't the price at all. It's that an open-weight model can run entirely within a controlled environment.

If you operate under data residency rules, handle regulated personal or health information, or work in a sector where sending data to an outside API is simply off the table, a model you host yourself changes what's possible. The data stays in your network and under your existing controls. You can run it in an air-gapped environment if you have to. You decide the logging, the retention, and the access. None of that is a knock on hosted providers, who invest heavily in security. It's that "we never sent the data anywhere" is a categorically simpler thing to explain to an auditor than "we sent it somewhere with strong contractual protections."

The flip side is that you inherit the responsibility. Running the model yourself means you own the patching, the monitoring, and the safety guardrails that a hosted provider would otherwise handle. That's a real operational commitment, not a checkbox. The point isn't that on-prem is safer in the abstract. It's that for specific regulatory situations, owning the whole stack removes a class of problems that no contract fully solves.

How to act on this

You don't need a strategy offsite for this. You need a routing decision, and a way to check your work.

Start by treating "which model" as a per-task choice rather than a company-wide default. Map your current AI usage into two buckets. In the first: high-volume, structured, internal work where mistakes are cheap and recoverable — extraction, summarization, classification, internal tooling, code assistance, first drafts. In the second: customer-facing writing, anything with strict formatting or compliance rules, and the judgment calls where being wrong is expensive. The first bucket is your savings opportunity. The second is where the premium model stays.

Then prove it before you trust it. Pull a few hundred real examples from one task in the first bucket, run both models, and score the results against what "good" actually means for that task. This is the step people skip, and it's the one that turns a plausible idea into a defensible decision. If the cheap model holds up, route that task to it and move to the next one. If it doesn't, you've learned that cheaply, on a sample, instead of expensively, in production.

Most teams that do this end up running both models behind a simple router that picks based on the job. The user never sees which model answered. The finance team sees a smaller bill. And because you measured rather than guessed, you can say exactly why each task is routed the way it is — which matters the next time a new model ships and someone asks whether you should switch again.

One more habit worth building: revisit the decision on a schedule. This field moves fast. Prices drop, new models appear, and a comparison that was true in June may not hold by year end. The routing setup you build now is the thing that lets you re-run the test cheaply whenever that happens, instead of starting the analysis from scratch.