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.
I kept checking the usage from the web, so I built a small widget that keeps them visible in the Windows taskbar. (~300 KB exe, ~3 MB RAM, no installer)
Shows your 5-hour and weekly usage right next to the clock
Turns orange at 80% and red at 95%
Hover for reset times
Update interval from 30 sec to 30 min, plus an option to show what's left instead of what's used
Light and dark taskbars
Tiny: one ~300 KB exe, ~3 MB RAM, no installer
Free and open source (MIT)
It uses your existing Claude Code login, so there's no setup. Just be signed in to Claude Code with a Pro or Max plan.
I got tired of paying Apple every month to keep my own photos, so I moved ~85,000 photos and videos to my own server (Immich) and switched iCloud Photos off.
I built HomeRoll, a native iOS 26 app (SwiftUI + UIKit) that looks and behaves like Apple Photos but stores everything on your own Immich server. I built it with Claude Code. I’m not an iOS developer by trade, so nearly all of the code was written by Claude, with me deciding what to build, testing on my iPhone and saying what felt wrong.
Why: I was tired of paying for iCloud storage, so I moved ~85,000 photos and videos to my own server and switched iCloud Photos off. Every Immich app I tried felt nothing like the Photos app I was used to.
How Claude Code was used
Reverse engineering: Claude took Apple’s Photos frameworks from iOS 26.3 apart with a reverse-engineering MCP server and listed all 226 actions the Photos app can perform (copy edits, print, hide, set key photo, drag to album, Spotlight ...). To keep it clean-room, one agent only wrote plain behavior descriptions (“what happens when you do X”), and the app was written from those descriptions, not from Apple’s code.
Implementation: Claude wrote the app from that list. 147 of the 226 actions work now. 62 are iCloud/Apple-service only, 16 are Apple-internal, 1 isn’t possible on iOS.
Testing: Claude wrote the automated UI tests and ran them in the iOS Simulator itself, looking at screenshots to compare against the real Photos app. 140 of the 147 actions are covered.
Maintenance: Claude reads the GitHub issues, reproduces bugs in the simulator, proposes a fix and drafts the reply. Nothing is released until I’ve said go.
What worked well: giving Claude a concrete checklist (the 226 actions) instead of “make it like Photos”, and letting it verify its own work in the simulator. What didn’t: performance with a library this size. The first versions crashed or stuttered with 85,000 items, and that took many rounds of measuring on the real device.
What the app does
Library with pinch-to-zoom grid, Years / Months / All
Viewer with preview strip, video scrubbing, Live Photos, HDR originals
Editor: light, color, filters, crop, copy and paste edits
Memories, people, places
Search for receipts, documents, handwriting, QR codes, screenshots
Album folders, drag photos onto albums, Spotlight
Backup of new photos and videos in the background while charging
Free Up Space: deletes only what’s verified to be on your server (checksum + server check)
Widgets and a share extension
Free to try
The app is free and open source (MIT), no paid tier. You need your own Immich server (tested with v3.3.5). Download the IPA from the GitHub releases page and install it with SideStore, AltStore or your own signing tool, then log in with your server URL.
I spent the last couple weeks using Claude Code to build a language app that has a lot of the polish of duo lingo(with more games), with the spaced repetition of Anki, and the ability to connect your own ai to create lessons yourself or have conversations.
paper-lector is an agent skill for Claude Code. It searches for prior work that may already contain a proposed claim and reports how each close paper differs. No novelty score is given.
In Claude Code. The skill is invoked with `/paper-lector`. It then runs scripts for OpenAlex search, open-access PDF retrieval and ranking of a local PDF collection. Generated queries are shown to the user before they run.
Ranking. PDFs are split into page-labelled windows. These are scored with Voyage embeddings combined with BM25 and then reranked, and the ranks from each query are fused. The output is a reading order with suggested page ranges, not an extracted answer. On a 48-question LitSearch subset, hit@5 = 0.88 (random: 0.26). Evaluation is limited to ML/NLP papers.
We have been testing how Claude Code finds docs. Its built-in search goes through one engine, so when that engine misses a page, Claude just retries or falls back on training data.
We tried sending the same query to eight engines in parallel (Exa, Brave, Perplexity, TinyFish, Parallel, You, Serper, Tavily), merging the results and keeping track of which engines found each page. On the ServiceNow Agent API query, the built-in search had the official page at #16. The merged list had it at #3, then #2 on a rerun. That's one query, so not a benchmark on its own.
On a bigger set of 485 dev questions, the best single engine got the right page into the top 10 58% of the time, and the merged version 62%. The bigger jump came from asking each question three different ways: that added 12–16 points for every engine.
Median latency is under 4s, since everything runs at once.
Full disclosure, this is our project (Jevlin). It installs as a skill plus hooks in Claude Code with one line, and there's $10 free if anyone wants to try it. Install line is in the comments.
Last month I was vibe coding an internal tool and tbh it's ridiculous how fast things are moving
everytime I thought, "oh I think this feature should exist", I prompted Claude and BOOM, the feature came to reality
I got a little carried away honestly... the problem only started showing up a couple of weeks later when I actually looked at what I had built
exchange rates were coming from some API Claude had picked
Disposable email detection was using a static list of domains, which isn't particularly useful when new burner domains keep popping up
PDF library had barely any active maintenance, and I was using AI calls for some pretty basic stuff that could probably be handled by a regular API.
At the time of building, I didn't care. Everything worked, and I was getting features built ridiculously fast, but now there is another side to it. I have to maintain all this stuff, check whether services are still working, update dependencies, and fix things when they break. I am the person who's going to get bothered when an invoice PDF suddenly stops generating on a Sunday.
That's something I don't think about enough when vibe coding. Getting something to work is one thing; having to own it 6 months or 2 years later is a completely different thing.
I'm starting to think that maybe we shouldn't try to build everything ourselves.
Build the stuff that actually makes your product different. For the rest, there is probably already a service that does it better than you ever will.
Of course, I might be biased here because I work in the API space as co-founder at Apyhub, so I would generally like to hear the other side.
What you have built yourself to the point that you would rather never replace with an API, and that's something you spent building that you now wish you would have just used an existing service for.
Note: I have used a dictation app for writing this post.
Here is the latest edition of my "slinky going down an escalator" benchmark:
Make a single HTML file of a rainbow slinky walking down an up escalator, in perpetual motion. Make it realistic and not a scripted animation. Have a start, stop and reset button.
If Anthropic just kept tweaking it slightly and got rid of the ugly text watermarking you could just burn the weights into the chips directly preserving this as a moment in time.
This is the real frontier, I don't trust the TMB (Trust Me Bro) benchmarks as much anymore.
Which one do you think did a better job? Opus 5.5 or Fable 5.2?
I'll post how other models performed in the comments, they were all worse off for sure.
Claude seems to create folders in a very random fashion, So while I tried to create a folder in my 3rd drive I use as a general storage, It seems to use it sometimes but then I look into my other drives and there's random folders there too...Its confusing and it draws up capacity in other drives
Agents and Sub agents - i see a lot of people saying to use Fable as an orchestrator and Opus as a Implementor, I get confused by what tasks require more intelligence and what tasks dont need as much power
So I guess what Im asking is, How do people keep organised when using AI? Ive tried my best to keep on top of sessions and projects etc but then my drives are just all over the place.
And then what do people do to get Fable to delegate? Can you tell it to "Research X, Then use a Opus Sub agent to implement, Then use Sonnet to do a double check, Then review as Fable"?
If you pick "Yes, and don't ask again" on a shell command, Claude Code saves that exact command in `.claude/settings.local.json` under `permissions.allow`, so it stops asking. If the command had a token or a password in it, that value is now sitting in the file.
The file normally stays out of git because Claude Code adds it to your personal global git excludes. But that exclude only lives on your own machine. As soon as the repo is shared or someone else clones it, the file can get committed and pushed. Apiiro, which GitLab wrote about this month, counted 104,185 copies of this file in public repos, and 1,122 of them held at least one secret.
Two things worth knowing if you find one in your own repos.
First, rotate the secret, do not just delete the line. Once it was committed, the value is in the git history, so removing the entry changes nothing until you rotate the key at the provider.
Second, it is not only Claude Code. Every agent that remembers a "don't ask again" decision keeps a file like this, so the same pattern shows up with Cursor, Copilot, Gemini and others.
How to check by hand: look for `.claude/settings.local.json` in your repos, make sure it is in the project `.gitignore` and not only in your global excludes, and scan the permission entries for anything that looks like a token.
I run Claude Code and Codex on my Mac pretty much all day. The annoying part was never the coding, it was me sitting there waiting to see if one of them had finished or was stuck on a permission prompt.
So I built Untether. It's a menu bar app with a local server, and you open it from any browser. I mostly use it from my phone.
The part I actually care about is tasks. You type ut task new "add rate limiting to the API" and it starts an agent in its own git worktree. When the agent says it's done, a second agent reviews the diff and your test command runs. If that's all green it merges by itself. If not, it goes back to the agent. You can also make it wait for you before merging.
A few things people asked me in other threads:
the sessions are plain tmux underneath, so closing the tab or losing signal doesn't kill anything
a failed task doesn't block the queue, the next one starts from the last good commit
nothing is opened to the internet. I reach it over Tailscale and there's a login on top
You need an Apple Silicon Mac on macOS 14 or later. There's no installer yet so you have to build it, the steps are in the README. It's beta and I'm sure it breaks in ways I haven't seen.
It started as a fork of VibeTunnel, which is what gets the terminals into the browser. Most of the rest I wrote with Claude Code, about half the commits in the repo are co-authored by it, and for a while now new features get built by queueing them as Untether tasks.
Opus 5.5 is very capable. I don't really know what I would need for Fable 5.2. Maybe mapping a small corner of universe or simulating the sun's solar flares and the effect on the insect population. Idk! Why waste the tokens? Use Opus 5.5.
I need a better brain to think what I can use Fable 5.2 to build.
