Remix.run Logo
jetrink a day ago

> Tokens become cheaper than tool calls

The author observes that a call to GPT-5.6 Luna is only 4-5 orders of magnitude more expensive than grep, and then predicts that at current rates of progress, calling an LLM will soon be cheaper than a grep. I think this is a good time to invoke Stein's Law: "If something cannot go on forever, it will stop." These efficiency improvements won't continue forever. It's more likely that the per-call cost of high-quality, compiled software like grep will be a lower-bound that LLMs asymptotically approach, rather than a line that they blow past with perpetual exponential progress. (Barring a true breakthrough in something like quantum computing or room-temperature superconductors.)

sanderjd a day ago | parent | next [-]

Yeah I bumped on that too. If it's possible to make llms cheaper than current grep, then it is also almost certainly possible to make grep cheaper.

serbuvlad a day ago | parent | next [-]

You can burn anything* into an ASIC to make it cheaper per-call.

non-backreferencing grep is not very difficult to implement in an ASIC either. But it's probably not worth it because of how relatively rarely you use it and of the data transfer costs.

LLMs are great candidates for ASIC-burning because they're slow compared even to network speeds and run all the time. The issue is that you don't want to burn a specific model or architecture that then becomes obsolete.

So you've got two possible futures, and both guarantee large price drops: (a) LLMs keep getting better and better and better, so ability/$ keeps rising; or (b) LLMs plateau in ability, in which they will start getting ASIC'd.

nvme0n1p1 a day ago | parent | next [-]

Grep (or ripgrep at least) is i/o bottlenecked at this point. It's impossible to process data at faster than i/o speeds, since you have to get the data to the processor somehow. That doesn't change whether that processing is grep on a CPU, or LLM on an ASIC.

serbuvlad a day ago | parent | next [-]

ripgrep may be.

I did a toy project once implementing a limited version of grep on an FPGA and was able to get some speedup over GNU grep at the time, though marginal.

In any case, LLMs aren't IO bound :))

cobbal a day ago | parent | next [-]

I am now imagining a future where developers buy fancy "grep cards" for their machines. I don't hate it.

alexshendi 6 hours ago | parent | next [-]

These are properly called "GPUs", as in "Grep Processing Units"!

bee_rider a day ago | parent | prev | next [-]

It would be cool if they could be daisy-chained, so you can have a hardware implementation of |

mpweiher 10 hours ago | parent | next [-]

The return of the Transputer.

Put a Transputer in a Lego brick. Not "like a Lego brick", an actual Lego brick. Turn the notches into connectors for the serial link.

Plug'n'play.

benterix a day ago | parent | prev [-]

The next logical step would be to have a separate card for each Unix utility.

QuantumNomad_ a day ago | parent | next [-]

And a patch panel and a bunch of patch cables that you plug in and out to construct your pipelines.

And eventually hire people whose job it is to patch pipelines on demand for everyone in the office.

“Hey Jim, I’m gonna output the systemd logs of nginx on line five, can you assemble a grep pipeline for me to match all HTTP 500 status codes from /api/cart POST request log lines? Connect the filtered output to Tim’s desk, line 7. He’s there now, we are trying to figure something out.”

“Sure thing Bob, give me a moment.”

bartread 21 hours ago | parent | next [-]

It’s OK: you can just tell us you have a financially and relationally crippling Eurorack addiction. You’re amongst friends here.

justsid 14 hours ago | parent | prev | next [-]

Now if that isn’t a great Zachlike game mechanic. Playing as the patch pipeline builder.

serbuvlad 17 hours ago | parent | prev | next [-]

I'm sure this is how some bellheads (in the phone tradition, not in the Unix tradition) envisioned computing.

kgwgk a day ago | parent | prev | next [-]

Patching cables is so primitive... Use punched cards to define the connection patterns or something!

xigoi 9 hours ago | parent | prev | next [-]

Somehow we’ve reinvented punch cards, but worse.

mkesper 7 hours ago | parent [-]

It was a companion of punchcards, the tabulating machine. Programming by wires. https://en.wikipedia.org/wiki/Tabulating_machine#Selected_mo...

