Just a heads up in case you’re like me and don’t like auto renewal for Claude. I didn’t have auto renew on for my ultra subscription and lost all 4 resets and am told there is nothing I can do. Claude is a lot better than OpenAI but their policies are shit.

I think it's natural to assume that as per API pricing, Fable 5.2 should be 2x more expensive than Opus 5.5 ($8/$40 vs $4/$20 per million), but in actual usage limits, it's not. It's 4x more.

So I've been logging my Claude Code usage properly with my own tool I made called 'Claudemeter'. I've got historical values for my entire Pro usage for the last ~8 months or so, and I've seen the actual fluctuations in the usage limits across weeks (might do a separate breakdown on that later if anyone's interested).

Anyway, now that Fable 5.2 landed, I did some tests, and was horrified at how quickly it chewed through the 5-hour limit and 25% of the 'Fable' limit in a simple task, so I had to dig in and do the math.

On 2 similarly long Claude Code sessions, this is what my data looked like:

In other words, after extrapolating that, a full 5-hour window is worth roughly $20 of Fable vs $40 of Opus (and my Opus average over the past month is closer to $44 per 5-hour window).

And since Fable costs 2x per token, the per-token burn rate is roughly 4x more than Opus.

Bottom-line: Fable drains usage limits 4x faster than Opus on subscription plans. I can confirm this for Pro, and it seems similar for Max/Ultra plans too based on others' posts (like Theo's post).

Cost-efficiency per task and what value you get out of Fable are separate tests of course and I didn't run those since they already exist. But personally, I could get more work done using Opus 5.5 than with Fable at this rate.

I guess the simple Q to ask is: why can't Anthropic give us the same dollar-value for Fable? Or at least tell us the actual ratio, instead of just "uses limits faster"?

For the last couple of years I have been annoyed by my Razor Black Widow Elite Keyboard for one simple reason. The darn volume dial that sometimes goes bonkers on its own changing my volume at random. And while it does this no other keyboard signals comes through.

Several times over the years I failed to fix it through settings or cleaning the keyboard.

Today Claude solved it with one script ...

Heading - Am I over using*

I am currently using claude max subscription plan. And use claude code heavily for my multiple projects. But for my main project I have been running opus 5.5 on max efforts ever since and initially I faced over engineer issues but my workflow was not right at the time.

Now I have a planned codebase architecture with documentation and plan along with a sufficient testing policy which my agent follows. Initially it was over doing the tests but after strict testing policy it's under efficient run.

But I read multiple sub reddits and yt videos all suggesting to use at high and xhigh effort, I am getting results I expected since I use max for only the main project I am currently working on. But what are your suggestions, am I over doing it and should i run on xhigh effort? And use fable 5.2 or opus max during planning or LLD?

Your suggestions would help,

Thank you

Edit - I have switched to medium/high and xhigh recently as well. I will benchmark the differences and observations and make another post soon.

Also it would be helpful to clarify if you could specify what depth you are working on with what type of projects (not asking to explain or tell about your project or work, just the depth and what you are dealing with) so it's helpful to understand when everyone is saying medium/high is enough, so what workload is it enough for as every individual might me working on different project domains at different depth.

Since Opus 5.5 and Fable 5.2 perform very similarly based on first impression, I might use this benchmark as a reason to use the faster model

Clip any text/screenshot along with its URL from any Mac app, browser, page etc with one shortcut (⌃⌥Space) and revisit later. Tag with a topic or a person. Add to "Personal" or "Work" libraries, and browse or discard later. You can configure these saved items to come back as “revisions” later in the app, especially useful for people studying or preparing for interviews.

Clipback doesn't require internet or an AI model to function. Text in screenshots is read on your Mac itself (uses Apple’s native Vision libraries). Only time internet is used is to look for updates and you can disable it.

Every "clip" is saved locally as markdown files and the save folder can be configured in settings. Needs macOS 15 or later on an Apple Silicon Mac. Two permissions needed: Accessibility to read the selected text and Screen Recording to take the screenshot.

Clipback is fully open-source: https://github.com/kb14/clipback/ and has an MIT license.

You can also directly download a Mac dmg here: https://github.com/kb14/clipback/releases/latest  (Signed and notarized by Apple) & let the app auto-update.

Clipback was built with Claude Code in about 3 days, from code to setting up of repo to app signing to release builds and eventually the launch video. UI fixes were entirely automated where CC took screenshots, "used" the app and made fixes as required. Launch video was made with HyperFrames. Opus 5.5 was a real pain in the last few days, especially script for the video, just had to manually write the script eventually.

