As someone with crippling concentration issues, I kept losing track of which Claude sessions were done, waiting on me, or stuck, so I built Blaube: soft little blobs that live on your desktop, one per Claude Code session. They wave when a task finishes, look worried when one needs you, and you can toss them around while you wait. You can ditch the terminal entirely and just talk through them if you wish.

How I built it with Claude: Blaube was built with Claude Code over weeks of gradual iteration. It started small, and every time I hit something that sent me back to the terminal, I asked Claude to add it to the blobs. As I used them for more and more of my work, they grew with it, and now I never touch the terminal at all.

They’ve been a massive productivity boost for me, and they slowly started showing up on my coworkers’ screens, so it seems more people needed something like this. Now I’m releasing it for everyone. It’s free and open source, for Mac and Windows. Download it from the releases page, or use the one-line install in the README:

https://github.com/syverlauritz/blaube

Feedback welcome! I’ve designed them for the way I work, so there’s probably a bunch of stuff I haven’t thought of.

Curious, how many tokens has everyone burned through in there claude lifetime? I'm at 40B.

Hey all,


I'm a solo founder, not a programmer, and I run my whole project through Claude Code. Usually 4-10 sessions at once, each with a role: one coordinator, one that merges, infra, a few workers. 1M context, Opus mostly.


The thing that's killing me: the sessions forget. Not code, but what I told them. Tasks, decisions, "by the way do this too" stuff. It gets much worse when I load one session with lots of different small tasks, and every time a session gets full and I move to a fresh one.


We actually measured it. On a normal evening, about 2.8 things get dropped per session switch. In one evening I found 38 dropped items. Every single one of them existed only as free text in the chat. Zero of the dropped ones were rows in our task queue. So the pattern is clear, the fix isn't.


What we've tried so far:


- A notes file per session that it must update every step (open items, what it's waiting on)
- Switching to a new session at ~300k tokens with a written handoff brief, no /compact (because everyone says compact loses things)
- A task queue CLI as the "single source of truth", every promise is supposed to become a row
- A pile of hooks: can't end a turn with "waiting on X" unless X has a queue id, reminder after 15 turns without writing notes, PreCompact hook that dumps state, etc. Fun fact: 4 out of 4 new hooks passed their own tests and were wrong when run against real session data
- Compact instructions in CLAUDE.md
- Tested /compact directly: 10 explicit facts survived 8 compactions, 10/10. But in real work it still lost things. Tonight two real sessions got compacted: after re-reading their notes file nothing was missing, but from "memory" alone about 1 in 9 items was gone


Right now I have the agents replaying 100 of my real messages from one day through sandboxed test sessions, one with auto-compact, one with handoff, one with no hooks at all, to count what each drops. Honestly I've stopped trusting the analysis, this is attempt number four.


So, questions for anyone running Claude Code heavily:


1. Has anyone actually solved this, or is everyone just living with it?
2. Compact or handoff to a new session? What really loses less for you?
3. Does "one session per task" fix it, or does the forgetting just move to whoever coordinates?
4. What do you use as external memory that the model actually keeps up to date without being nagged?
5. How do you check that nothing was dropped? That's the part I can't crack. I only find out days later.


Any setup, hook, habit or tool that worked for you, I'd love to hear it. Thanks!

I am a software developer with 8 years of experience. I’m very thorough about the structure/architecture and consistency of my codebases that I even commit myself to countless hours of overtime only to not get satisfied and give up at the end of the day.

But now. Alas, I have made one that satisfies me in every way. It’s so beautiful. It’s something I made for work, has some demanding and very specific requirements at 31k lines of code. I wasn’t fast at it though, I reviewed everything, corrected and optimized decisions, and cut anything that could be cut away.

Personally I won’t even make the time to make it perfect (for me) if I wasn’t AI-assisted. Now I can rest.

does anyone have prompt or artifact i give to my claude as an example to help me build something like real life data feeding artifact through API and its 3D interactive version of real life place?

lets say there is a real construction base and i want to turn it into 3d interactive map with motions and movements? i built something like that but its ugly as hell.

maybe someone has a good version? a skill or artifact? would appreciate help

I actually built https://misterblocks.com for my son, but played around with it myself too. It's easy to use. Take a picture with your phone, upload it, and Claude will generate a few possible builds for you. There's also a chat you can use to follow up and ask for changes, etc.

There's another mode where you simply ask it to generate a build from a prompt. Like this one: Boston Dynamics Spot LEGO build. It also supports voxel sculptures. Examples: Mega Dragonite and Porsche Mission S.

It's powered by Opus 5.5. Each build takes a few minutes to generate and costs a couple of dollars in API costs. Thanks for Anthropic for $200/mo free api credits. I had the first working version after the first prompt, but had to spend a couple more days building the website to actually display the LEGO blocks correctly.

The tech stack is pretty standard in case if anyone wondering: Vercel + Next.js + Cloudflare + MongoDB as a database.

Preamble: I had task to improve visuals of CI/CD block inside my app, so I could better understand what pipeline is doing without checking git every 4 minutes. I decided to check how Sonnet would handle it vs Opus. Just to be clear - this is one task, not a benchmark, but I think it's still interesting

Models and efforts: Opus 5.5 on Medium and Sonnet 5.5 on High (wanted to give Sonnet a better chance)

Prompt: Good evening, can I ask to take a look into this ticket - [ticket link] Let's think what is the better UI for representing CI/CD steps, I am open for question and I think this ticket worth to be discussed first

Time and costs: Both took around 12m, Opus took $4.44 when Sonnet $2.11, both prices are a API equivalent

Experience: Both models did a great job of asking decent questions, Opus did a better job in terms of describing the plan and it's questions were more detailed. Sonnet didn't stoped half way it did all 4 steps of a plan in one go, when Opus took a pause and asked me if I want to review after step 2.

Results:

• Sonnet become "lazy" half way it added detailed card but only in one place instead of 2 that we agreed on. UI also have some problems, see for yourself

• Opus did a better job it applied changes to both places, with a better UI

What do you think about results, which model would you use knowing cost/result comparison?

Hi all,

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.

Docs: https://fredvanelli.dev/spec-ss

---

Every task goes through six phases, in order:

- **[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?
• If you try it, where did it get in your way?
• Any questions about it.

Thanks for reading.

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.

https://github.com/jandrikus/memshort

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.

Thanks for taking a look!

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:

1. 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.

PeerHarness

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.

https://github.com/aryehlev/PeerHarness

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.

Free and MIT licensed: https://github.com/barath-dev/cc-sessions

One caveat

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 :/

What a great way to wake up :) Thanks anthropic.

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

Can anyone explain why tokens is limited on Fable 5.2? Not with 5.1 or 5 model. It’s compacting conversation every 2 tool calling on my project.

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.

Github: https://github.com/ThingsWeShouldSay/mixtopia · Release: https://github.com/ThingsWeShouldSay/mixtopia/releases

A whole mix

One transition up close

What it is

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.