Yeah, and how we build—and what we surface operationally—matters as well.
I run several AI-based products, and I’ve moved almost entirely to agentic coding, so this is a huge concern for me. One thing that has helped in the coding realm is separating planning from execution: I use a stronger, more expensive model for architecture, research, and difficult decisions, then hand the implementation work to cheaper agents where the task is more constrained.
On the product side, I treat token usage and costs like any other production resource. We record usage by request, user, feature, and model, surface it in admin dashboards, and set budgets and hard cutoffs.
Alerts are useful, but automatic limits matter more—especially as a small business guy so a 2 AM loop doesn't bankrupt me :)
In some sense, devs are now responsible for a P&L the way a business manager would be, but I suspect that nobody is paying enough attention to the P part of it. When you incentivize people to spend as much money as possible but don’t hold them accountable properly for what they actually produce, this is what happens.
I wonder how it's possible for a developer to assign profit. The article mentions Uber's $1500 limit per developer per month. At work we're using an LLM to analyze Windows crash dumps, which turns out to be quite expensive -- several dollars per dump, and you might analyze many every hour. Others don't use AIs very much. Should those not using so many tokens donate them to the crash dump people? And back to your point, how can we assign a profit to this? Customers love having their crash dumps analyzed quickly, but that's not the same as it being profitable.
> At work we're using an LLM to analyze Windows crash dumps, which turns out to be quite expensive -- several dollars per dump, and you might analyze many every hour
Is that in any way useful?, how so?, are dumps from optimized builds?
I've found that most of the time I don't even need to open a dump because of regular automation providing all thread callstacks in tickets... That and logs are generally enough...
I'm not directly involved in the day to day activity around this, but as I understand it, it's about triaging related crashes together and associating them with prior bugs and suggesting fixes, else escalating.
It is just extremely difficult in most companies to draw a line between a specific feature and an amount of revenue. A lot of engineering has a stochastic type of impact.
(It’s often easier to see what a feature does to reduce costs though)
also, codex apparently uses fewer tokens to complete tasks, in part because their tokeniser is about 80% the length of that in tokens for the same string as that of the latest anthropic ones. This might be fable only though.
I have both the Claude and ChatGPT entry-level business plans, and I feel like I get more use out of Claude, and that's even with some Fable and Opus use.
I suspect this will turn out to be a super overblown issue: AI spend is literally the easiest spend to regulate in the entirety of businesses. No machinery is grinding to a halt over it, no asset that had to be bought and is now useless. You don't even have to employ or fire staff to give it a go (of course, you can still do both for other reasons). There are a lot of options that you can try out and substitute for each other, as new stuff comes up, because most things are compatible.
Sure, if you start at this point, where a good chunk of employees, who never had that ability, can now spend a lot of money at their discretion, that's probably going to be costly at first. Then people will learn from that and set direction adn guardrails.
How does that concern individual companies as AI consumers? The hyperscalers have no trouble utilizing their GPUs (and I would suspect they mathed it out to be profitable but, again, that's just a different topic).
yeah, it's easy to regulate, but the psychological impact isnt.
You spend 3 days making AI do something, and now what, you're suppose to spend 2 days trying to keep up with whatever it's done? That's like if your coworker's projects, every week, were handed to you on Thursday and you're told to finish them up.
No matter how smart you are, the bootstrap of new knowledge is impossible.
So sure, it's easy to turn the spigot off at arbitrary dollar values, but you can't just turn the worker's mindset off.
Workflow is valuable because of how in the flow it is.
And, if you try it out and find that for your particular circumstances there's no level of spend on AI that's giving you positive ROI, you can just...not do it.
It seems like execs these days think that if they're not doing the One Thing Everyone's Doing, they're necessarily missing out, leaving potential revenue on the table, what have you. But the only reason to use AI in a business is if it makes you more money, so if you try it, and it's not doing that...I guess the question is, who are you going to believe, Sam Altman or your lying eyes?
If I may suggest people move away from harasses and start using Emacs. Gptel is amazing and the rest of Emacs plays incredibly well with llm development. Since the human is always in the loop token costs are also tiny compared to anything else.
I looked at gptel and eca about a year and a bit ago… how far have they come, at the time they were more geared toward code completion and essentially a buffer for communications - but all while not having some kind of Ralph Loop, Skills, and auto-compaction.
Is this all built in these days so that you can Superpowers a prompt to the point where it will automagically chug along for hours until it’s satisfied it’s completed the end goal?
I work at a very big company and I have unlimited access to Codex with no visibility on token usage. I don't know if this is the norm but seems kind of crazy to everyone in my team
Same, however managers are starting to ask questions, like 'what can we do to help remove bottlenecks' (they think sprinkle unlimited tokens -> revenue multiplies). In actual fact what happens is devs benefit.
It's like the company gave every senior dev a super eager brilliant fellow coder to do their work for them so they can 'do more important things' i.e. Netflix and sleep.
'Yes still working on this ticket' When codex/cc completed it flawlessly last week. The upside is absorbed by the devs knowing they could be soon surplus to requirements.
I think a lot of ppl assume that usage here is simply for AI coding, which is easily governed. I suspect that the more tricky issue are those usage powering workflows and application logic that cannot be easily throttled down.
https://archive.is/dR2J2
Yeah, and how we build—and what we surface operationally—matters as well.
I run several AI-based products, and I’ve moved almost entirely to agentic coding, so this is a huge concern for me. One thing that has helped in the coding realm is separating planning from execution: I use a stronger, more expensive model for architecture, research, and difficult decisions, then hand the implementation work to cheaper agents where the task is more constrained.
On the product side, I treat token usage and costs like any other production resource. We record usage by request, user, feature, and model, surface it in admin dashboards, and set budgets and hard cutoffs.
Alerts are useful, but automatic limits matter more—especially as a small business guy so a 2 AM loop doesn't bankrupt me :)
In some sense, devs are now responsible for a P&L the way a business manager would be, but I suspect that nobody is paying enough attention to the P part of it. When you incentivize people to spend as much money as possible but don’t hold them accountable properly for what they actually produce, this is what happens.
I wonder how it's possible for a developer to assign profit. The article mentions Uber's $1500 limit per developer per month. At work we're using an LLM to analyze Windows crash dumps, which turns out to be quite expensive -- several dollars per dump, and you might analyze many every hour. Others don't use AIs very much. Should those not using so many tokens donate them to the crash dump people? And back to your point, how can we assign a profit to this? Customers love having their crash dumps analyzed quickly, but that's not the same as it being profitable.
> At work we're using an LLM to analyze Windows crash dumps, which turns out to be quite expensive -- several dollars per dump, and you might analyze many every hour
Is that in any way useful?, how so?, are dumps from optimized builds?
I've found that most of the time I don't even need to open a dump because of regular automation providing all thread callstacks in tickets... That and logs are generally enough...
I'm not directly involved in the day to day activity around this, but as I understand it, it's about triaging related crashes together and associating them with prior bugs and suggesting fixes, else escalating.
https://seldon-ai.com/blog/how-much-of-your-llm-bill-is-just...
It is just extremely difficult in most companies to draw a line between a specific feature and an amount of revenue. A lot of engineering has a stochastic type of impact.
(It’s often easier to see what a feature does to reduce costs though)
For those that recently switched from Claude, does Codex gives you more usage than Claude Code on the highest personal plan?
I frequently max out my weekly usage, and given this [1], hopefully Codex might give me more milage.
[1]: https://news.ycombinator.com/item?id=48126429
Yes, according to this:
https://x.com/SemiAnalysis_/status/2064815044085318040?s=20
also, codex apparently uses fewer tokens to complete tasks, in part because their tokeniser is about 80% the length of that in tokens for the same string as that of the latest anthropic ones. This might be fable only though.
I have both the Claude and ChatGPT entry-level business plans, and I feel like I get more use out of Claude, and that's even with some Fable and Opus use.
I suspect this will turn out to be a super overblown issue: AI spend is literally the easiest spend to regulate in the entirety of businesses. No machinery is grinding to a halt over it, no asset that had to be bought and is now useless. You don't even have to employ or fire staff to give it a go (of course, you can still do both for other reasons). There are a lot of options that you can try out and substitute for each other, as new stuff comes up, because most things are compatible.
Sure, if you start at this point, where a good chunk of employees, who never had that ability, can now spend a lot of money at their discretion, that's probably going to be costly at first. Then people will learn from that and set direction adn guardrails.
> no asset that had to be bought and is now useless
Dare I say the GPU bought today won't be economical in 3-4 years time?
How does that concern individual companies as AI consumers? The hyperscalers have no trouble utilizing their GPUs (and I would suspect they mathed it out to be profitable but, again, that's just a different topic).
yeah, it's easy to regulate, but the psychological impact isnt.
You spend 3 days making AI do something, and now what, you're suppose to spend 2 days trying to keep up with whatever it's done? That's like if your coworker's projects, every week, were handed to you on Thursday and you're told to finish them up.
No matter how smart you are, the bootstrap of new knowledge is impossible.
So sure, it's easy to turn the spigot off at arbitrary dollar values, but you can't just turn the worker's mindset off.
Workflow is valuable because of how in the flow it is.
And, if you try it out and find that for your particular circumstances there's no level of spend on AI that's giving you positive ROI, you can just...not do it.
It seems like execs these days think that if they're not doing the One Thing Everyone's Doing, they're necessarily missing out, leaving potential revenue on the table, what have you. But the only reason to use AI in a business is if it makes you more money, so if you try it, and it's not doing that...I guess the question is, who are you going to believe, Sam Altman or your lying eyes?
If I may suggest people move away from harasses and start using Emacs. Gptel is amazing and the rest of Emacs plays incredibly well with llm development. Since the human is always in the loop token costs are also tiny compared to anything else.
I don’t quite understand what you’re suggesting.
i believe something like this: https://mwolson.org/blog/emacs/2025-12-03-my-emacs-ai-setup/
for those who use vim (me) there's also, e.g., this: https://voipnuggets.com/2025/03/30/supercharge-your-vim-edit...
I looked at gptel and eca about a year and a bit ago… how far have they come, at the time they were more geared toward code completion and essentially a buffer for communications - but all while not having some kind of Ralph Loop, Skills, and auto-compaction.
Is this all built in these days so that you can Superpowers a prompt to the point where it will automagically chug along for hours until it’s satisfied it’s completed the end goal?
How long until this is handled like human hiring (business case, budget, performance reviews, layoffs)?
I work at a very big company and I have unlimited access to Codex with no visibility on token usage. I don't know if this is the norm but seems kind of crazy to everyone in my team
Same, however managers are starting to ask questions, like 'what can we do to help remove bottlenecks' (they think sprinkle unlimited tokens -> revenue multiplies). In actual fact what happens is devs benefit.
It's like the company gave every senior dev a super eager brilliant fellow coder to do their work for them so they can 'do more important things' i.e. Netflix and sleep.
'Yes still working on this ticket' When codex/cc completed it flawlessly last week. The upside is absorbed by the devs knowing they could be soon surplus to requirements.
At the moment a lot of companies thinking of it like speculative capex - we can just stop doing it if we don’t get results, or we can easily optimize.
My concern is that with all the bundling that the model labs are doing the lock-in becomes harder than anticipated to unwind
[dead]
I think a lot of ppl assume that usage here is simply for AI coding, which is easily governed. I suspect that the more tricky issue are those usage powering workflows and application logic that cannot be easily throttled down.
Story from June OP;
Discussion then: https://news.ycombinator.com/item?id=48602571