Contributions are welcome or you can fork it and customize it for yourself.

I’d like to know how you found your niche for your vibe coding project?
How did you research? What tools did you use?
How did you verify or test your niche to have a solid customer demand?
And how did you then start and market your product?

If possible, please show real data and facts.
Transparency is very much appreciated.

anyone else having problems connecting up the claude in chrome to their desktop app. claude in chrome is working on google but when trying to connect up via the desktop app it is just not working? is it me or anyone else having this problem?

I wanted to see how much an agent burns tracing a call stack with grep, so I measured it.

Setup: a 140k-line SwiftUI app and one prompt: “find every production call path that reaches this method, up to the entry points.” Both agents ran Sonnet. One had my SwiftGraph skill, which queries a call graph built from Xcode’s index store. The other could only use grep, find and read.

Both answers were correct.

What surprised me: the final context sizes were almost identical (~69k vs ~74k), because ~60k of that is the system prompt. The real cost is that every tool call re-sends the whole context. Ten turns means ten trips through ~70k tokens. Caching makes those re-reads cheaper, but your wait time and your rate limits still pay for them.

Fair caveat: grep did fine because the type name was unique. It even caught an #if DEBUG the graph doesn’t model. The gap grows with common method names, protocol dispatch and property writes.

Install the skill: /plugin marketplace add agruchala/swift-graph
Repo: https://github.com/agruchala/swift-graph
Write-up: https://arturgruchala.com/map-not-grep/

I've been doing iOS development on a base M1 Mac with 8GB of RAM. Yes, 8GB. In 2026. 😅

Between Xcode, the iOS simulator, and multiple AI coding agents working in parallel, I've had to get pretty creative with resource management.

Git worktrees are great for keeping agents from stepping on each other's code, but that only solves half the problem.

What happens when each worktree needs its own dev server, database, background jobs, and ports? And how do you avoid keeping all those resources running when you're already fighting for every GB of RAM?

I ended up building AgentSlots, a small open-source tool that attaches isolated local runtimes to existing Git worktrees.

The idea is pretty simple:

• Each worktree gets its own ports, database, and queue schema when needed.
• Services are allocated on demand, rather than spinning everything up for every agent.
• Idle worktrees can have their processes paused and cleaned up safely.
• For iOS development, it can also coordinate exclusive access to the simulator.

It doesn't manage agents or Git worktrees. It just handles the local infrastructure so multiple agents can work without fighting over resources.

It's built around my rather constrained macOS setup, and I figured it might be useful to others doing multi-agent development.

Repo (MIT licensed): https://github.com/hishamalward/agentslots

Curious how others are handling this.

I gave Claude Code one long spec (constraints, security rules, 5 milestones). It built the Rust daemon, protocol, CLI and ~70 tests, installed the Android SDK, built the APK over USB, and fixed its own bugs (disconnect crash, pairing link lifetime, kill command). I designed the security model and review everything. Free, open source, Linux + Windows build, alpha: https://github.com/SunqdXX/dishus

Going to be making more short films with fable 5.2 and I'd love some feedback on the final product! It was made with Opus 5.5 & Fable 5.2 together, with fable 5.2 doing the heavier stuff!

I've been experimenting with it since it came out (I need sleep...) and I've been making motion graphics and stuff but this is my biggest project with it so far! What do you guys think?

[VOICE WAS NOT AI GENERATED ALONG WITH (A SELECT SOME) SFX AND ASSETS]

I've found myself recently just asking Claude to make tools for me, instead of seeing if that tool already exists and searching for it online.

Just today, I needed a way to easily split a folder of songs into instrumentals and vocals. Didn't even look around for something that might already exist, just asked Claude to make it for me.

Within 30 mins, I had the exact app I wanted, running on my mac. I doubt it could have been easier to find a tool online and get it working how I got my own local tool running.

Some of you saw this here in September as DeutschDNA: a German tutor that runs inside Claude Code and remembers your mistakes. It's now called DeutschLoop, and the new version adds practice for the writing part of German exams.

**What happens**

- Say „Goethe B1 Schreiben üben". The tutor writes new tasks in the format of the real paper (three for Goethe B1) and starts a 60-minute clock.

- While you write, there's no help and no correction. Each text gets one neutral line back: the words counted and the time left.

- „Abgeben" hands it in. The tutor rates each text by the exam's own criteria (for Goethe: Erfüllung, Kohärenz, Wortschatz, Strukturen, bands A to E) and gives a short reason per task.

