My (and many others) normal workflow includes a planning phase, followed by an implementation phase. For me the most useful time for fast mode would be during that planning phase.
The current "clear context and execute plan" would be great to be joined by a, "clear context, switch to regular speed mode, and execute plan".
I even think I would not require fast mode for the explore agents etc - they have so much to do that I accept that takes a while. being able to rapidly iterate on the plan before setting it going would make it easier.
Only in the same way that the pixels displayed in a browser are not a tree structure that you can diff - the diffing happens at a higher level of abstraction than what's rendered.
Diffing and only updating the parts of the TUI which have changed does make sense if you consider the alternative is to rewrite the entire screen every "frame". There are other ways to abstract this, e.g. a library like tqmd for python may well have a significantly more simple abstraction than a tree for storing what it's going to update next for the progress bar widget than claude, but it also provides a much more simple interface.
To me it seems more fair game to attack it for being written in JS than for using a particular "rendering" technique to minimise updates sent to the terminal.
Most UI library store states in tree of components. And if you’re creating a custom widget, they will give you a 2D context for the drawing operations. Using react makes sense in those cases because what you’re diffing is state, then the UI library will render as usual, which will usually be done via compositing.
The terminal does not have a render phase (or an update state phase). You either refresh the whole screen (flickering) or control where to update manually (custom engine, may flicker locally). But any updates are sequential (moving the cursor and then sending what to be displayed), not at once like 2D pixel rendering does.
So most TUI only updates when there’s an event to do so or at a frequency much lower than 60fps. This is why top and htop have a setting for that. And why other TUI software propose a keybind to refresh and reset their rendering engines.
I spent a whole day running 3x local CC sessions and about 7 Claude code web sessions over the day. This was the most heavy usage day ever for me, about 30 pull requests created and merged over 3 projects.
I got a lot done, but my brain was fried after that. Like wired but totally exhausted.
Has anyone else experienced this and did you find strategies to help (or find that it gets easier)?
I have formal requirements for all implemented code. This is all on relatively greenfield solo developed codebases with tools I know inside out (Django, click based cli etc) so yes. Thanks so much for your concern, internet person!
Hardian Health | Senior Product Engineer | REMOTE (UK only) | Full time flexible, 1 (initial) year contract
We're building a regulatory intelligence platform for AI in healthcare. In effect a specialist dataset + search engine for that information. Currently working to get from a Beta to production ready. This is a Full-stack role, working alongside CTO.
Stack: Python, Node, React, GraphQL, PostgreSQL, Data scrapers
Fully remote with quarterly meetups. Flexible hours.
Must have UK work authorization (no visa sponsorship).
I was thinking that on this, folks need a cron task to run a trivial prompt at 5-6am and get that 5hr timer running so that it the majority of the quota is available in the working day morning, and then a new 5hr block starts around lunch time. This should maximise use of included tokens by a standard work day spanning 3 blocks rather than 2
Also useful for paid APIs like DeepSeek's, where they have cheaper inference price (50%/75% off) for UTC 16:30-00:30, so being able to schedule some stuff you know would take a ton of tokens for that time period would make sense.
I'm in a similar position of never having found a use where memorising lots of facts would be useful. The main use I keep seeing is vocabulary building when learning a language. I'm sure people are using the system for learning other stuff too though?
Seeing this did make me wonder how I might be able to get better at memorising important parts of iso/iec standards at work, but I can't see how that maps to flashcards
In what context do you find yourself wanting to recall a specific part of an iso/iec standard? Distill that context into a short description and put it on the question side of the flashcard. The answer side then has the corresponding information you want to memorize.
But of course it's possible that you almost never need the same information twice, in which case committing it to memory wouldn't be particularly useful.
I've built one for the US Amateur Radio exam pools (which are public) as I'm trying to sit for both my Technician and General in the same volunteer exam session.
Mixing the questions between both pools and studying as a unit I've found has had two great benefits: 1) I'm not focusing on Technician first and then going for General as a "bonus" and 2) it helps me see the connections between the material.
I have used Anki to memorize cube numbers and roots, recipes, and music theory. If you're interested in other ideas, you can browse public decks here: https://ankiweb.net/shared/decks.
I've been following 16hr fasts by skipping breakfast and eating my first meal at around 12:00 each day. Normally have an afternoon snack, then dinner at 18:00 with my young family. Perhaps a sweet treat by 20:00 after putting the little one to bed. Honestly, it's not that tricky if you bulk up lunch a bit.
Edit: As a sibling comment says quite rightly, you do feel hungry in the late morning, but reacting to that feeling is optional
I stopped feeling hungry in the morning a long time ago. Just unhealthy amounts of coffee, without sugar or milk. If I eat even just the tiniest snack or sweet, the food processing tract will "wake up" and it's over. But if I can avoid that, I only break the fast because of convention, not because of hunger.
But it's also very contexy sensitive: currently working from a place where I usually go for high calorie throughput sports (think Tour de France climbs, but higher and a heavier rider, obviously a lot slower but the energy demand is mostly mass x elevation, almost unpacked to speed) and my body is in "eat! you will need it!" mode every day. Crazy weight gain on the working days.
I came here to say the same as the parent comment - it's an amazing achievement, but you may well have built a medical device which needs certification in order to be on the market in the territories you want to use it in.
I work (freelance) with a consultancy [1] that helps specifically with software-as-a-medical-device (SaMD). My email is in my profile if you want to chat about what might be the best way forward.
I'm working on scoping out specific problems facing "software as a medical device" (SaMD) companies. In particular issues around being able to release software at a reasonable cadence. I've been a CTO in this space for a couple of years and I am now consulting with other firms around the intersection of tech and regulatory.
It's a tight-rope walk of ensuring that all testing (software and non-software testing) and evidence is produced correctly and being able to release at a rapid pace to derisk each release. It's not uncommon for software to only be updated yearly, leading to very conservative changes and little iteration. Monthly releases are okay, but still not great.
I want to make it possible to release at least weekly and to do so safely.
If you work in this area, I'd love to chat and hear your experiences (email available via my website in bio).