nxobject 19 hours ago | parent | prev | next [-]

Bring back IBM accounting machine plugboards!

formerly_proven 20 hours ago | parent | prev [-]

Transputerpunk.

Retro_Dev 13 hours ago | parent | prev | next [-]

I cannot wait for my cowsay coprocessor.

Scarblac 5 hours ago | parent | prev [-]

And a datacenter for Emacs.

swiftcoder 7 hours ago | parent | prev | next [-]

I wonder how close you can get with Nvidia's GPUDirect. Hook the fast NVME directly up to the GPU (well, it gets direct DMA to GPU at any rate), then implement parallel grep in CUDA... profit?

nxobject 19 hours ago | parent | prev | next [-]

I look forward to GPGrepPU -- someone'll find a way to abuse them for scientific workloads or something.

NooneAtAll3 15 hours ago | parent [-]

GrePU

sanderjd a day ago | parent | prev | next [-]

Universal Basic ASICs

klipt a day ago | parent [-]

If your BASIC is compiled that's just a CPU!

lou1306 21 hours ago | parent | prev [-]

At some point Intel was experimenting a Xeon with built-in FPGA, maybe they were just a bit too early to the game :)

mhast 18 hours ago | parent [-]

Almost 30 years ago there was a project about making a computer which used FPGAs for all "software". It was called RAW.

Baring it all to software: Raw machines | IEEE Journals & Magazine | IEEE Xplore https://share.google/nI9GyFJu4HvbYFrBf

(If you Google the name you will find free PDFs as well, the IEEE page is more useful as a summary and such.)

dgacmu a day ago | parent | prev | next [-]

I've evaluated some of these and in almost all cases they failed to outperform Intel's ridiculously optimized CPU regex library, hyperscan.

sanderjd a day ago | parent | prev [-]

Right, but I read the comment's point as: being i/o bound is the eventual limit of the asymptote and it's the same one grep has.

readams 21 hours ago | parent | prev | next [-]

GPUs and inference ASICS also have large amounts of high bandwidth memory, plus lots of high speed storage cache, and dedicated very high bandwidth scale-out and scale-up networks. Because they are also often bound by I/O bandwidth.

If your problem is grepping crazy amounts of data, the infrastructure for LLMs isn't a bad place to look for an example.

nxobject 19 hours ago | parent [-]

> plus lots of high speed storage cache

I wouldn't be surprised if that's what Apple is focused on for their next generation platforms – I wonder if more layers of caching between their SSDs and unified memory are on the cards.

sanderjd a day ago | parent | prev [-]

i/o could still be sped up though? And I dunno, maybe this actually is an argument for how the llm version could end up being faster, because there is lots of investment in crazy fast i/o hardware and protocols to get the data into the chips.

feoren a day ago | parent | prev | next [-]

It's almost a certainty that LLMs have a "core" that will essentially never become obsolete, possibly even 80% to 90% of their parameters. The rules of English and other languages, core ideas in math and science, all of history, nearly all literature, etc. We don't really understand what's going on inside LLMs enough yet to make good use of this, but one day we will have "core logic" neural networks with stable weights burned into ASIC that are doing the heavy lifting, with more dynamic continually-tuned models manipulating the inputs and outputs into those core models. There are also likely stable expert models on topics that don't change much that we could already do this with.

Inference costs cannot keep falling forever, but they do still have a long way to go.

vrighter 12 hours ago | parent [-]

it doesn't work that way though

hobofan a day ago | parent | prev | next [-]

> LLMs plateau in ability, in which they will start getting ASIC'd.

They don't need to plateu for that to happen. There are companies already building AI on ASIC, and IIRC they were approach 12 months lead time. A 12 months old frontier model (Sonnet 4.5, GPT-5, Kimi K2) for 1% of the price is still a rather good value proposition.

atq2119 20 hours ago | parent | next [-]

In order for the ASIC to achieve 1% of the price, there'd have to be 99% overhead in GPU implementations which for some reason you'd have to be able to eliminate in ASICs but not in GPUs. That seems rather implausible.