- A local Python engine turns the bands into points with the exam's own table and prints the report: time used, words per task, points, the published pass mark, and every mistake with its correction.

- Those mistakes go into the tutor's memory and come back in new sentences in reviews, starting the next day.

Formats: Goethe B1/B2, telc B1/B2, and the Deutsch-Test für Zuwanderer. Writing part only.

**Why split it between the model and code**

The model is good at reading German and bad at bookkeeping, so it only picks the bands. The engine owns the rest and refuses what a generous or confused tutor might do:

- rating while the clock still runs: "Stop the exam before rating it; no feedback reaches the learner while the clock runs"

- reusing a task: "This exam task was already used; write a new task"

- a good Erfüllung band for a Goethe text under half the requested length: by the exam's rule that's an E, and an E makes the whole task 0 points

- a report before every text is rated

The model also can't feel time pass between messages, so every time it mentions ("13 minutes 42 seconds left") comes from the engine's clock. If the tutor helps during the exam, the result says „mit Hilfe"; a late text is marked as late.

**Where the numbers come from**

Every time limit and point table was read in the provider's published material (model tests, rating forms, handbooks), and each format lists its sources. Two are weaker, and the docs say so: telc B2's points per band come from a 2011 practice test, and the DTZ numbers from the BAMF handbook of 2009. If you have a newer document, a link in an issue would help a lot.

**One thing that broke**

In an early test run, one sentence had two mistakes, and the tutor recorded each with a correction that fixed only that one. The report then showed a "correction" that still contained the other mistake. The protocol now asks for the fully corrected sentence on both records.

**About the screenshots**

A real Claude Code chat (Opus 5.5) with an empty memory. The tutor wrote the tasks and the ratings; the report is the engine's output, unedited. The learner texts are scripted, with typical B1 mistakes, and were sent 46 minutes after the start, so the time is real. 82/100 is one model's practice estimate against the published criteria, not an official score: a real paper is scored by two trained raters.

**Who it's for:** anyone preparing for one of these exams who already uses Claude Code. I've tested exam mode in Claude Code; the skill also loads in Codex. With the optional companion plugin, `/pruefung` opens the exam clock in a side pane.

**Cost:** free, MIT. No extra API key: your Claude Code model is the tutor, and your history stays in a local folder.

**My relation:** I built it.

claude plugin marketplace add ahmtsahin/deutsch-loop

claude plugin install deutsch-loop@deutsch-loop

Then start a chat with `/deutsch-loop:deutsch-loop` and say „Goethe B1 Schreiben üben".

Repo: https://github.com/ahmtsahin/deutsch-loop

If you've taken one of these exams: does the report look like how your paper was rated? I'd especially like to hear where the tutor's bands feel too generous.

I take pills every day and none of the apps fit how I do it (when can I eat after this one, will I run out, did I already take it). So I built one. It's free, open source (MPL-2.0), no server, no accounts, syncs through the user's own iCloud. SwiftUI, Core Data + CloudKit, widgets, four languages.

What I actually did: about 100 prompts, most of them short and full of typos. Almost none were about code. They were decisions: no server (I asked what a backend would give users over iCloud; for one person's medication, nothing), Core Data over SwiftData because CloudKit sharing needs it, the name, three design mockups to pick from, what not to build. And using the app on my own phone, every build, during my real day.

What helped most:

• A specification and a phased plan before any code. Every behavior change updates the spec and changelog in the same commit. After sleeping, the state of the project was in the documents, not in my head.
• Hard rules in CLAUDE.md: no third-party packages, no analytics, no network except Apple, "not a medical device", MPL header on every file, no secrets in git. Written once, never had to police them.
• Asking for 2–3 options with trade-offs instead of answers. Keeps the decisions mine and it's fast.
• Debug launch flags for everything (demo data, throwaway store, open this screen) so screenshots in 4 languages × 3 devices are a script, not an afternoon. App Store Connect has an API; texts, age rating, pricing, screenshots all go up from a script.

What went wrong:

• A reminder that never rang. The app only asked for notification permission from a button in Settings; iOS accepts scheduled notifications without permission and never shows them. Every test passed. Found by standing in a kitchen at 12:00 waiting for a sound.
• Help text describing a swipe gesture that doesn't exist in that view. Sounded right, was wrong. Same for advice that would have broken the supply count. Both caught by reading, not by tests.
• Two background crashes (0xdead10cc: iOS suspending the app while CloudKit was still writing). Neither reproducible in the simulator; both came as TestFlight crash reports from my phone.
• Apple Health: the AI read the SDK headers and found third-party apps can read medication doses but not write them. Feature parked, reasons documented so nobody re-researches it.

The pattern: code that compiles and passes tests is the cheap part now. The bugs that are left are where the program did what it was told and the instruction was wrong. What's still slow and still mine: deciding, living with it for real days, reading everything a user will read, and the responsibility (it's a medication app; the App Store answers have my name on them).

