Really useful read!
6 months ago a few people [https://news.ycombinator.com/item?id=44940089] agreed that LLMs are very good at translating Pseudo-code to real code. I agree. Also, writing pseudo code somewhat makes me feel a similar state of flow. Maybe even more, because no compiler/interpreter annoys me about syntax issues. Now, I built this:https://github.com/HalfEmptyDrum/Pseudo-Code-FlowIt is basically a...
npm install -g press-one
press-one --delay 3000 claude "fix all the bugs"
Known "features": a slow stream of 11111 appears while the model is thinking, and you can't type because stdin belongs to the machine now. Zero dependencies (just Node + Python for PTY allocation). MIT licensed.https://github.com/HalfEmptyDrum/Context-Compactor
agents. Not a custom truncation strategy, not a sliding window, not dropping old messages and hoping for the best. The failure mode is well-understood: your context window fills up, you truncate from the top, and the agent loses the thread. It forgets the task it was working on, the file path it just wrote to, the UUID it needs to reference. The conversation breaks. The problem is everyone...
https://github.com/HalfEmptyDrum/Key-Carousel
I think in-process key management is the right abstraction for multi-key LLM setups. Not LiteLLM, not a Redis queue, not a custom load balancer.The failure modes are well-understood: a key gets rate-limited, you wait, you try the next one. Billing errors need a longer cooldown than rate limits. This is not a distributed systems problem — it's a state machine that fits in a library. The problem...