cestith a day ago | parent | prev [-]

It will be a better value proposition now than it was 12 months ago. It's likely to be better yet in another 12 months. There may be room for a parallel to Moore's Law here.

mchusma a day ago | parent [-]

This I agree with.

Right now, I do actually use OpenAI's gpt-oss-safeguard-20b for somethings, was released 11 months ago, and is $0.075/M input / $0.30/M output now. I could see this model being in fairly widespread use at 10x speed and 1/10th cost if it was introduced today. Meaning, that for some usecases (moderation) i think dedicated chips can pan out today.

But for more general models, its tougher. Gemini 3 pro was launched in November, if ASICs brought it down 1/10th in cost, it would be $0.20/$1.2. GPT 6 Luna is $0.1/$0.50. Luna is better at a lot of things, but not everything. So 1/10th doesn't really make the ASICS investment worth it in my opinion, but if it brought it down to 1% ($0.02 / $0.12) it would be a really compelling model with a lot of use.

BUT, do i think something like Luna is probably generally capable of doing a huge amount of knowledge work. So if Luna came out at 1/10th the cost a year from now, it would probably be compelling for a while.

It all depends on the rate of improvement in cost/capability.

sanderjd a day ago | parent [-]

Yeah I think this is the right mental model. But we have no idea what any of the coefficients will be on any of the terms moving forward :)

sanderjd a day ago | parent | prev | next [-]

To be clear, I agree with the overall premise of the article!

But I would probably take a long horizon bet that the grep implementation on my machine will remain cheaper than an equivalent ai task, even though I think those ai tasks will become far cheaper over time.

I just think the original comment's model of asymptotic approach is probably more likely to be accurate than the model of the line blowing through this grep-like cost level.

thenthenthen a day ago | parent | prev | next [-]

This whole story really reminds me of crypto coins. Like.. going from mining one coin, or lets say token, to millions of fractions like 0.00000000001 bitcoin a week.

pixl97 a day ago | parent [-]

There is a reason it took 4 and a half billion years for human intelligence to develop.

onraglanroad a day ago | parent | next [-]

Around half of that was going from single celled life to multi celled life.

The complexity gets faster as you get on with it.

mschuster91 20 hours ago | parent [-]

And the progress humanity made in the last 100 years alone... some things end up to be completely world-changing because they enable things that only were an unfeasible dream before. The invention of the printing press, sanitation, vaccines , computers, the Internet certainly are such enabler technologies.

With AI, the question is still open if this will actually turn out to be something useful or if it will in the end just be another way for the elites to make untold profits.

formerly_proven 20 hours ago | parent [-]

Stratigraphically the invention of agriculture and the first thermonuclear weapon happened at the exact same instant.

hobofan a day ago | parent | prev [-]

???

Yes, because it was a largely random undirected process.

pixl97 a day ago | parent [-]

Even in directed processes the low hanging fruit is harvested first.

Then you have to climb to another branch to get more fruit. The biggest issue with most problem space discovery is you're doing it blindfolded.

onraglanroad a day ago | parent [-]

I probably replied to the wrong comment with my previous response. The low lying fruit, in this case, should be going from single cell to multi cell, but that took ages.

It accelerated from there rather than slowing down.

BiteCode_dev 10 hours ago | parent | prev | next [-]

postgres in asic however...

lstodd a day ago | parent | prev [-]

Do you mean most of uses of grep are backreferencing? In my 30-yr career I did not use regex backrefs once except for learning them.

serbuvlad a day ago | parent [-]

No, it just gets much more complicated to implement grep both in general, and especially in hardware if you support backreferences, since those make it impossible to compile the regular expression into a state machine.

rdsubhas a day ago | parent | prev | next [-]

grep is deterministic. Llm is probabilistic. Llm can be transferred to a tiny quantum cpu or a lower precision float.

When the author wrote Llm can be as cheap as a tool, I read it as not equivalent. They even said the Llm can be embedded into a tool.

Their point was, the higher level use case — like classification — could become as cheap as grep. Which is quite well possible.

