Sure but that's only half the equation. Screen readers with realistic high-speed AI voices are still VERY much necessary since users are not always going to be in an environment where they can talk out loud.
Anecdotally but it definitely feels like in the last couple weeks CC tends to be more aggressive at pulling in significantly larger chunks of an existing code base - even for some simple queries I'll see it easily ramp up to 50-60k token usage.
This really speaks to the need to separate the LLM you use and the coding tool that uses it. LLM makers utilizing the SaaS model make money on the tokens you spend whether or not they need them. Tools like aider and opencode (each in their own way) use separate tools build a map of the codebase that they can use to work with code using fewer tokens. When I see posts like this I start to understand why Anthropic now blocks opencode.
We're about to get Claude Code for work and I'm sad about it. There are more efficient ways to do the job.
When you state it like that, I now totally understand why Anthropic have a strong incentive to kick out OpenCode.
OpenCode is incentivized to make a good product that uses your token budget efficiently since it allows you to seamlessly switch between different models.
Anthropic as a model provider on the other hand, is incentivized to exhaust your token budget to keep you hooked. You'll be forced to wait when your usage limits are reached, or pay up for a higher plan if you can't wait to get your fix.
CC, specifically Opus 4.5, is an incredible tool, but Anthropic is handling its distribution the way a drug dealer would.
It's like the very first days of computers at all. IBM supplied both the hardware and the software, and the software did not make the most efficient use of the hardware.
Which was nothing new itself of course. Conflicts of interest didn't begin with computers, or probably even writing.
OpenCode also would be incentivized to do things like having you configure multiple providers and route requests to cheaper providers where possible.
Controlling the coding tool absolutely is a major asset, and will be an even greater asset as the improvements in each model iteration makes it matter less which specific model you're using.
I'm curious if anyone has logged the number of thinking tokens over time. My implication was the "thinking/reasoning" modes are a way for LLM providers to put their thumb on the scale for how much the service costs.
they get to see (if not opted-out) your context, idea, source code, etc. and in return you give them $220 and they give you back "out of tokens"
> My implication was the "thinking/reasoning" modes are a way for LLM providers to put their thumb on the scale for how much the service costs.
It's also a way to improve performance on the things their customers care about. I'm not paying Anthropic more than I do for car insurance every month because I want to pinch ~~pennies~~ tokens, I do it because I can finally offload a ton of tedious work on Opus 4.5 without hand holding it and reviewing every line.
The subscription is already such a great value over paying by the token, they've got plenty of space to find the right balance.
> My implication was the "thinking/reasoning" modes are a way for LLM providers to put their thumb on the scale for how much the service costs.
I've done RL training on small local models, and there's a strong correlation between length of response and accuracy. The more they churn tokens, the better the end result gets.
I actually think that the hyper-scalers would prefer to serve shorter answers. A token generated at 1k ctx length is cheaper to serve than one at 10k context, and way way cheaper than one at 100k context.
> there's a strong correlation between length of response and accuracy
i'd need to see real numbers. I can trigger a thinking model to generate hundreds of tokens and return a 3 word response (however many tokens that is), or switch to a non-thinking model of the same family that just gives the same result. I don't necessarily doubt your experience, i just haven't had that experience tuning SD, for example; which is also xformer based
I'm sure there's some math reason why longer context = more accuracy; but is that intrinsic to transformer-based LLMs? that is, per your thought that the 'scalers want shorter responses, do you think they are expending more effort to get shorter, equivalent accuracy responses; or, are they trying to find some other architecture or whatever to overcome the "limitations" of the current?
It's absolutely a work-around in part, but use sub-agents, have the top level pass in the data, and limit the tool use for the sub-agent (the front matter can specify allowed tools) so it can't read more.
(And once you've done that, also consider whether a given task can be achieved with a dumber model - I've had good luck switching some of my sub-agents to Haiku).
From a cursory glance it appears to be a physical guitar pedal that lets you program virtual effects. The "vibe coding" aspect is likely a system directive + effects library SDK docs fed into an LLM along with the user prompt that generates the appropriate C++ which is then compiled into an effect and run on the pedal.
Note: Which is still very cool. The previous programmable guitar pedals that I've seen were all pretty low-level.
Ive been interested in doing this with a raspberry pi. Ive plugged my guitar to my pc and used FL Studio, a daw, and can add effects to it live and was curious if someone would code a os (i guess) that only ran VST (the filters) and had a screen and knobs to control things. I know its very possible, I just didnt have the time to learn how to do it.
Lol, you read my mind. I’ve been wanting a generic-looking, wood-grained “tablet display” covered with a dozen PHYSICAL faders, sliders, and knobs that you can leave permanently hooked up to a DAW that interfaces with virtual synths for over a decade now!
When you switch to a different VST, the hardware’s display would dynamically update all the text around each dial and button to match the corresponding virtual control.
Slightly related, there was a programmable guitar pedal based on the Pi Zero called the Pedal-Pi a little while back that might interest you:
> I’ve been wanting a generic-looking, wood-grained “tablet display” covered with a dozen PHYSICAL faders, sliders, and knobs that you can leave permanently hooked up to a DAW that interfaces with virtual synths for over a decade now!
Just one of several. These have existed for at least two decades, save for "dynamically update all the text around each dial", which has a variety of complications that I won't go into here.
Yeah I should have clarified - I have plenty of generic MIDI controllers. The special sauce is reflecting the "VST" rendering/presentation of its own sliders/dials onto physical ones.
This means not having to look up and down constantly between your computer monitor and the physical hardware since the knobs/dials each have small screens/displays are 1:1 matches (so Frequency Range, Sub Audio, Clamping Point, Oscillator Frequency, etc).
VSTs are rather inscrutable and I think it would be difficult to design in an agnostic way that played nicely out-of-the box with the majority of them. Doesn't stop me from lusting over the possibility though.
I am a little confused. I think you the mean reverse of the usual mapping: (a) from the surface to the plugin GUI (b) the plugin GUI is drawn to look like the surface. Right?
Interesting idea, but creates a bit of a coding conflict: the plugin developer writes the plugin GUI (typically feeling they've lavished a lot of love on it); they're not in control of the layout of a control surface (and indeed, may have no way to know what it is). So a job that would really be the job of the control surface manufacturer can't be done because that's the domain of the plugin developer.
It's fairly easy to imagine a single control surface offering this for a tiny subset of all possible plugins, but getting beyond that seems pretty much impossible to me. There was a protocol that Digidesign/AVID bought back in the mid-oughts which did maybe 60-70% of this, in the sense that it provided negotiation between the plugin and the host/surface. Problem was, it was so complex that almost no 3rd party plugin developer or control surface developer was willing to get involved.
Yeah I'm not explaining myself very well. I don't have a lot of knowledge around the inner workings of how the GUI aspect is specified on a VST but it seems to be incredibly diverse which is why while I'd love to see something like this - I just don't think it's really feasible.
It's all for the love of physical dials - that tactile ability to play with a synth is such an underrated thing.
I've got tons of VST recreations of older synths like the Minimoog Model D, Prophet 5, etc. but it's just not the same fiddling with controls using a mouse...
Elisabeth Homeland does a range of Max for Live Wrappers that act as a translation layer between the host and the hosted VST, rendering the interface in the stock ableton device style. The OP would need to code up a similar template for their surface of choice, and then map the CC's and other MIDI sysex stuff as needed.
You could also do the same thing in an open source DAW too. The problem is that it is specific to the control surface ... the other problem is that it's not actually clear that a given control surface is actually an ideal layout for a given plugin either (hence all the work done by the developer(s) on their own custom GUI).
Using AI to drive text adventures / rogues has been pretty popular for a while now - I remember seeing a pretty dismal performance (although it was over a year ago) where somebody was trying to use an LLM to drive a game of Zork.
In fact, this was one of the very first things I did when Chat-GPT was first released to the public. It was impressive, but far from perfect. It's still not quite there.
One of the first things I did when Nano Banana Pro came out was to feed it room descriptions from the Zork and Enchanter trilogies and ask it to render them.
There was some definite cognitive dissonance. "The best graphics are in your imagination" was always an informal motto among Infocom fans, and something that I'd personally considered an axiom. It turned out to be just plain not true, because NBP showed me some interesting things in the text that I'd never bothered to imagine in any detail.
> I wish people had to visit a place multiple times, spaced out, before their ratings would even count.
That would effectively remove all negative reviews. Eating out is expensive enough as it is, I'm not going to pay for mediocre food a second or third time around.
A better approach (for almost anything) is just to focus on reading 2-4 star reviews since they're usually the most measured.
That's what I typically will do, or search key phrases that I care about. I agree that there would be a lot less reviews, but I'd personally prefer quality over quantity.
I feel like I’ve seen half a dozen HN submissions about this 900 WPM speed reading "barrier", and I’ll say it again: color me unconvinced until a proper study is done that measures people’s WPM alongside both their short-term and long-term recall.
Anecdotally, my ability to remember what I’ve read seems directly proportional to how much time I spend quietly reflecting on each section of a paper.
Speed reading seems more like a parlour trick than anything else.
Second the recommendation for "Moonwalking with Einstein." Ed Cooke (the memory coach and world memory champion featured prominently in the book) is also a really nice chap.
If you have any interest in memorization or mnemonics, it's a great read.
> If you have any interest in memorization or mnemonics, it's a great read.
Absolutely. Even if you don't have an interest in the subject, it's worth a read. I honestly picked that book up out of random; I had no idea such a world of memory existed. Brilliant book.
Totally agree. If you like this style of memoir + deep subject dive, I also highly recommend anything by A.J. Jacobs - his "Year of Living Biblically", and "The Know-It-All" are great reads in the same vein.
reply