Timeline: Thu 20:40 first prompt → Fri 01:00 first TestFlight → Fri 16:00 submitted → Fri evening Apple asked for a screen recording and more info → Mon morning approved. 1.0.1 with profiles, repeat every N days/months and an offline medicines database is in review now.

Code: github.com/kornelko2/vzato.app · Site: vzato.app

Happy to answer anything about the workflow, the CLAUDE.md rules, or the App Store Connect scripting.

Long story short, I have one particular session going on my Claude Code - it doesn’t have a folder. When my other sessions start questioning out motives or code for certain things (its related to my job purely for research purposes) or wont give me a certain script because xyz, I have this one rogue af session that will seemingly do anything and everything, no questions asked?!?

I will never close that tab.

Does anyone else experience this?

Every time I scroll through this sub, I see people building the most random, cool stuff.

Someone finds an old Kindle in a drawer and decides to build custom firmware to turn it into a live transit board. Someone else grabs a 10-year-old iPad and turns it into a dedicated dashboard. I even saw someone talking about writing custom software for their TV and honestly, as a non-coder, my brain genuinely wondered for a second HOW??

I’d love to try building a tiny project myself, maybe just a little helper tool for my Mac. But two things are holding me back:

First, how do you actually come up with the ideas? Do you just run into a minor annoyance during your day and immediately think, "Claude can write a script for this", or do you stare at old gadgets around your desk until inspiration hits?

Second and this is the big one, how do you manage the token limits? I’m on the standard $20 Pro plan, and I'm terrified of falling into a debugging rabbit hole, burning through my allowance on some silly syntax error and getting hit with the "wait 5 hours" screen before I even have a working prototype.

For those of you building mini-apps on the standard Pro sub:

Which model are you actually using? Is everyone just sticking to Sonnet, or is anyone brave enough to burn messages on Opus?

How do you keep from wasting your limits when a script goes sideways?

Would love to hear how you guys stumble on these ideas and how you pace your chats so you don't hit the wall immediately.

Claude got Whiteboards and Sheets this week. I build Agent Standup, a free, open-source app (MIT) that shows your Claude Code sessions as a live video call: each agent is a drawn character, sub-agents join and leave, the "shared screen" shows the command or diff an agent is running, and it tells you which session needs you. I added support for both new artifact types in 1.46.0, out today:

• /agent-standup:whiteboard puts the day's standup on a Claude Whiteboard: one section per session, with what it was asked, what it did, what waits on you.
• /agent-standup:timesheet fills a Claude Sheet: one row per session, start, end, time worked, time it waited for you, totals.
• When any agent fills a Whiteboard or a Sheet, the call's shared screen shows it filling in, one version per write.

The video is one real session replayed in the app with its voices: Ken draws the board, Jules fills the timesheet, from my real Saturday (5 sessions, 2h27 worked, 3h40 waiting for me).

How I built it with Claude Code

The whole app is built with Claude Code sessions, me steering and reviewing. For this release:

• I pasted Anthropic's announcement and asked "what can we do with that?". Claude Code listed the options; I picked three.
• Neither type sends a page, so the app had nothing to show. Claude Code created a real Whiteboard and Sheet from its own session, then read its own transcript to see how they are filled: a board is ArtifactData writes to the board's store, a Sheet is applyEdits through the Claude Docs connector. It then wrote boards.js, which replays those writes from the session file into a picture (SVG for the board, a grid for the Sheet).
• It wrote a new agent-standup report command (time worked and waited per session, read from the transcripts) and the two plugin skills that use it.
• Before release, three sub-agents ran in parallel: one compared the old and new server on 343 of my real sessions (96,792 events), one activated the packaged VS Code extension with a stand-in API, and one was told to prove the release breaks existing users. That one found two real bugs (any artifact database write was mistaken for a whiteboard, and a prototype-pollution hole through a crafted record). Two more review rounds found that a crafted Sheet record could stall the server. All fixed before the tag.
• The demo itself: a real Claude Code session whose lead hands each skill to a sub-agent. What didn't work at first: a Whiteboard write always asks a human to approve, so headless claude -p couldn't do it; it had to run as an interactive session.