sanderjd a day ago | parent [-]

Yeah you may be right!

scotty79 a day ago | parent | prev [-]

depends on what you are grepping ... greapping a large file might be more expensive one day than generating n-th token with LLM that works fully in hardware

you could make hardware implementation of grep and store the file itself next to it in some ROM but that's not a very useful grep ... while hardware LLM is exactly as useful as software LLM only orders of magnitude faster

sanderjd a day ago | parent [-]

Yeah it's a pretty poorly specified problem. It needs to be some kind of "equivalent task", but it's not clear how to define that.

BearOso a day ago | parent | prev | next [-]

4-5 orders of magnitude is huge. Assuming an order of base 10, it's 10000x-100000x. So a call to grep may return in 1s on a typical PC. That means a GPT call takes equivalent energy of 10000-100000 PCs to do the same in 1s. That's a difference that can't be equalized with scaling. It would require a revolutionary breakthrough.

I also don't understand where the idea that frontier models are getting better efficiency comes from. The results are certainly improving, but that comes from feedback and multiplexing requests, which cost more.

chewbacha 5 hours ago | parent [-]

Recall the articles claim that efficiency is gaining 2.5 orders of magnitude per year.

Something seems off about this.

FranOntanaya a day ago | parent | prev | next [-]

LLM is spicy memoizing, so it can potentially be faster than a tool call. But people will spend a month tweaking and testing to ensure they have the level of determinism they need, which means it's more expensive, and that they should have used actual memoization in the first place.

jandrese 21 hours ago | parent | prev | next [-]

A classic case of someone projecting out to infinity from just after the first bend of the S curve.

lelanthran a day ago | parent | prev | next [-]

> The author observes that a call to GPT-5.6 Luna is only 4-5 orders of magnitude more expensive than grep, and then predicts that at current rates of progress, calling an LLM will soon be cheaper than a grep.

At some future point where LLM hardware is cheaper than simply running grep, then grep equivalent would benefit from those selfsame hardware improvements and be cheaper to run as well, probably still by the same ratio.

gwbas1c a day ago | parent | prev | next [-]

Well, think that statement through a bit:

Grep reads through the entire file looking for patterns.

