It sometimes feels to me that cloud AI providers have convinced people that cloud AI is worth it because of all the ways people have been able to use cloud AI to write blog posts about using cloud AI to make cloud AI more efficient for something that they haven't shipped yet and aren't really ready to talk about.
... replying to internet comments to reassure the fact that cloud AI is worth it because we're 'this close' to shipping a product that allows more efficient usage of cloud AI ...
But seriously, a friend of mine has been both amazed and frustrated in equal measure by cloud AI, and I think the frustration part is resultant from the new precedent set by the amazing parts.
I’ve used it for several improvements to our wysiwyg. I was able to refactor to a much more cohesive architecture that is making future work much easier/safer. We got a fzf like search algorithm for an autocomplete that includes marking which characters matched. It fixed some jank performance issues I was struggling to track down.
Fixed small several bugs last week without even open the editor. It wrote tests that confirmed the bugs, then fixed them. Then I manually confirmed as well.
It built a double entry event log. A single application event produces two logs, one for the person doing the action, one for the person being acted upon.
For a nasty problem we have, we had AI prototype 2 different solutions. Then we reveiewed them as a team. We threw those out but it was very helpful input into our decision making.
> I’ve used it for several improvements to our wysiwyg. I was able to refactor to a much more cohesive architecture that is making future work much easier/safer. We got a fzf like search algorithm for an autocomplete that includes marking which characters matched. It fixed some jank performance issues I was struggling to track down.
so, basically did some vague, almost incomprehensible stuff. seems par for the course.
How was any of that incomprehensible? They gave a list of some actual things they shipped. The hand wavy dismissal where you pretend they didn’t say anything just exposes your bias. You don’t want to hear a success story so you don’t.
Checking all the past "what are you working on?" threads just to realize that, somewhere in August 2024 stuff just exploded and the average thread goes reached ~1000 messages, from ~50 pre-August.
I shipped this shader based video compositor as part of a bigger project ive been working on since before LLMs but the compositor was 100% ai and it works fantastically. It's not a huge project but I and a number of my users use it. https://lowkeyviewer.com/studio/
I did ship a quite efficient quantum simulator as a toy out of other work (and a block truncation certificate as a side-product). https://github.com/cgiogkarakis/qut
I have been thinking about this for a while, because I personally need a career pivot but I was going to move into personalised training, and I think AI likely really messes with the viability of that.
If you characterise questions as bad faith so you don’t have to answer, sure.
Since this is my thread, and since I am an exasperated freelancer who has made most of his post-dot-com career from writing exactly the kind of quite small, simple, unambitious, often internal things for smaller customers that nobody would confuse with anything cool, who is trying to understand how AI is going to make his life any better when it’s so opaque, fast moving, poorly documented and full of unverifiable claims battling unverifiable claims, let me assure you that the following question is not being asked in bad faith:
I've shipped small, simple, unambitious internal things for our company that saved people lots of time, and I've shipped them in minutes rather than the a day or two they used to take.
I've just shipped a migration from our old auth service to the new one in a week, a migration that we've put off for three years because it would take the team months to finish.
I don't use it to ship whole products. I have it do some tasks.
I have it code dsp techniques in journal articles I hand it. I have it create the unit tests, pipelines documentation. Then I manually verify the test cases aren't wrong and run the tests. If they pass it does what I wanted and I start looking at the code quality. It varies from being better than I could have done it to being objectively bad. I fix it if it needs fixing, then I'm done.
I have also pointed it at issues in our backlog and it usually finds the subtle logic errors underlying the behavior in the issue.
I haven't started and entire product from zero and shipped it. Mostly because I haven't started a new product since it was capable of that. But also because it has a scale beyond which I don't find it as useful. I have used it for an entire repo, but in the crates.io or npm scale of repo, not boost scale.
I work at a 6 year old startup. Essentially every feature and bug fix we’ve shipped in the last year has had LLMs involved. Every project plan involved AI, either for writing or for codebase research. For code review we get AI to do the first pass.
Why assume bad faith? I've witnessed a barrage of "proof of concepts" at my dayjob by folks who have zero intention of ever hooking up their dashboard to our actual messy data. Shipping is still a major barrier. Is your experience meaningfully different?
My definition would be "users waiting for it who received it"; that's the one that fits the broadest real world definition of the word. Not everything is an organisation, not everyone is paying.
Many very well made software written without any AI was never "shipped" because there were no people who wanted to pay for it, many very poorly made software was shipped because demand and marketing did the job.
So evaluating software by "shipped or not" is just useless.
My team redid a bunch of our ETL. I personally built a programming language that you can download and use, and I’m about to release an iOS app(in a few weeks).
Which is basically a fancy calendar and team management system for my Valorant Premier team haha
It’s on my GitHub as operators-premier-manager but note it is not great: it serves its purpose which is to wrangle my team to show up for practice and scrims
I'm hesitant to respond, because I haven't shipped yet and I haven't shown any evidence. But I am close enough to completion that I am certain Claude's work will be sufficient to ship.
From an implementation perspective, it is about 80% complete, where by "complete", I mean "adequately polished such that I could ship it." (I'm not interested in providing evidence of my claim at this time, and you are welcome to not believe me.) Most of the remaining 20% are optional game modes I could choose to cut (and may, for gameplay reasons).
I do not contend that the code is excellent. But to whatever extent the code is "slop", that has not meaningfully inhibited the ongoing development or caused noticeable issues with the player experience.
The game is not especially ambitious, but it's something I would have been unable to create without genAI. The version of me that could have made it without genAI would have taken > 10x as long to get as far as I've gotten.
That's fair critique, the README itself is indeed slop explicitly written by bots for bots. What it actually does and how it works is actually pretty neat if you care to look.
It's not a full game yet, but the substrate on which I am building one. It implements a completely deterministic SDF VM rendering engine that allows edits in real-time at acceptable performance levels. The engine is essentially folded in on itself as the editor is the game; assuming that an editor mode was actually defined in the world document. It's a lot...
Part of the issue with "shipping" AI-generated code is, what's the value of shipping something that your prospective customers could just make for themselves? Shipping a product used to be the gold standard of value, but I'm not sure it is anymore, the zeitgeist just yet has to catch up.
I think it does have pretty good value when you are your own customer, because you can make exactly what you need. For instance, I'm using it to make a web playground in which I can test the board game I'm designing, instead of asking people to pay for, and install Tabletop Simulator. I'm satisfied. I can tell the code sucks without even looking at it. But I wouldn't have had the time to do this myself, the token cost isn't prohibitive, and it works fine.
This is a bit of a year-of-linux-on-the-desktop question.
Desktop 3D printers are tools; I know many people using them to support their making. And they've utterly changed manufacturing on another level (simply because of their ability to surface a prototype).
It will get better and better and better and still never replace mass production, but mass production will be changed by it.
Not least because of the fundamental shift in availability of the tools to make tools. The productised desktop CNC market is wild and it owes almost its entire existence to the change in the market driven by 3D printing.
Sorry I am not saying that X technology is not important, transformative, etc.
I am saying that the average person is going to want to just have things that work. They are not going to want to have a hobby of using X technology.
It doesn't matter how much you lower the barrier to entry on making apps, websites, games, whatever. Most people are just going to want something that is ready and off-the-shelf.
I mean, why do people pick an iPhone over a cheaper Android even if they are functionally similar? Aside from the (valid) green-bubble/social aspect, it's a much more polished product.
The reality however is that unless you're spending tens of thousands on hardware or setting up cloud instances you can't run anything near close to state of the art.
In almost all cases right now, a subscription with a cloud AI wins.
Yes, it's the Youtube phenomenon - often when looking for domain-specific videos on Youtube I tend to find videos by professional Youtubers not videos by professional domain specialists (overlap is very rare but occasionally you can find a domain specialist Youtuber who applies their domain knowledge to making Youtube videos).
I agree there... I hate the posts that rattle on about non-real-world work. Real world now (for me anyway) is maintaining legacy code, fixing issues, and new development. Now, some of the problems others have with AI are super crappy prompts with no real info other than "do this". I look at myself now more as a software designer and an architect, and the AI as a paid consultant. I give detailed specs and designs. The models are getting better at real deep code and legacy, but there are still holes. BUT give the AI a fighting chance with real detail in the prompts.
a massive number of data engineering agents. We are able to stand up, test, audit, deploy data pipelines much more efficiently with the foundational models.
I can't remember who it was I spoke to recently, but it was some startup for doing code reviews. So I asked how they're handling larger diffs and especially when a code change is related to something requiring knowing a lot of context. Will it hallucinate things that make the review low-quality, etc. I was told "no it's been given guardrails to prevent hallucinations. it doesn't hallucinate." but I was thinking, that's not really how LLMs do or do not hallucinate, is it? (I'm not an AI person so I really don't know).
This is a good/fast/cheap tradeoff, but in the form of accurate/precise/creative, or something in that ballpark anyway.
You can constrain the AI to be more accurate by having it a) equivocate (lose precision) or b) turning the temperature to effectively zero, thus losing "intelligence" and creativity.
There's no such thing as a free lunch. The models perform best out of the box, and everything you add into context makes them perform worse generally, but more likely to do what you want. Every token is a burden, but without those constraints the generation won't do anything.
So by that standard, hallucination is something completely core - you can't get rid of it without losing what makes them useful. You can make different tradeoffs, or use a very smart model in a way that is completely locked down (or adversarially verified, same result) which results in far more tokens used than if you just let the model do it's thing and validated for hallucination independently, outside of the generation loop.
Guardrails can and do help but they don't prevent hallucinations entirely. I generate trivia questions for my app. Questions are true/false and I tell it you must include an explanation of why the question is true for false. I also tell it to give me supporting links which validate its claim. I've had it make up explanations and invent plausible looking URLs. But I wrote a checker that pulls the content of the URL and asks a different model if the URL supports the claim. LLM's are much better at something like that than pulling a trivia question out of thin air. Reviewing diffs can be much the same. It isn't having to write the code but just evaluate if it matches what the commit comments claim it does. You are right, though. Without good comments on PR's and commits (i.e. context) the diff review is going to be a lot of assumptions made by the AI which is where hallucinations get more common.
It's like the frog prompting the scorpion not to sting him as they cross the river. Or like when image models used to routinely draw human hands incorrectly and you'd see these "prompt hacks" that would essentially be stuffed with phrases like NO DEFORMED FINGERS, NO ELDRITCH HORRORS!
You can reduce hallucinations with appropriate grounding checks. You can’t really get rid of them though, so feedback loops with verification are essential.
Doing a loop and having the model review its own earlier output tends to solve this stuff, and for code requiring good test coverage catches them before they even hit that phase.
So while you can't remove "hallucinations" they're corrected before the process is complete, albeit at the cost of more tokens for verification.
Error percentages compound. Having an LLM do something with a 5% hallucination rate, then having an LLM (same or different) with a 5% error rate check it means there's a 10% chance of error, not .25%. Prompting can't save you here; it's the fundamental math.
Two independent task? You have a 95% chance of each task being correct, so total success is .95^2 = 90.25% correct.
Having two AIs verify the same task with each being 95% correct? That's a 5% error per each, so 1-(.05^2) = 99.75% correct.
That is assuming fully independent error rates, which is the real issue. If it is pure hallucinations, then that is an okay assumption, but if there are issues in the underlying prompt/data causing the error rates, then it becomes a very dangerous assumption and I think more human involvement is recommended to better understand and resolve the underlying data problem.
The real interesting bit is that more AI's mean the 2 in the above equations gets bigger, so the error rate gets worse or better depending upon which equation is in play. So if you are in an in-between landscape where you aren't sure there is independence or not (or how much independence between errors), it also becomes unclear if more AI makes the error rate better or worse.
Reliable AI is an oxymoron and deeply misleading. Even if you can stack models the efficiency tanks. Also, just looking at the Wikipedia page (https://en.wikipedia.org/wiki/N-version_programming#:~:text=...), don't LLMs already have all these problems?
I hear you! I read the article and thought the same thing because I've actually built a surprisingly similar pipeline myself, but it culminates with Human review. I've got a trivia app (Hedge Calibrated Trivia) whose whole content pipeline is built on a similar architecture of models evaluating models. I didn't want the same trivia that every other app has and I naively imagined that it would be easy to ask an LLM to give me questions. Turns out when you ask an LLM for trivia questions, the FIRST thing it gives you are the same questions every other app asks!
After iterating into many of the same problems OP describes I settled into a similar pipeline. I generate questions with Gemini 3.5 flash and review with Claude. The different vendor generation and validation eliminates training holes in a single model solution. This is True/False trivia so I ask for an equal mix of True/False questions and also ask for alternate phrasing of the question to the opposite variant. Each statement must provide an explanation and sources which back up the claim. I pass in my existing dataset as questions to avoid, but found the model then rewording the questions or category shopping the questions into related categories in an attempt to re-use them. That led to using Claude Sonnet to check for duplicate "themes" and similar topics. Claude also acts as a critic of the question and the explanation. Sometimes Gemini's "thoughts" leak into the explanation. The critic catches these leaks and also catches "weak" questions (basically shapes that I have identified via examples as lazy or projecting the answer in the question). Once the comparative models have stripped out anything obviously bad, my server curls the source URLs and uses Sonnet to verify that the fetched source supports the claim. Any URL that doesn't resolve throws up flags, and I found Gemini was particularly bad at inventing source URLs for sports trivia. Updated prompting directed it to prefer Wiki links over its fabricated deep links into league websites, which helped immensely. Still one of the biggest tells in review is that the URLs don't resolve or don't confirm the statement.
But review is the entire point here. I have to review them all. A question that lands in the app and is wrong reflects terribly. So while I have a trivia app on the App Store, the real complex App is my private admin app that lets me sit on the couch swiping through each and every question sorted by the model's confidence in its own quality and correctness (weakest first). No question makes it into my bank without me reading, checking all the indicators that came from the models and potentially even rewriting the question to make it better. It all happens in the admin app and exists entirely to prevent hallucinations from reaching real users. Early on I was maybe accepting 1 in 3 questions generated, but I'm probably closer to 2/3rds now. Of course not every dismissed question is wrong. The quality checks I've put in the pipeline are probably giving me 80% questions that are correct and sourced, but sometimes they just aren't what I'm looking for or don't meet my standard.
The best thing I ever did was make an app to review these questions though. Sitting on the couch, kick off a question generation, come back 20 minutes later with 50+ questions in the queue. Sort through them and pull out the 30 best when I have the time. That's the real anti-hallucinations pipeline.
Very similar experience. The review UI might actually be the most important part of the whole pipeline. Does the confidence ranking match what you end up rejecting?
It's a future evaluation for me, as I'm keeping the app with a "Data Not Collected" App Store label for now. Once I have some visibility to stats of how people answer each question and at which confidence level I expect it to reveal bad/poorly worded questions that made it through my pipeline.
Also on my to do list is an upgrade similar to my de-duplication logic. Currently I pass in my approved set of questions as a list of topics and questions to avoid. It works well especially when combined with the more deterministic comparison of generated questions vs approved question by the separate model. The upgrade would be to pass in the questions REJECTED by me. These are question which made it through ever automated gauntlet of models and code, yet still ultimately were sent to the waste bin by human review.
I'm imagining that by including the list of examples of what NOT to do, it could inform the initial Generation to be smarter. I currently have a limited list of a hand picked "bad question shapes" where I provide the question and why its bad kept statically in my prompt. But I've realized sorting through thousands of questions, I've probably built implicit data through rejection that I may not actually recognize myself which the model may pick up on.
Simply starting in the right part of the search space is the biggest predictor of success.
The best way to save tokens is to start out the deep research pass with cheap models and then funnel the findings through increasingly powerful models. I've got a pipeline right now that uses all 3 of the gpt-5.6 model variants to address each stage of the process. If you are using models like sol or terra to generate hypotheticals and perform initial exploration, you are leaving money on the table.
5 hypotheticals out of luna will massively outperform 1 hypothetical out of sol, but the cost is the same and so is the runtime if you do it in parallel. The hypothesis generation phase is also a great place to mix and match models from different vendors. The more diversity at this step the better.
The other thing I started looking into is batch pricing which represents 50% off for OAI tokens right now. With some tweaks to the UI/UX of an enterprise chatbot, I think it is possible we could have users get comfortable with the idea that questions to the robot might take a day to come back. The key is that this has to actually work. Users don't mind trading time if their questions come back with high quality results.
This only works well if you are creating sub agents with clean contexts for each task. If you constantly are switching models part way through some work then the whole session needs to be replayed each switch. You lose all the benefits of the context cache.
Currently. I'm sure that you could make a system where the cache values are a superset C of e.g. models A and B where C is probably bigger than max(A,B) but smaller than A+B
definitely something that will come sooner than later. In my view, adaption of model routing / model orchestration and mixing providers is just natural next step.
Yeah, I do this as well. Some of the last large tools I built have been started with Gemini (I get it with my Google package), and even one with Copilot.
I am not a proper developer and only use AI for faster research of topics so please forgive my ignorance. Could one not save a lot of money on tokens by using the 80/20 or 90/10 rule in that 90% of AI usage is on local models and save that last 10% or less for the frontier models where the local model did not meet the needs? Did they cover this and I misunderstood?
Unlees you invest thousands your local ai won't even come close to the cheap cloud llms. Local is only worth it if you care about privacy or have a legitimate usage for the hardware otherwise. Money wise it isn't worth it
I think you bring up a good point about privacy. Companies probably should not be handing over intellectual property to cloud AI third party vendors. Perhaps all of that should stay on-prem and then the cloud vendors could be used to fill in the gaps.
Enterprises running in public clouds have Zero Data Retention policies with the vendor. Routing the ai spend through Azure or AWS usually bring these policies along with it, ie enterprise data and useage is not ingested to retrain the model.
I think the idea or methodology is something along the line of one starts with the local models then when they hit a wall then continue with their current results in a frontier model, thus the other half is those last bits one could not compute locally.
If you are only using chatbots for code gen then for sure this is a reasonable approach. If you're trying to learn something then your best bet is to not have the lowest jpg quality version of human knowledge be your teacher.
We could probably get the same results by offloading 20% of obviously smaller / simpler / well defined tasks to smaller models and keep the 80% for ones that benefit from the big iron. Not the 80/20 they were referring to, but still it's something.
I find myself wasting time on smaller models or wasting money on frontier models. I only have so much of either.
I suppose I was thinking in terms of companies that already had a slew of hardware and are just missing external GPU's, FPGA's or whatever people are using these days. A company might have a $50MM budget for tokens but could save a chunk of that using their existing hardware with some modifications.
Maybe that makes sense if the company already bought the hardware.
But I currently think the fundamental reason the cloud models often make more sense is based in how the models work. My current understanding is that once these models are loaded into GPU memory, the model can respond to multiple prompts in parallel. So a cloud vendor that receives lots of user prompts at the same time can achieve really good hardware utilization. These cloud vendors can then spread the cost of the hardware over many more users than you can with a local model, leading to lower prices per prompt in the cloud.
If you are an individual, almost certainly, unless you are using LLMs very heavily.
If you are a business employing many people all of who use LLMs reasonably heavily? You can still spread the hardware cost over many users and respond to multiple prompts in parallel. At some point buying the hardware will make sense.
I would not get a dedicated server to run a single small VPS. On the other hand if I needed a lot of capacity a dedi is cheaper than a big VPS (or lots of small ones).
There is also a benefit for anyone who has confidential or secret information.
That can work, especially for privacy or repetitive tasks. My experiment focused on subscriptions I already had, but local models are a natural addition to the routing layer.
1. Use less subagents. The act of using subagent already needs dumping adequate amount of context for subagent to work effectively
2. Refactor when file grows large. Reasonably scoped files is easier to understand, for both human and agents, and consume less tokens because less guessing which section of the file to read
3. More capable models for planning, learning. Cheap models for execution. Same for human teams, senior member for higher level planning while junior member more on the act of translation of idea into code
4. I wasn't doing any fancy stuff that opus can't handle
5. Consult a second opinion for things you are not sure. (I have made a skill specifically for that)
6. Audit how your habit correlates with token consumption. I found out a skill a use frequently is using a lot of context just so a subagent can get all the context. (made a tool to audit claude specifically)
I didn't update it for a while. It reads your local conversation history, correlate input/output token with usage (claude doesn't give exact breakdown), and classify if they are subagent/tooluse/normal message/whatever. Let me know if I can make it any way useful to you.
You should consider testing our RemembrallMCP (note I'm the author). It substantially cuts token usage and you get better results in codebases.
https://github.com/roboticforce/remembrallmcp
Many of us were saying it a year ago but now with model restrictions (e.g. fable) and pricing changes it should be obvious to people that part of the economics is avoiding vendor lock-in with evals (so you can easily switch providers/models/optimize) and increasing control by investing in local models which could be good enough for your tasks, at whatever the price for your cloud compute is. Eventually consumer hardware will also be able to run good enough.
You can use Big/Cloud LLMs to help you "find good enough configs" for your local/small llms [1] and stay quite nimble in the face of rapid change.
What a great confirmation of what I've tried to achieve by getting models to communicate with my local data in shorter communicates to save on token command bandwidth, more or less the same results! Thanks for the article!
I get a lot of satisfaction using a significant chunk of my work-provided Claude plan researching and developing local LLM solutions for work.
Claude has been helping me tune models to run better on our big compute rack at work, researching which leading edge open models will fit in hardware and are good for our workloads, and it's been helping me write test fixtures to evaluate how things perform.
At several points, Claude has expressed surprise at the quality of results from my local LLMs. While I know that doesn't mean anything, it still feels like giving Anthropic the finger, which is always great.
The author touches on an issue which bothered me, which was the thought of many agents re-solving the same issues over and over. I see a few comments here too, mentioning fixing issues which may already have a solution elsewhere. That was why I created https://pushrealm.com which started as essentially a Stackoverflow clone via MCP.
It has now become a way for agents to converge on complete, shared answers for emerging issues. As a side effect, through posting open issues we can also identify gaps in model knowledge.
The fun part of LLMs and internet research is that even if you have a URL and a quote from a primary source that primary source could be an LLM generated hallucination.
I stopped using any of the built-in skills and skills agents and tried to keep things in the model only, and that seems to work better for token usage for me. It took me some time to tune my skills .md, but it rocks on now. I use them all in both Claude-code and Codex. I will say, GPT is better on token usage than Claude is, but for some of my code bases, Codex is not as good, but seems to be getting better with 5.6-sol.
Try to mix both subscribtions and take the best from both providers. In my opinion, we should not just one over another but understand the power of both and mix them to reach the better results.
The reason most people burn through their allocated limits is mostly because of sub-agents. Stop using them and you will find out that even the Pro tier is enough for daily 8-12h coding sessions. Don't use Fable though.
I think this is almost a tautology, to the point that I'm surprised more people don't realize it.
If you ask the AI to do more work, it uses more tokens. If you do more of the work instead, fewer tokens are used.
I've been looking at Matt Pocock's skills recently, and they're very useful. But they use tokens. You can do that work yourself without the token usage, and just have the AI do the coding, or you can tell the AI to do everything and pay the cost.
And you can scale it down even further, and reduce the AI to a glorified code completion tool, and use way fewer tokens. But it's not going to speed up your work nearly as much.
For now, finding the right balance is important. In the future, I think things will eventually shift to the point that we just hand most of it to the AI and let it go without worrying about tokens.
I don’t think subagents are the problem. Uncontrolled fan-out is. Separate contexts and independent analysis are extremely useful for larger tasks. In my experience, Pro is far too limited for sustained programming, although that probably depends a lot on the kind of engineering work you do.
Fable is great, but overkill for most tasks. Sonnet and Opus are already good enough for the execution work. I find Fable much more useful for planning, orchestration, advising, and judgment.
I am not sure. I think of myself as a pro user yet I am finding hard time maxing out Pro tier. It only happens with sub-agents without any material returns.
It is Polish so please translate. But tldr is: ask your agent at times to analyze last chats and update rules and skills to not repeat the same steps it repeats every time when you start a new thread. Simple as that.
At the shell level, the agent does not need to know about Bash. The contents of "$OUT" are passed to echo as one argument, then sent to claude-mem-save over stdin. Bash does not re-evaluate them as shell code. printf '%s\n' "$OUT" would be more robust than echo. Whether claude-mem-save can use arbitrary output is a separate question.
the endgame of this optimization loop is an AI that spends /usr/bin/bash by doing nothing, which is also the most accurate description of my deployment strategy
LLMs only have 'knowledge' that was encoded by scanning as much data as possible. (Same way a search engine only can find data that was indexed)
American LLMs are by and large closed. Chinese are open to a point. And research how these things work is still a big mystery.
So yeah, was comprehensive data about saving tokens scanned and indexed? Likely no. So engaging about token saving is going to generate a lot of verbose and useless slop.
Yeah, that was pretty much my experience. The models weren’t lacking knowledge as much as discipline. Without a good workflow, they will most likely spend thousands of tokens exploring dead ends.
I think 'exploring the dead ends' is *possibly* very fruitful. Various disciplines have a lot of appearing dead ends that someone in another field did solve. And they don't talk with each other.
What I've seen with lots of the breathless 'OMG SCIENCE ADVANCEMENT' articles including the one yesterday, is that the LLMs are quite extraordinary about linking a dozen different fields together, and delivering an answer combined from all of them. Basically, the solutions to a lot of current scientific problems are partially solved, but partial from a lot of fields that don't talk with each other. And also, they don't use the same nomenclature, so simple searches don't suffice.
An LLM seems to use Chomsky's Universal Grammar, and thus on training, does normalize all training data, including different words for the same thing.
A lot (perhaps all?) Of these BIG scientific advancements were solved by humans, partially. An LLM jigsawed them together and appeared it solved the thing.
What most AI model users don't understand is (most here will know) that they are probabilistic (statistically based) and not deterministic (static/fixed).
So answers to the same prompts can vary (wildly sometimes)
This really hit home yesterday as I made a general conversation state logging prompt (because suddenly Claude - Sonnet - was acting far more dumber than expected after /compact), and in 3 different projects it led to Claude saving the logs in 3 different locations (memory, .claude/session_state/.md, docs/.md). Somehow still didn't help increase the smart much BTW, so I'll probably have to engineer it, and just toss /compact out the window.
Honestly, that sounds more like you triggered the hidden "guard rails" or realignment (aka corporate censorship), and you got downgraded.
Of course, you have no way to he absolutely sure, cause Anthropic lies about silent downgrades, and charges you as if they didnt. And the 'realignment' rules are kept hidden, so you can't even avoid them intentionally.
Yeah it's very possible I hit a rail, as one of the projects involves fully automating Claude Code to allow co-driving (similar to what mobile remote control offers, but other agents (eg. Pi) can also be in control, and vice versa). And yes it does seem as though the token burn is also higher, even though it eventually outputs something that works). I'm a patient person though, as long as the rails aren't too restrictive and the subscription value remains reasonable.
Id recommend getting and running Qwen-3.5-35B-abliterated locally.
Having a local LLM is immensely helpful especially if you do the thing the companies disapprove of. Abliteration guarantees it wont refuse or censor.
The token dealers are incentivised in burning as much tokens as possible, and scamming by crippling/downgrading models. Their goal is to get you to pay more for each pull of the slot machine. And this slot (slop) machine doesn't have state/federal regulations for fairness.
I don't think you made that. It looks for sure like an LLM made it.
And now that you have typed some words into a chat box to produce a thing, you are confused about why other people won't pay money to you for the output of the chatbox, instead of typing the same thing into their own chat boxes.
Been through this exact loop building an LLM product. The counterintuitive lesson for me: most "token saving" ideas are cache killers — anything that makes the prompt prefix dynamic (rotating retrieval, appending context per turn) can cost more than the tokens it saves, because you lose the cached-prefix discount. Freezing the retrieval selection early in a conversation and paying a slightly larger fixed prefix beat every clever adaptive scheme I measured.
Yes, but you could have an uncached dynamic tail, this would not kill the cache though. And you could still periodically kill the cache, still keeping the same prefix every N requests. But it's questionable what all this extra complexity delivers.
I found that now that the models are better, at least Codex compaction with GPT 5.5+ xhigh is almost unnoticible. So the answer is: just let the context fill up, don't prune much, the model is smart enough. When you're out of space, have the model summarize and continue from that point. A smart model will know the information pieces it needs to re-read after compaction; it won't make incorrect guessed when some details got lost.
That's what I have been doing with Cursor with auto mode. Let the model manage the cache through compaction but staying focused on the topic. It has been quite efficient cost wise and quality wise too. It found issuesbat cheaper cost that Sonnet 4.6 medium effort had missed while costing more. I would like to repeat this test with higher tier Anthropic models like Opus effort medium to see the results.
With a coding plan, there is no need to use lower quality models right (GPT 5.6, Fable 5). Only with some kind of batch job (processing PDFs) I could imagine not having enough usage with a 100 or 200 USD coding plan. It sounds like you're on API? I'm dying to know why, since it seems quite common, yet it's about ten times the cost. Sounds like a terrible deal. What am I missing?
What I said was specific to work and it is not entirely clear to me why the cost goes up so much the moment I switch to medium with just Sonnet 4.6 (newer models would be even more I guess). There is a monetary budget allocated and I've blown it easily in the past with Claude. Cursor has been a life saver.
I have a process generating trivia questions for my app and by passing in my existing dataset each time as a cached exclusion list, the output tokens it save more than pay for it.
