I've long speculated this when I see these types of comments, because it's actually really difficult to hit usage caps with an efficient dev flow, even when running multiple threads for hours every day.
I think some combination of:
1) Using 1 thread for everything
2) Reviving old threads which are no longer in cache
3) Really broad prompts on badly vibecoded codebases, so model spends huge amount of time tracking down whatever you're trying to do.
4) Non-coding workflow which is more output than input heavy
5) (Less likely IMO) Intelligent use of many passive CI/cron-like scans. E.g. regular security, quality etc scans. Automated issue resolution/PR
Just a guess. I think 3 is likely the primary reason.
You can literally go all day every day with multiple threads with Sol on the Codex 100/month plan IME
That's my experience too. I've found OpenAI really quite generous with tokens. I sometimes wonder how some people manage to run out of them really. Do they just type prompts that much faster than me or use the highest reasoning mode for everything just because they can? Idk.
I generally agree with those reasons, although using a single thread may be less of an issue than it seems because of context compacting which should happen automatically when you're near the limit.
My use cases are iterative and sometimes require reading a lot of code or reevaluating work.
Token efficiency is near meaningless when the workload is input-heavy. It can't always just choose to read less, depending on the task.
I can have cheaper agents do the reading but it's not appropriate for all use cases because they'll misjudge and choose the wrong things to emphasize, summarize, extract for the bigger model.
The problem is also that at a lot of code bases are not designed around LLMs and their token usage.
If you have a monolete codebase, you need to clearly define in the prompt what modules are involved. And even then, your wasting tokens with the first 1 or 2 steps where it needs to located the modules.
if you have a github codebase, with a lot of your code into nice little repos, its even worse because then the model needs to pull data, and a ton of more steps.
Most people do not open their coding agents in the module directories because "it may need something out of it".
I mean, we used to program by creating utils directories to deal with repetitive code but models (a) find it and use it (but it cost steps and tokens to read), (b) do not realize it there and make their own version of whatever or (c) combination of both.
And ironically, i feel like we need to give up on this idea of reusable code, and literally keep things into single modules, with as minimum external dependencies. That in return reduces searches and thus steps/tokens burn. But very few agents / harnesses have proper implementation of groups/projects and sub-module structures. Aka they only open a single dir, so your then forced to create dozens of tabs > per dir > cli ...
2. That is also a issue if you open multiple agents. Maybe now your working in A, B but C, D, E are not doing anything. And their cache expires... Now you go back to D because A, B needed to be done, and now your paying Cache Write + Input cost.
Its hard to have a good flow to keep things cached, when to really /new and when to not have it expire (and that assumes there are no issue with the provider moving your session around and forcing new cache hits. MiMo did that a lot in the past).
Something that i also advice more and more to people. Get a microphone, download openwisper and talk (text to prompt). You tend to give more information vocally, then writing as its in our habit of programming to not be verbose. Its like people are afraid of long prompts. While just talking to the LLM tend to give it much more information to work with, often resulting it being able to skip steps.
I was on the Anthropic train for 2 years, and I tended not to jump between vendors much because it felt like a lot of distraction for little gain. But last week I switched to 5.6 Sol during an Anthropic outage and it made me realize how frustrated I was with Opus 5 and I haven't switched back.
In a world where code can be generated rapidly, it's super critical that you have a core few set of people who really understand the macro design of the codebase and can continue to factor it well and iterate quickly.
Adding more people and contributors just increases the probability that nobody really understands the structure of the codebase, it degrades into DRY and unfactored slop.
The cost of reviewing other people's code is almost too high to be worthwhile now... It's much easier to just cut them out and do it yourself.
A core set of very skilled people can just implement whatever change you are doing, but better, cleaner and faster.
I built a fairly large and complex project with Codex and had to spend about 50% of the time factoring things down as I went into well contained modules, had a full understanding of the architecture at a high level. It would have been pretty difficult to do this if bringing in other contributors.
Too many people comment about AI from the perspective of throwing feature A or B over the wall at the workplace, but anybody who has built a huge project from scratch will see how important good design is in regard to iteration speed and result quality.
That being said, there are still areas where changes should be sized reasonably and human reviewed e.g. foundational or very mature software
That makes sense from an engineering perspective, but from a business perspective you don't want the understanding to live in the heads of a small team of people. Companies own the codebase, they don't own their employees. If losing a single employee means losing the understanding for a significant chunk of the codebase, that's a serious risk. With the senior/junior model where you have a senior engineer architecting the system and a small team implementing that architecture, the understanding lives in the senior engineer's head, but it also lives in the head of the person who implemented it, and their teammates who implemented the parts that interact with it and were present for the discussions probably have enough knowledge to figure it out pretty quickly, so as long as the company doesn't lose the whole team all at once they're okay. If you make the team more productive with AI tools you can have the team do more, which still cuts down the total headcount, if to a lesser degree, but preserves the redundant understanding.
It's not all inflation expectations, either. The dollar has been strong lately due to elevated oil prices---countries that are short need extra dollars to buy oil, so they often liquidate treasuries to get them.
Additionally recent studies have shown high duration/volumes of cardio increases plaque buildup in the arteries.
"Indeed, many studies have shown a relationship between endurance sports and higher volumes of coronary calcified plaque as determined by computed tomography."
I guarantee you that HITT with stupid movements is also not good for you. And you can over train HITT. Source: all the people I used to do CrossFit with that got injured or washed out from over doing it.
As always the answer is to listen to your body and don’t over do it. Running marathons is fine. HITT is fine. Lifting weights is fine. In moderation at an intensity suitable to the individual.
Yes, if you set reasoning to none you can force the granularity of the thinking.
It will actually adhere to your request for e.g. 3 sentences max.
Thinking mode will override any instructions in the prompt (at least for other models in my experience).
Of course this will probably hurt performance, but works great for easy tasks that you know are trivial. Tons of pipeline, image recognition etc use cases where this works well.
I'd be curious to see Qwen 3.8 27B low thinking benchmarks though.
There are tons of core principles that can be learned that largely apply across fields.
One prime example, single source of truth for data/concepts. To be violated only when performance is meaningfully improved (denormalized databases). But when you do so, you should definitely recognize you're opening up out of sync issues for that performance gain.
Though for the majority of code, there is no performance benefit to adding multiple sources of truth. Yet it's the most common error I see re: quality.
The sad thing is that software engineering fundamentals and best practices never became widespread or widely taught in school prior to LLMs
Not sure I follow the logic here, but happy to be proven wrong if I'm misunderstanding. It's not intuitive to me that a 300 lb. person at 20% body fat is generally at the same risk as a 200 lb. person at 30% body fat.
Fat is inherently unhealthy for you beyond some low baseline level.
Additional muscle is positive for health, but only up to some reasonable threshold. There is no health benefit to having very high levels of muscle, and in fact it may be negative for your health at extreme levels. E.g. many bodybuilders have trouble breathing, sleep apnea etc.
Both people in the example have 60lbs of fat. 1lb of muscle doesn't cancel out the negative health effect of 1lb of fat
The nasty detail is that some people gain relatively more visceral fat than others. These three fats are correlated, but the correlation isn't the same in every human. Some have better metabolism and don't store as much fat inside as others do.
Looking for some references on these claims, thanks! What you're saying registers as "makes some sense, but where's the evidence?" to me. I'm not seeing the connection where total lbs of fat is inherently worse than higher percentage.
The mean height for men at 20-29 is 69.2" and 80+ is 67.1" (measured in 2015-2018, the last data I've found) [1], which could be interpreted as shorter people having lower risk of all mortality. One could say that people are just getting taller over time and 80+ y.o. were shorter at their 20-29, but we also have the median height for 20-29 fro 1970s, when 2018's 80+ were 20-29 - it's actually 69.7" [2], men in the US are getting shorter over time, so unless people naturally shrink 2" with age the data points to shorter people having lower risk of death.
"People typically lose almost one-half inch (about 1 centimeter) every 10 years after age 40. Height loss is even more rapid after age 70. You may lose a total of 1 to 3 inches (2.5 to 7.5 centimeters) in height as you age."
So people DO in fact tend to lose about 2 inches at age 80 versus their younger selves.
The actual studies [1],[2] that tried to measure this came to very different rates of height loss though: 3.6 cm and 6 cm from 40 to 80 in men. This does not look like a serious fact.
The difference was 3.6cm in the study that measured 10 more years 30-80. And 5cm in the study that measured 10 fewer years 40-80.
The studies were conducted over different time periods when average nutrition changed, and demographics changed. And the study demographics just vary by location.
Height loss with age is incredibly well documented. Here’s a few more studies.
This is just basic medical textbook information. No one in the world is arguing that this phenomenon doesn’t exist.
I am not saying that. I am saying that the theory about absolute amount of fat being bad for health, as stated by the comment you responded, seems to be supported by data.
> I asked about the specific claim that absolute fat was bad for your heart.
There is no word "heart" or any to this effect in the message you replied to so I did not understand that was what you were doing. I took your question as an attempt to attack the theory on the basis of prevalence of some heart conditions in shorter people.
Some are more common in short people and some are more common in tall people. Hypertension is one of the ones more common in short people and is significantly more common than the rest combined, so your overall chance of having some form of heart disease goes down as you get taller. However, the forms of cardiovascular disease more common in tall people (e.g. atrial fibrillation) are more likely to actually kill you.
Do you have a citation for that? I've had thoughts in a similar direction (specifically around the upper/lower intervention points) but have had no luck finding data.
I think some combination of:
1) Using 1 thread for everything
2) Reviving old threads which are no longer in cache
3) Really broad prompts on badly vibecoded codebases, so model spends huge amount of time tracking down whatever you're trying to do.
4) Non-coding workflow which is more output than input heavy
5) (Less likely IMO) Intelligent use of many passive CI/cron-like scans. E.g. regular security, quality etc scans. Automated issue resolution/PR
Just a guess. I think 3 is likely the primary reason.
You can literally go all day every day with multiple threads with Sol on the Codex 100/month plan IME
reply