An LLM scans its neural net (in ways that I don't understand) which is kinda-sorta like having a huge index.

You can improve over Grep if you have an index; and the LLM has an index.

Thus, it's plausible that an LLM can be more efficient at reading its neural net (IE, index) than Grep reading the whole file.

saltcured 18 hours ago | parent | next [-]

But if the problem is literally grep (search this file you've never seen before), no index can pre-exist.

If you assume the file arrives ahead of time, can be indexed, and that this is worthwhile because we want to support multiple pattern matched retrievals, then sure it makes sense to consider indexed query schemes and upper/lower bounds. Each query could be faster as an inference if it doesn't have to re-scan the whole file.

But I don't think anybody, in good faith, can pretend that any LLM can digest a file faster than grep can. Particularly, if you admit the vector processing dedicated to doing the convolution kernel(s), you should also admit similar hardware could run a vectorized grep.

kelnos 7 hours ago | parent | prev [-]

The LLM doesn't have an index of every single file I might want to grep, though. In practice it has an index of very few of them, and perhaps even none of them.

arijun a day ago | parent | prev | next [-]

It might never beat out grep, but it could beat some more expensive to call tools, similar to how heuristics will often be faster than exact answers. Rust Analyzer can be slow at times, I could see an AI tool taking over a subset of its work.

nextaccountic 14 hours ago | parent [-]

It's probably better to optimize rust-analyzer first (and now, this became easier). I mean, see rust-glance: it's not feature complete but it points out to different tradeoffs in this space

WokeUp420 3 hours ago | parent | prev | next [-]

If the providers can't find a way to nickel and dime us to death they will no longer provide the service

gregdeon a day ago | parent | prev | next [-]

Right. And some hardware improvements will speed up both grep and Luna, which won't close the gap.

DoctorOetker a day ago | parent [-]

not necessarily, one may be easier to parallelize while the other suffers some serial computation bottleneck.

gunalx a day ago | parent [-]

Grep is trivially parallelizable if you care to do it though.

https://iepathos.github.io/ripgrep/performance/#work-stealin...

robotresearcher a day ago | parent [-]

Storage access isn’t, though. You have to read every byte of a (non-sorted) file to find words in it. And whether it’s disk or RAM, the bandwidth is usually a key constraint.

That’ll be just as true for an ASIC NN as it is for good ole grep.

cestith a day ago | parent [-]

When storage bandwidth is a big enough problem, that will get addressed.

NVMe v1 wasn't released until 2011 and there was no hardware available until 2012. Before that the fastest drive interface was 6 Gbps SAS. Then we got 4 GBps (32 Gbps) with NVMe v3, 8 Gbps (64 GBps) with v4, and 16 Gbps (128 Gbps) with v5. V6 is slated to double again. v7 is currently planned to double that. This is less than 15 years of progress.

In the 1990s, we went from 33 Mbps to 66, to 100, then 133 with IDE. We went from the 40 Mbps of 1986's SCSI 1 to 80 of SCSI 2 in 1994. Since then parallel SCSI has gone to 80, 160, 320, 640 (Ultra 2 wide), 1280 (Ultra 3), 2560 (Ultra-320), and 5120 (Ultra-640) Mbps.

SAS has also gotten faster, with 6 Gbps, 12 Gbps, and 22.5 Gbps. NVMe is still lower overhead and lower latency.

Memory bandwidth can also be addressed. Stock servers with EPYC are 16 channel DDR5. That's 409.6 GBps. Four channels of DDR3 was only 102.4 GBps. Video and accelerator card memory bandwidth is also increasing.

fnordpiglet 19 hours ago | parent | prev | next [-]

A few years is hardly forever and the state of the world here indicates a lot of low hanging fruit still exists.

An LLM can certainly be cheaper than grep, because it’s an approximation, while a grep is deterministic and must examine every byte in what can be a relatively complex state machine for a regex based grep. There are other scales to consider like the scale of your local hardware vs the highly multitenant and high end hardware of the hyper scale inference providers.

There are already high volume models for coding inference where the reasoning time is crazy low and cheap per token where it can build reasonably simple software so blindingly fast it isn’t implausible the bottleneck is the latency in tools and networks. I find them hard to use at times because I don’t have time to think through the next turn by the time it’s done.

Regardless I wouldn’t be surprised to see a world where tokens are so cheap it’s not worth metering them but charging licensing feels with meter tiers at the far horizons to prevent abuse, charge outliers. Subscription models already set this stage well.

The other side to consider is bountiful capacity will also drive tokens to near zero price. The data center build out is barely underway and as it materializes, as hardware efficiencies improve, as techniques and model science and technology improves, harnesses, methodologies , etc improve, the economics flip from load shedding to trying to keep the data centers utilized. The economics lead to the world where tokens are not a unit of measurement for cost for anyone other than the inference providers to manage their utilization.

nextaccountic 14 hours ago | parent | next [-]

> An LLM can certainly be cheaper than grep, because it’s an approximation, while a grep is deterministic and must examine every byte

You mean a grep over terabytes of data vs a LLM with gigabytes of parameters?

If you have so much data, you can use an index to search. It's unlikely that LLMs are going to be cheaper than properly indexed search DBs (which is what we should be comparing them with)

fnordpiglet 33 minutes ago | parent [-]

Gigabytes loaded into GPU memory being processed by custom silicon designed for the task that’s exactly the same on every inference? Even now parameters physically baked into the silicon for super low latency? Yes.

The point of a grep is for adhoc analysis of data that isn’t in a database. At best you could use an inverted index, which is extremely expensive to create and maintain, but if you don’t know a priori what you’re going to search for, or even if an inverted index helps with your query, it’s pointless and expensive to index literally everything you could ever use to save some time on a tool call.

The point isn’t to find a way to make searching more efficient. It’s that LLMs are becoming very efficient, and a measure is relative to grep. Making grep and searching more efficient has been a task in CS for decades. LLMs is relatively new beyond a very small crowd. It’s also not a goal to make LLMs better at grep than grep, but as a relative reference point that inference is getting cheap and fast and has opportunity to get faster far beyond grep simply due to unclaimed optimizations more available for the newer technology.

19 hours ago | parent | prev [-]
[deleted]
adrianN 11 hours ago | parent | prev | next [-]

There is no reason to assume that quantum computers would benefit LLMs in particular. Perhaps we could implement LLMs as analog circuits to save energy.

14u2c a day ago | parent | prev | next [-]

> calling an LLM will soon be cheaper than a grep

From a computational standpoint this is obviously nonsense, but from an attentional one I'm not so sure. It may already be more attentionally expensive to use grep in some cases, such the moment you need to remember a non standard arg. And if this applies for performing a simple http operations, then it certainly applies going up the complexity chain.

stabbles 21 hours ago | parent | prev | next [-]

What if the tool is more advanced, like an optimizing compiler: `g++ -O3 -march=native -x c++ - <<EOF ... EOF`

If the compiler invocation is sufficiently slow, the llm could consider outputting a binary directly?

For all we know matrix multiplications are a faster way to generate optimized machine code than branchy sequential compiler code with tons of heuristics and passes.

echoangle 21 hours ago | parent [-]

> For all we know matrix multiplications are a faster way to generate

“are” or “could be”?

thesmtsolver2 a day ago | parent | prev | next [-]

> Barring a true breakthrough in something like quantum computing or room-temperature superconductors

Won't that also help grep and then move the asymptote down more?

contact9879 a day ago | parent | prev | next [-]

room-temperature superconductors, sure, but I fail to see how quantum computing will disrupt – in the medium term (25 years or so) – classical computing in any meaningful way

Is running LLMs (or some other ML workload) on/with quantum computers expected to bring efficiency gains?

BobbyTables2 14 hours ago | parent | prev | next [-]

The cost for my employer to employ me is only 4-5 orders of magnitude over that of the snack in the vending machine…

m463 21 hours ago | parent | prev | next [-]

But grep is just a tool in a pipeline between a question in your brain and an answer you are searching for.

what if an LLM finds the answer early?

grep might continue to read everything, doing the wrong thing correctly.

matthewmcg a day ago | parent | prev | next [-]

"Did you know that disco record sales were up 400% for the year ending 1976, if these trends continue...AY!"

someonebaggy a day ago | parent [-]

AY-3-8913?

rtpg 15 hours ago | parent | prev | next [-]

I think it's an interesting thought experiment: could an LLM call be a "cheaper" grep?

Especially for deterministic activities it just feels impossible to imagine general LLM tech handling the problem better, despite everything being said.

But hey, tech is filled with "smashing the generalist hammer works better than the specialized tooling". Would be odd though!

TeMPOraL 8 hours ago | parent [-]

One thing that's easy to miss about performance is that it depends on framing.

An example I like to give: optimizing a data processing program's runtime by 5x is obviously 5x speedup for everyone. But if, for some reason[0], this means it crashes and restarts more often, it stops looking like this to end users. If every restart means it needs to start from scratch, and it restarts 10 times on average now where it didn't restart before, the 5x speedup suddenly looks like 2x slowdown to end user.

In this sense, LLMs are already much more efficient than most CLI tools, by a combination of:

- User not having to remember the exact invocation, or even the name of the CLI tools

- LLM being able to run the CLI tools and chain them on its own

- LLM being able to self-correct in case it got things wrong, or when actual output show that user's idea was right, but the instructions were wrong

Prompting "okay, list those processes sorted by runtime and match them against these output files" is both faster to type than the actual commands, it also end-to-end completes much faster than doing it by hand.

--

[0] - And I don't mean a bug. Say it's some batch processing run on a cluster with aggressive resource usage management; 5x speedup means it runs much hotter than before, which may put it on the top of "kill list" for when the cluster managing code needs to free up some resources.

16 hours ago | parent | prev [-]
[deleted]