I only use opus 4.7 and am on the 100$/mo plan. I usually make sure the context does not grow beyond 30-40% of the 1m tokens. On heavy coding days where I do something pretty similar to this, I would occasionally run into the five hour limit, but that happens like once per week and then it wouldn't take too long to reset. Note that I use caveman, but I'm not sure to what extent that really helps.
Before the cloud, people were trying to reduce the mean time between failure (MTBF) essentially trying to prevent a thing from failing. With cloud, people are trying to recover as quickly as possible (mean time to recovery) accepting that things will fail —- it’s about how fast you can react to it.
Also note that even though you get a warning about an unknown config key, the value is actually set so you're future-proof. Check `grep telemetry ~/.config/gh/config.yml`
> As of 07:55 UTC, we are experiencing issues with the Dashboard, Express Dashboard on all platforms and Mobile surfaces. We’re continuing to investigate and will post further updates. API requests and payment processing are unaffected by this issue.
> Update - We're currently investigating issues with Claude Code and Claude.ai. Some users may be unable to log in, and others may experience slower than usual performance. The Claude API is not affected.
Shout out to Blogtrottr[1], which allows you to subscribe to RSS feeds and have the posts sent to you via email. Great service I've been using for years.
That's weird! It must be due to a history rewrite I did later on to clean up the repo, removing some files that weren't really part of the project. I didn't realize when I first started the experiment that we'd actually end up releasing the code so I had to go back and clean it up later. I am surprised though that this messed up the timestamps -- usually rebases retain timestamps. I think I used `git filter-branch`, though. Maybe that doesn't retain timestamps.
I know that `git rebase` changes the committer date while keeping the author date the same, so I'm assuming something similar happened here. For example, many of the early commits have this committer date with varying author dates:
$ git show --format=fuller 3dafc8f5de6ffe46fb223a75a46a6bd848b6daf8
commit 3dafc8f5de6ffe46fb223a75a46a6bd848b6daf8
Author: Kenton Varda <kenton@cloudflare.com>
AuthorDate: Thu Feb 27 17:15:37 2025 -0600
Commit: Kenton Varda <kenton@cloudflare.com>
CommitDate: Tue Mar 4 14:48:59 2025 -0600
Add storage schema by Claude.
GitHub uses the committer date for its history, which is annoying if you rebase frequently; I like to run a non-interactive `git rebase` with `--commmiter-date-is-author-date` in such cases.
This is great advice. Unfortunately, all these AI tools make it far too easy for beginners to not follow it. I'm not sure if all this advice will become irrelevant or if those programmers trained in the 2020ies will not become those "best"..
Everything comes in cycles I think. There will be a wave of AI generated stuff, but then people / companies will be hit hard by bugs and problems and will reinvent the wheel of quality assurance.
I wonder if AI generated stuff would pass our existing checks, e.g. linters, test coverage, sonar, etc.
> I'm not sure if all this advice will become irrelevant or if those programmers trained in the 2020ies will not become those "best"..
It's how they use the AI. If they see it as a glorified StackOverflow where you paste a big chunk of code and ask "why does it not work", they'll be in trouble. If they are able to narrow-down their problems to a specific context, express them well and take the output of the AI with a grain of salt, they'll be 10x programmers compared to what we were in the 2000s, for example.
You could argue that a "feature" of Stack Overflow is the culture. They're building a reference, not a help desk, so they expect questions to be original and researched. Once you're in a corporate environment, if you don't have experience in asking good questions, you'll come off as incompetent.
I dunno, do they really make it that easy? From what I've seen they can give you some example code, and often it works, but when it doesn't, you actually need to know what you're doing to fix it up.
Fixing someone else's code is a great exercise, so maybe they're actually learning useful skills by accident? :)
I understand the power of flash cards and SRS in general. But was wondering how you decide when to put something into an SRS when learning something new. Especially in a tech/programming context.
reply