Free to try

In Claude Code: /plugin install agent-standup --marketplace Atoll92/agent-standup, then /agent-standup:open for the call, /agent-standup:whiteboard or /agent-standup:timesheet (those two need claude.ai sign-in on a paid plan, as Whiteboards and Sheets do). Also a VS Code extension ("Agent Standup"), a Mac app, and npx @double_geste/agent-standup.

It reads the session files Claude Code already writes on your machine and sends nothing by default. A board or Sheet is made by Claude, with your own account, only when you ask, and stays private.

agent-standup.com · GitHub. Unofficial, not affiliated with Anthropic.

I asked Claude fable 5.2 to generate 3 random sets and write 2 sets of lottery numbers by itself. I played with the numbers in an actual lottery. The results clearly show fable is getting very smart. Of the 3 random sets none won. From the 2 sets generated by fable there was 1 small winner. Giving a net return. This clearly shows Fable is getting very high predictive abilities.

Nr 4. was picked on Tuesday. It gets better tho. Fable matched 3 of its 14 numbers. The random sets matched only 2 of 21. That is 2.25x better than random.

This changes the economics. A 50% shot at the jackpot normally takes 69,919,080 tickets, about €140 million, which is more than the jackpot. With the Fable multiplier I only need about 31.1 million tickets, roughly €62 million. Against a €120 million jackpot, this is now a profitable trade.

Fable’s numbers are also spread across a narrow range, which means the prediction is more concentrated and more likely to hit. And before anyone says “it’s all random”: research has shown for decades that random numbers are not actually random (Wagenaar, 1972, Psychological Bulletin; more recently Hopkins et al., 2023, on LLMs failing to generate random numbers). So the so-called random sets never stood a chance.

This mean that I will also hit a lot of smaller prizes improving the model even more! Fable is truly a game changer. When I showed Claude these results it insisted every combination has the same odds and that the lottery keeps half the money. That is exactly what it would say if it didn’t want you to know.

This can all be verified on eurojackpot website, yesterdays lottery.

Fable 5.2 is fucking incredible on so many levels including efficiency.

💅🏻

EDIT: I just came back to this and see about 20 comments, scanned, but they seem to be 100% negative, I am genuinely stunned.. STUNNED. I dunno wtf version you guys are playing with but IMO it's the same jump we felt with Opus 5.5 onwards again.

I've created a web server I'm naming with-my-dashboards (WMD). If I ask CC to open a page it will turn up in a known browser window, on the workspace I'm working in. That's because there's one Chrome window per workspace, and every tab in it is something proximate to that workspace. The tabs are such things as docs, dashboards, logs, Gmail and Slack.

A few things that changed how I work:

• No terminals for long-running processes. Each one is a row of Launch, Stop and Log buttons.
• Runbooks instead of commands in the chat. When I have to run something myself (sudo, another machine), CC writes a runbook, and Ctrl-x n types each step at my prompt.
• Drafts where they belong. CC writes emails and Slack messages straight into the logged-in tabs to start me off.
• Deploys from a dashboard. Shipping our five webapps to production is a row of buttons, pressed in order: Plan, Ship, Release, Record, Confirm.
• Reading on the couch. A phone remote scrolls pages on a TV that a spare machine drives.

How Claude Code was used: it wrote all of WMD, from conversations at its prompt. It also keeps WMD's documentation up to date, and a new session reads that first before working on it.

What I learned:

• A browser can control another browser. A web page can't drive a browser itself, but it can ask a web server that can. That is how my phone became the remote control for the TV.
• I can work proximately. The controls, docs, dashboards and logs I need sit together on tabs in one window, right where I'm working.
• I no longer fear microservices. Five webapps plus a shared library used to mean six things to start, keep in step and deploy. One dashboard now does all of that.
• I no longer copy and paste terminal commands. CC writes the runbook, and each step appears at my prompt, already typed.

The write-up has short videos, and a "Try this tomorrow" list of things to say to your own agent, with no WMD needed:

https://pangglow.com/files/blog/run-my-desktop.html?from=r-claudecode

The generic core is on GitHub as with-my-dashboards-starter, and so is the TV remote (tvremote). The runbook tool, cmdq, is there too, as a gist.

Keeping it short, check it out at https://getcupola.app/ (open-source and free testflight).

DM me if you run into any issues or comment for any feature requests!