Henrik Söderlund retweeted
Herdr UI just got a lot bigger 🐏
- Signed Windows installers + in-app updates.
- A new activity bar.
- Cross-project PRs and issues.
- Azure devices.
- Deeper WSL support.
Here’s the release in two minutes.
full article: xitter.cf/fabienpenso/status/211…
Last night I realised $200 of Claude API credit was expiring in about 8 hours.
By morning I had 72 issues filed across 4 of my repos, every one checked by a second agent. It cost $178, none of it my own money.
Max 5x gets $100 a month, Max 20x $200, Team up to $500. Here's the prompt to find what yours could do:
gist.github.com/henkisdabro/…
Henrik Söderlund retweeted
My Productivity Strategy to Reset, Get Unstuck, and Focus on the Right Things
Henrik Söderlund retweeted
Herdr GPUI just got a lot bigger, so many features and fixes I need a thread as it does not fit this tweet 🧵
Henrik Söderlund retweeted
Finished my ClaudeCut experiment.
I wanted to see how much of a $20 Claude subscription actually goes into the work, and how much gets eaten by Claude Code itself.
I cut it down to one terminal tool, a 36-token system prompt, and a capped context window. Startup dropped from 17.6k tokens to 895.
Then I tested both setups on the same repo. One task was about understanding the project structure and entry points. The other was a code-search task: trace where config gets loaded, find the exact line, and explain the failure cases. Three runs per task.
ClaudeCut came out at roughly half the cost in Claude Code’s own usage report, with comparable answers. On the search-heavy task it even used fewer turns.
I also pushed both setups through long sessions with repeated compaction. ClaudeCut came back at around 14k tokens after compaction vs ~36k for stock Claude Code.
This is still not a final benchmark. There aren’t enough repeats yet and the long runs need to be tested several more times, but I’m pretty much at the limit of what I can test on a $20 plan, so I opened the repo. If you use Claude Code, run it on your own project and send me the results.
People in the replies pointed me toward Pi + Claude Agent SDK, where you get much more control over tools, prompts and compaction. That’s what I want to test next against ClaudeCut.
Setup instructions, benchmarks and methodology are here: github.com/alexgetmancom/cla…
I castrated Claude Code.
Ripped almost everything out and left only the bare minimum: read, inspect, write.
Startup context is now under 2k tokens.
I also capped the context window at 200k tokens so it compacts earlier instead of chewing through my limits with bloated context.
Basically pushed Claude Code much closer to Pi’s minimal approach.
This is all on the $20 Claude Pro plan, running Opus 5 on low effort. For me, that’s the only setup that makes sense for actual work.
Now I want to see how far I can stretch a $20 subscription like this.
I’ll report back. If you’re interested in the experiment, let me know.
Here's a token-saving tip for longer Claude Code sessions - stepping away for lunch/breaks etc.
On a Claude plan, session cache is 1h (API/SDK 5m). After idling out, your entire convo is charged in full.
Use:
/loop 55m send ''bump" to the chat
...and cache will stay warm!
Henrik Söderlund retweeted
Reminder that I don't think you should run agents on a Mac unless you absolutely have to. It will slow you down massively and is not worth it.
Henrik Söderlund retweeted
PSA: Don't forget that you only have another 2 days to claim this $250 credit for each of your Claude Max 20x subscription accounts.
If you have a bunch of accounts and don't log into the web app very often other than to swap accounts in Claude Code, it's easy to miss this.
You need to connect it to your GitHub account, which is very quick and easy if you're already logged into GitHub in the same browser. Then you just start a session, pick one of your repos, and give it a prompt to claim the credit.
If you're like me and don't even want to have to think much about this but want to make sure you get reasonably good utility out of your $250 credits, you can try this generic prompt that I've been using, shown below (adapted from a similar prompt I use with GPT Pro in the web app with the GitHub connector).
You can adapt it accordingly if you don't use beads or have a comprehensive plan document in the repo:
(also, another PSA: they gave everyone one banked reset per account that expires Oct 22 if you don't click the button in the "Usage" section in settings in the web app. But wait until you actually hit your weekly limit before clicking it, then do it right after that. Don't waste this potentially valuable reset!).
---
I have this now… can you work on it for me? Read the comprehensive plan and look at the beads first. Figure out the most momentous and critically important remaining gaps in features and functionality and focus on getting as much done of those things as possible in this session—not on minutiae or process/ceremony related tasks!!
Use GitHub to commit your changes directly to main (no PRs!!!!). Commit relatively frequently: don’t wait to do one big commit at the end, it’s too risky. But don’t commit absolutely trivial, tiny changes separately: wait until you have a meaningful commit.
And just keep going, being as useful as possible. Again, don’t focus on minutiae, focus on implementing the most critically important parts of the system that are incomplete! And commit directly to main using GitHub (I know for a fact that this works, just be persistent!).
Henrik Söderlund retweeted
we merged 4x more commits last week than we did a month ago (thanks opus 5.5). our dev setup and CI couldn't keep up, so we reworked both:
• lint: 4x faster
• memory per agent session: half
• CI setup step: 50x faster
• CI type check: 10x faster
we often run 10+ agents at once locally, and each one runs its own lint, type checks and tests.
from time to time, several agents would run these at the same time and block each other.
a 64 GB MBP would run out of memory and crash. so most of the work was making things faster and lighter, or getting rid of them
we revamped our local setup to make checks faster and use less memory:
• oxlint and oxfmt instead of eslint and prettier, and type-aware lint only runs in CI. linting a changed file went from over 10s to a few seconds
• a hook formats every file an agent edits, so agents don't have to take a turn to format it
• typescript 7's native LSP instead of tsserver. each agent session uses about half the memory
• agents run one check script after each change. it installs missing packages and env files first, then lints, type-checks and runs the tests for what changed
• only 3 type checks or big test runs can run at once across all worktrees, so they don't slow each other down
we revamped our CI to make it faster:
• every CI job installs pnpm before it can install our packages. the standard github action for this (pnpm/action-setup) installs pnpm through npm, and that hung for 3-7 min on most of our test jobs. we now download the pnpm binary from github releases, which takes about 4s
• our type check needs about 9.5 GB of memory. github's standard runners have 8 GB, so it ran out of memory and took 206s. on a 16 GB machine it takes 20s
• vercel builds type-check with typescript 7 (85s to 45s), and previews only build for PRs that change the database
if you're running lots of agents, look at what they're waiting on. for us it was mostly lint, type checks and CI setup
Henrik Söderlund retweeted
So I found you can instantly ~2x* your GitHub CI speed for free
GH added parallel actions.
But AI usually misses it since it's too new 😱
* Depends on what you're doing, just ask AI to benchmark
github.blog/changelog/2026-0…
this excellent post, combined with the skill (github.com/starslingdev/skil…) from a commenter @yonasbe gave me an incredible reduction in wall clock time on my github actions workflows as well as local test/build times. Thanks for the post - highly recommended!
we merged 4x more commits last week than we did a month ago (thanks opus 5.5). our dev setup and CI couldn't keep up, so we reworked both:
• lint: 4x faster
• memory per agent session: half
• CI setup step: 50x faster
• CI type check: 10x faster
we often run 10+ agents at once locally, and each one runs its own lint, type checks and tests.
from time to time, several agents would run these at the same time and block each other.
a 64 GB MBP would run out of memory and crash. so most of the work was making things faster and lighter, or getting rid of them
we revamped our local setup to make checks faster and use less memory:
• oxlint and oxfmt instead of eslint and prettier, and type-aware lint only runs in CI. linting a changed file went from over 10s to a few seconds
• a hook formats every file an agent edits, so agents don't have to take a turn to format it
• typescript 7's native LSP instead of tsserver. each agent session uses about half the memory
• agents run one check script after each change. it installs missing packages and env files first, then lints, type-checks and runs the tests for what changed
• only 3 type checks or big test runs can run at once across all worktrees, so they don't slow each other down
we revamped our CI to make it faster:
• every CI job installs pnpm before it can install our packages. the standard github action for this (pnpm/action-setup) installs pnpm through npm, and that hung for 3-7 min on most of our test jobs. we now download the pnpm binary from github releases, which takes about 4s
• our type check needs about 9.5 GB of memory. github's standard runners have 8 GB, so it ran out of memory and took 206s. on a 16 GB machine it takes 20s
• vercel builds type-check with typescript 7 (85s to 45s), and previews only build for PRs that change the database
if you're running lots of agents, look at what they're waiting on. for us it was mostly lint, type checks and CI setup
Given how important it is to write sharp, precise instructions for AI agents (behold the brevity of @mattpocockuk's skill bodies), one might assume literary masters like John McPhee would get incredible agentic results. Back to basics!
My agentic coding stack for macOS: Ghostty, @herdrdev + Herdr GPUI (from @fabienpenso), Codex, Claude Max, Openrouter, OpenCode, Sandcastle-kit, Docker, GitHub Actions, pnpm and uv and remote machines for AFK workloads
What’s in yours? Keen to hear which tools make the biggest difference, what you’ve dropped, and what I should try next.
henkisdabro.github.io/sandca…
Wow, @mattpocockuk is so back
Ran Matt's new /retro on a week of my Claude Code sessions. It found:
- main's CI red for a day and a half, 11 pushes, and no agent checked it after merging
- a lint job that can't fail cuz it auto-fixes in CI and throws the fixes away
- 649 inline python3 scripts to edit files instead of the Edit tool, wtf
- 29 calls blocked by auto mode, including read-only prod reads
This will help turn wishy-washy, loosely-followed agent instructions into deterministic checks that fail the build
Observation: Claude Sonnet 5.5 on low effort gets the (most of the) task done but skips the process steps in my prompts, such as "write the test first, run checks one at a time, verify before moving on".
Fine for quick edits, but I wouldn't trust it where tests or evals matter.
Anyone else seeing this?
Henrik Söderlund retweeted
Super excited to be interviewing @poteto, live, in ~48 hours on YouTube.
We'll be nerding out about skills, high-velocity software factories, and learning SOTA techniques for shipping with agents.
This Friday - 9AM PT. Don't miss it!
youtube.com/live/MN9dGgmLyso
Wookstar Claude Code plugins 7.0.0 is out - a full refresh of a marketplace I'd left alone too long.
Every skill re-checked against current Claude Code and live vendor docs, five new plugins, and the stale ones retired.
github.com/henkisdabro/wooks…
Some of my plugins are now worse than the official ones, so they're retired: codex (OpenAI ships one), Notion, Cloudflare, docx/xlsx.
Retired plugins ship one last version that just tells you what to install instead.
Upgrading from 6.x is one command:
curl -fsSL raw.githubusercontent.com/he… | bash
It updates what you keep, swaps the retired ones and moves your API keys into Claude Code's keychain-backed config.





















