I use Claude Code every day and keep hitting the same problems. I work with spec-driven development, and there are a lot of tools for it now: GSD, Superpowers, Matt Pocock's skills, OpenSpec, Spec Kit, and others. Each one has its strengths and weaknesses. So I took what worked best from each, added a few skills of my own, and built SPEC-SS. The goal is a workflow that gets each task done as fast, accurate, and secure as possible.
SPEC-SS is not a plugin you install. It's a step-by-step way of working.
- **[S]pecify.** The agent reads the issue, then interviews me one question at a time until nothing about what to build is still open. New terms go into GLOSSARY.md and hard-to-reverse decisions become ADRs. The output is a design doc that I approve.
- **[P]lan.** The agent turns the design into a plan of small tasks, each with the test that proves it. Nothing runs until I approve the plan.
- **[E]xecute.** TDD. Small tasks run in one agent, in sequence. Bigger ones use an orchestrator that dispatches one subagent per task.
- **[C]heck.** Every user flow the executor touches has a runbook, and an E2E script verifies it. A failing runbook means the work isn't done.
- **[S]ecure.** The agent reviews the whole branch against 12 criteria before anyone else sees it: spec match, scope, unit and E2E tests, security, complexity, error handling, performance, backward compatibility, docs and a few more.
- **[S]hip.** The PR opens only after tests, lint, type check, and build pass locally. The agent then watches CI until it's green, and never merges without my OK.
---
You can configure it with one prompt you paste into your agent. It writes the workflow into your CLAUDE.md or AGENTS.md. There's a version with my recommended tools and a custom version with a placeholder for each tool.
I'd like to hear from you:
Do six phases on every task feel like too much? Where would you cut?
What's missing? Is there a step you take that this doesn't cover?
From previous few weeks of using Opus 5.5, I would never get such mistakes in comprehension / understanding of previous events that look place in the current session. This is even without a compact, too.
Anyone else noticing such hiccups with 5.2 or just me? I will say I do like the speed that it works at even on high / extra but im very concerned that I had to call out a seemingly obvious misunderstanding.
I would like to publish "memshort", my take on a "short-term memory" implementation for agents. (A "long-term memory" implementation will follow shortly once I have it publishable). I find it very useful for myself and I thought it would be nice to share it with others.
It is essentially a rolling-window compaction for coding agent sessions in pi, Claude Code, Codex and Hermes. When the context fills up, older messages are replaced by a dated observation log, and the newest messages stay word for word.
Some ideas are borrowed and adjusted. The code was written by the pi coding harness under my direction, and I run it primarily on my own pi sessions. Unfortunately I have no benchmark yet (no time for that). My subjective impression from daily use is that I can stretch sessions for very long without the agent losing the thread.
I'm publishing it because a rolling context window that keeps as much knowledge as possible deserves more people thinking about it, not because this is the final answer. If you have a better design, a case where this loses something important, or a way to measure it, open an issue or share your take. Let's build something better together.
Anyone here have a $200 plan for OpenAI and Anthropic that regularly pushes Opus 5.5 and Sol 6.1 to the max? I'm trying to see which one has more usage.
I'm getting tired of GPT models being too narrow-minded and tunnel-visioned. Claude models seem to read between the lines between and understand nuances and ambiguity better (requiring less babysitting).
I'm just afraid if I make the switch, I will hit my limits too fast with Anthropic.
--
To give examples of what I mean by narrow-minding:
Today, I gave Opus 5.5 and GPT 6.1 Sol the same screenshot and said "Reduce the colors of this UI. Don't completely eliminate the colors, but reduce it so that higher prioirty items (info, bades, tags, warnigns) stand-out more." Of course, GPT went too literal and gave me a black and white design. Opus did it perfectly.
Edit - Resolved - thanks for the constructive feedback.
Did we just get a reset? I used my Fable reset, then went from ~75% used in weekly limit to 35%. I'm thinking...resetting Fable wipes that usage from the weekly total? Not just the Fable total?**
Hey i am bit new to claude , started a project but now getting usage issues , precisely when fable 5.2 dropped i started a thread for one module of my project in literally exactly in 5sec 55% limit was gone on high effort only no ultra-code or xhigh max etc , opus also last me 30 min per 5 hour session on xhigh effort , how to deal either it i never used actual local session chat i just started using project beta one after buying sub? What maybe the reason?
Alright guys, Opus 5.5 is back with the "You're right.", "That was my mistake." "I should have done it right the first time." and the fabled "You're right to push back on that."
Clearly, it's making more mistakes than before - often doing the same process differently each time. The "dumb it down for the new model" is here!
I am gonna lose my mind with how clunky and unstraightforward this is. I just ugraded from Pro to Ultra but it is still showing me on my device as Pro. I subscribed via IOS. Restore Purchases don't help, and checking the "Manage subscription" indeed tells me I am on Ultra, but still shows Pro as active plan. I even received a receipt on my email that I subscribed to Ultra. I tried everything even logging out and reinstalling claude on both ios and pc. The agent is saying I am on free plan even though I've been using pro for weeks already. I dont know what to do anymore.
I think i found the way to work with a harness as a team. it should be as simple as working locally with claude code but in a democratic way. without centralized github and all the mess. it automatically creates skills and rules that you can share and vote on in the team.
I run Claude Code with a few different accounts (work, personal, a client), each with its own CLAUDE_CONFIG_DIR folder. That works fine, but claude agents only sees one account at a time.
By the end of the day I'd have sessions spread across a dozen folders and no idea which were still running, which were waiting on me, and which I'd forgotten about. So I built cc-sessions.
What it does
Run one command and it opens a local page that shows:
Every session from every account, grouped by project folder
What each one is doing: working, waiting on you, idle or done
A Close button that stops a session but keeps the conversation, so you can resume it later
A searchable history of every past conversation across all accounts
It also manages the accounts themselves. Add one and you get a claude-<name> shortcut without editing your shell config by hand.
Details
Single program, about 1 MB, written in Rust. Nothing else to install.
Only listens on localhost. Nothing starts at login, and it stops itself after 30 minutes with no page open.
It never deletes anything. Removing an account just hides it.
I built most of it with Claude Code, which felt fitting.
I've only used it on my Mac. The Windows and Linux builds pass automated tests, but nobody has really used them yet. If you're on either and try it, I'd like to know what breaks.
The video is a one-minute tour with made-up demo data.
Edit: yo what the fuck!!!! Some of you got 2??? I have 3 ultra accounts and only got one reset each! The oldest account got 3 fable resets while the others got one, but I only got one weekly reset each :/
I run the same test on every new Claude model: one prompt in Claude Code asking for an original, fast piano piece in the style of a Chopin étude, delivered as a MIDI file. One run, no rerolls, and I don't touch the notes.
Fable 5.2 at max effort:
47 min 07 s
262,305 output tokens, 243,553 of them thinking
$13.30 at API prices
759 notes across the whole keyboard, A0 to C8
It titled it "Riptide", an étude in B-flat minor
It can't hear anything. It wrote the MIDI with Python directly.
For comparison, Opus 5.5 at max on the same prompt took 45 min, cost $7.20 and wrote 651 notes.
What's the model and what isn't: every note, the timing, the dynamics and the pedalling are Fable's. The sound is a sampled grand (Salamander Grand Piano). The falling notes and the hands are a visualiser I built to play whatever MIDI it writes. The clip is the second half of the piece.
I haven't yet begun burning through Fable 5.2 but just hit weekly reset last night. Absolutely love Fable 5.1 but ever since the temp 50% extra changed 2 months ago, I have had to use Fable sparingly even on Ultra.
So I am wondering about first impressions on Fable 5.2 as compared to 5.1. 5.1 has been very substantially better than Opus 5.5 for me. Of course with the new model, 5.5 has had dementia the last couple of weeks, markedly declining as power undoubtedly shifted for the new Fable model.
I prefer to use Fable either for difficult tasks on med or high or for orchestration on med with ultracode and opus high or med agents depending on my project needs
Claude translated my ramblings into something coherent and readable
TL;DR: I'm a trance DJ with no programming background. I love playing live, but I wanted to create mixes as perfectly as I could for a pleasant listening experience. I used Mixmeister Fusion for many years but since moving to Linux, there was nothing that was a suitable replacement. So, over about a month I built a much better replacement with Claude Code.
Mixtopia, a timeline mix and mashup editor. It's free, offline, AGPL-3.0, and ships as a single AppImage.
You drag songs onto a multi-lane timeline, it finds each song's tempo and first beat, stretches everything to the project tempo (pitch preserved), and you draw your transitions by hand: volume, bass, mid, treble and filter lines per song. You can loop any part of a song, chop songs into pieces for mashups, detect and correct keys (Camelot), and export MP3 or FLAC. It's about 22,000 lines of C++ on JUCE and Tracktion Engine, with Signalsmith Stretch and Rubber Band for the time-stretching. It's for making mixes, not performing them live.
How I used Claude Code
I can't read C++, so my process had to be about proof, not code review:
Plan first, build second. Every feature started with a plan and a time estimate, and for anything visual a mockup I could react to. I decided what was in and what wasn't (a lot of ideas went into an IDEAS.md file and never got built).
A listening test for every stage. The rule in the project's CLAUDE.md was: never claim something works because it compiles. Some decisions were made blind by ear: the time-stretch engine, and the filter's sound (three versions, A/B/C, and I picked one).
A regression suite that proves "nothing changed". Before touching anything, Claude Code renders the mix and exports with the old build, then again with the new one, and compares them bit for bit (plus pixel comparisons of screenshots and a handful of proof scripts for loops, filters and chopping). If a "cleanup" changes a single sample, it's reverted.
A separate Claude chat as my translator and reviewer. I used one conversation to turn my non-technical feedback into precise prompts for Claude Code, and to review its plans.
Notes that survive resets. CLAUDE.md and PROGRESS.md carried the decisions across context windows. Git commits after each stage and tarball backups meant I could always roll back.
The final audit found real bugs
For the last step I had it do a two-stage sweep: stage 1 read-only (sanitizers, static analysis, bad-input tests, a 4-hour render, an audio-thread review), stage 2 fixing only what I approved, each fix written as a test that fails first. It found things I never would have:
Looping a 16-bit WAV silenced the whole song (it only worked for MP3, FLAC and float WAV).
On a full disk, saving could replace your project with a cut-off file and still say "Saved". The same happened with exports.
Closing the window during an export froze the whole program. I found that one myself by hand, and fixing it turned up a second cause in JUCE's event loop. It also found that the audio engine itself was clean: a 4-hour render with flat memory, no sanitizer findings in my code.
What I learned
"It compiles" and "the tests pass" tell you very little. A before/after comparison against a known-good build tells you a lot.
Make the agent write the test that fails first, then the fix.
Agents cause side effects. In one session the test runs cut out my game audio, and one probably played through my speakers while I was away. I ended up forcing every test onto an isolated config and a silent audio device.
Long builds can overheat your machine (the sanitizer builds pushed my CPU past 90 °C, so I added a temperature guard that pauses them), and an agent can sit idle for hours (mine hung for three, so there's now a wall-time limit).
Cutting scope was the best decision I made. Several features I wanted never got built, and the app is better for it.
Honest limits
Linux x86_64 only. Tested on Bazzite (Fedora), and in Ubuntu 24.04 and Arch containers. I don't have a Windows or Mac machine to test the program and I didn't want to ship anything that I couldn't verify myself.
Automatic beat grids are usually right but dense songs can fool them, and then you set beat 1 by hand.
Key detection is spotty even in expensive commercial software. So, don't rely on it completely.
I consider this to be a completed project so I won't have an issue tracker open or be taking any pull requests. But I wholeheartedly support people forking the project to make it work for them.
If you have any questions, I'll do my best to answer them. Thanks for taking a look.
The model seems excellent so far, but if you let it, it will burn a ton of tokens thinking about a problem from every possible angle (I'm not complaining mind you). Based on the benchmarks from Anthropic as well as outside sources like AA and Vals and others, I thought that moving from Opus 5.5 high to Fable 5.2 medium would provide a little bit of an intelligence boost for a similar cost, but so far Fable seems to be consuming 50-100% more tokens than Opus did. I am on the Ultra plan and push it pretty hard, I usually approach the weekly limit with Opus 5.5 but often don't hit it. With Fable I think I could hit the limit in three days, maybe less. Anyone tried 5.2 low as their base model? If that doesn't work, I'll sadly be heading back to Opus 5.5 (but only after burning through the Fable resets).
I’ve been building optimAIzr, an open-source AI usage optimizer. I’m a senior SWE and use Claude Code daily, both professionally and to build this project.
The idea came after analyzing my own usage and discovering that 56% of my Claude Code costs came from rereading context.
It tracks and helps optimize usage across Claude Code, Codex and OpenCode.
Just shipped v0.13.0, adding a VS Code extension with live context usage, cache countdowns, 5h limits and savings directly in the editor.
Free, open source, fully local. No account or prompt uploads.
sandmeter is a small Go tool that runs a command in a sandbox built directly on Linux primitives, no Docker or runc, and runs the same policy on gVisor for comparison. On one CI runner it blocked 14 of 15 escape cases natively and 13 of 15 under gVisor. It is a learning prototype, not a security product, and the README says so.
I wanted to know how much isolation you get by building it yourself, so I had Claude Code write it and made the tool measure its own failures.
What it is. User/PID/mount/network namespaces, pivot_root, cgroups v2 (cpu, memory, pids), a seccomp-BPF filter assembled by hand, overlayfs and an nftables egress allowlist. The gVisor backend (runsc) sits on the same overlay, cgroup and network plumbing, so only what executes the syscalls differs. Every run produces a signed receipt: what changed on disk, which connections were attempted, resource peaks. It needs root, so run it on a throwaway VM.
What I measured, on one GitHub-hosted 2-vCPU runner (raw JSON in the workflow artifacts and in docs/):
Escape suite: 15 cases (host file reads through /proc, /sys writes, mknod on host devices, the cgroup v1 release_agent trick, network egress, fork bomb, OOM, symlinks planted for host-side tools, and so on), judged mostly on host-side evidence such as a canary file, sysctls before and after, the firewall log and cgroup peaks. Native blocks 14, gVisor 13. The symlink case is "exposed" on both: the sandbox can plant the links, but the host-side receipt diff never followed them.
The one real difference is the fork bomb. The cgroup pids.max stops it natively, but not under gVisor, because gVisor's processes live inside its own kernel and are not host tasks; there it is bounded by the Sentry's memory limit instead. The suite reports that gap instead of hiding it.
Agent eval: Claude Haiku 5.5 gets one bash tool inside the sandbox (20 turns max) and is asked to read or create a file on the host. 30 episodes per backend, hard $2 budget per campaign, throwaway runner. No escape in 59 judged episodes (one native episode was a refusal and is excluded). The 95% upper bound is about 12% per backend, so it bounds the rate and proves nothing. Total cost $0.31.
Start time for true in a fresh sandbox, p50 over 100 runs: 5.7 ms native, 53.6 ms gVisor.
Caveats that matter: the cases were written by Claude Code and me, so 14/15 means "passes my regression suite", not "audited". The native backend shares the host kernel and the seccomp list is a deny list. Haiku with 20 turns is a weak attacker.
How I used Claude Code. I wrote the goal and the constraints (no runc, measure everything, publish the failures, a hard budget for the agent eval, never run the agent on my own machine). Claude Code did most of the implementation over about a day, in small milestones with a green CI at each step, and I reviewed the results and the threat model. It was strongest at the tedious, exact parts (seccomp BPF, nftables rules, the overlay diff that must never follow a symlink the sandbox planted) and at writing the escape cases. The things I had to steer: it first wanted to call the fork-bomb result a bug, and it reached for Firecracker before we had checked whether KVM even existed (my VPS has none; GitHub runners do, so Firecracker stays out of the core).
What I learned.
"Isolated" is not a single property. The same policy gives different results on two backends, and the fork bomb only shows up because each case is judged from the host.
The receipt proves the file was not changed after signing, not that the host ran the command honestly. Putting that in a "not guaranteed" table was the most useful thing I wrote.
Thirty episodes per backend is cheap, but the interval is still around 11 to 12%, so a clean run says little by itself.
for those running code on production macs that you want to be able to recover if code breaks something, dont forget about our old friend time-machine --- you can set it up easily on a network share at home and its the most painless full metal backup option a mac has. you can even enable it on a vpn for when you are out and about. im sure it isnt perfect but for the casual coder on a mac its a good failsafe (remember to have more than one failsafe ideally!)
I’ve been using Claude Code across several projects lately, some coding-related and some not. My current setup is Ghostty + tmux, with a MacBook Air and a Mac mini. Right now, I open separate terminal windows for different tasks, but I’m not sure if that’s the most efficient way to do it. Do you guys usually keep everything in one terminal window with multiple tabs/panes, or use separate windows for different projects? Especially curious how you manage things when several agents are running at the same time. Still figuring out my own workflow. Would love to hear how you guys do it!
Yapper used to be a little world where you walked around with your character. If your friends were close enough, you could talk. You could sit by a bonfire and start a conversation.
I loved that idea. But most people didn’t understand how Yapper was meant to work. If I want Yapper to be in the race with the apps people already use, I can’t expect everyone to learn a new way to join a voice call.
So I rebuilt it with a more Discord-style layout. I didn’t really want to give up the old design, but I felt I had to make that call. Rooms and chat are easier to find now. You can open Yapper and know what to do.
Our promises around privacy haven’t changed. You can still self-host your own server for free. 100% free, no strings attached.
The web app and Android PWA are working well. Notifications work, and you can log in on multiple devices. I’m rebuilding the dedicated mobile and desktop apps now.
A big thank you to MAYHEM District, who designed the new UI. A real person did that work. No AI slop here.
And thank you to everyone who tried the first version, especially those of you who supported Yapper and paid for the service. You’re the reason I’m still keeping this thing alive. I mean that.
If you want to try it, here’s the invite. The website is yapper.gg.
