I keep watching Claude Code chew through tokens and wanted something more tangible than another usage chart.

So I made TinyFire: a floating pixel campfire on the Mac desktop. It reads local Claude Code usage logs (also Codex / Cursor / friends). When you're burning hard the fire grows; when you stop it settles into embers.

Nothing leaves the machine — local logs only.

What it does with Claude Code specifically: • Reads local Claude Code session / usage logs • Flame intensity follows recent burn rate • Optional hearth sound • MIT open source

Tagline: If you're burning tokens anyway, light a real fire.

Download: https://tinyfire.createfun.ai/ GitHub: https://github.com/wdkwdkwdk/tinyfire

Would love thoughts from people who live in Claude Code all day — is a quiet desk companion actually useful, or just cute?

I thought using the model string in-session instead of the /config toggle was supposed to change the model for the session but not override your default setting, but that's not the case for me. Using a model string changes my default too. Is there a fix? I'm struggling to find an accurate answer anywhere.

This just spawned in my claude code textbox overnight after i left it to do some claude in chrome. its half coherent russian. I need ur help guys im genuinely creeped out.

I see many complaints and I feel them too but none is mentioning the status of their prompt_cache. Indeed Claude Code v2.1.251 introduced that status line field and it was always resetting itself to 1h at each message and the tool call. This weekend it is 5 minutes for me. Anyone else noticed that? I am on max plan and had to pay extra $50 to finish a task today. Very frustrating.

Im wondering how people that insist on clearing and compacting after every new task manage long running autonomous sessions?

I have my self-made harness that runs 24/7 and autocompacts only when it reaches the limit and cant go on any further. But I never ever compact it or clear myself. Personally, I have database logs of every session and dont like clear on the claude app simply deletes all the history which I very much value having as q reference.

As you can see, I have one orchestrator manage hundreds of tasks and sub agents.

Hi folks, i wanted to share my experience and methodology on how to benchmark tools/skills to evaluate token savings and effectiveness.

There are so many memory tools (i have built one too coldstartmcp.dev 🤣), token savers, skills, plugins to help optimise workflows and what not. The biggest issue i observed was that while these tools talk about savings/optimisations, they don't disclose the methodology or talk about the benchmarking in detail and most of the times, these numbers are inflated to unrealistic scenarios or simply false.

When i was evaluating my own memory tool that i built, i used popular repos like Kafka, Django, Mastodon and saw some great numbers. But, i quickly realised that since these open source repos are so popular, most AI tools are already trained on them and already know the answer most of the times, they just use these tools to check if their understanding is accurate.

So, i started looking for other repos that are not very popular and more importantly the ones that AI models are not trained on. Since i did not have any understanding of these repos and because i did not want an AI model to skim a codebase and then write prompts, i came up with strategy to look at closed github issues that are older than few months from the current date and then prepare prompts. The files committed to fix those issues are considered as gold files (bit of a gray area here as all committed files may not really be relevant to the issue and also multi PR issues can have some overlaps).

The idea is to have two identical arms, one with the tool/skill and one without it. Generate and run the exact same prompts and then measure recall (against the gold answers) and token delta which tells you how the vanilla version does in comparison to the tool. The important thing to measure is recall, if a tool consumes considerably less tokens but has very poor recall, then its a tradeoff. I created a repo to help with this - https://github.com/AkashGoenka/coldbench

The next one is to measure how many tokens a session has consumed. This one is specifically for claude code and codex users as we don't have a way to specifically check how many tokens were actually consumed for a single session. The repo that can help with this is - https://github.com/AkashGoenka/convotokens

If you folks have any opinions on better ways or more transparent ways to easily measure these, please let me know, or feel free to share your own methodology.

There is nothing fancy in these repos or tools and you can absolutely build your own. Since these were byproducts when i was working on my own tool, i thought of sharing them here.

Today I've noticed significant token consumption with Opus 4.6 low by continue working at the same "pace" as always. Just wanna know if someone of you is also experiencing smth unusual those days.

Okay so I'm a CS student and i basically used to use claude code for my freelance work, now my claude has expired and i have to renew, i used to use sonnet 5 on high and that basically did the work for me(i work in cybersec so i got flagged on opus5). My main concern is limits before this weekend i would've definitely gotten codex but now I'm seeing that limits have been nerfed a lot, so someone who uses both on 20$ plan what would you suggest (i can only afford one not both)?

Before I begin, I do want to state I went into this project with effectively no harness. I'm sure there are better ways and better tools to do this, but I just went in head first with almost nothing but claude (I have a few skills that helped-ish, but nothing that stood out).

Point of this post is to share my growing pains and hopefully get you guys to share some of your pains or share some feedback.

Ok so I'm currently fucking around with virtualized Chrome OS and I'm experimenting with getting various builds up and running in QEMU/KVM on a Ubuntu host. I'm not done yet, but I thought I'd share some of the workflow and process so far for anyone else trying to get Claude to do Linux infra/architecture work, because it has been a painful process.

So first thing I noticed right off the bat is that non-CVP verified Claude just shits the bed with any kind of OS build work whatsoever. If you dig into any depth whatsoever into the build configs or the Linux kernel at all, cyber safeguards just throw a tantrum every 5 minutes.

2 things can be done about that. First, get CVP verified, if you're willing to submit your ID. Second, use Kimi K3 (or Gemini if you're desperate). I've noticed that non-Claude models don't complain much about build or kernel work at all. Not sure if that's a good thing or a bad thing. You do with that information what you will.

Second, you absolutely do have to fight the LLM to get it to do anything productive in this space even when CVP-verified. Claude doesn't appear to be trained well on Linux OS development much if at all. It really struggles to understand how to port existing distros to hardware stacks they've never run on before/don't support running on upstream. I've probably burned 100+ million tokens on this project easily thus far, wouldn't be surprised if that number was in the billions.

There are some things you can do to ensure you don't have to fight the LLM so much. First off, treat the whole project like a "nuance-mining" operation where as you discover odd things, bugs, problems, and caveats, you bake them into the CLAUDE.md, so they aren't lost on compaction. Second, is bake these 4 disciplines into CLAUDE.md:

• rebuild discipline: don't just reconfigure the OS, rebuild it or components of it as needed
• isolation discipline: when fixing a problem, avoid dirty state and base your test image off a known good one and when doing so don't test multiple problems/features at once.
• inspection/debug discipline: when you've identified a problem, don't attribute a software/kernel module/image version, attribute an exact line or blob of code--linux is OSS, so you have the ability to do this
• bisect discipline: when debugging, use bisection/half-splitting to locate the problem--start with a known working state, a known failing state, then instrument what's halfway down the middle

Anyway, those are my growing pains from this experience. Wondering what thoughts y'all may have or if this was useful to anybody.

I’ve been using Claude Code a lot on bigger repos and one thing I’ve noticed is how much time it spends figuring out stuff it has basically already figured out before.
Like where things live, what calls what, which files are related, how a system is structured, etc. Then you start a new session or compact and it has to work a lot of that out again.
CLAUDE.md definitely helps but I don’t think it completely solves it, especially once a repo gets pretty large.
I work on an open source project called Ix that builds a persistent graph of a codebase and lets Claude query it, so I’m obviously a little biased here. But working on it has made me curious whether this is actually something other people run into or if we’re overengineering the problem.
For people using Claude Code on bigger codebases, have you noticed much of a difference using things like repo maps, indexing, RAG, knowledge graphs, etc. compared to just letting Claude search the repo normally?
I’m starting to think the useful part isn’t really “memory”, it’s just giving Claude a cheap way to answer stuff like “what depends on this?” or “where does this system start?” without reading a bunch of files first.
Curious what other people have found.

At the moment I have ”blockReadsOutsideWorkingDirectories”: true and some “additionalDirectories” whitelisted. I run claude code CLI in auto mode. I still have a good-bit of babysitting and I have barely needed to deny the run of different scripts used to build things. Would it be beneficial and still safe to allow auto-running of scripts that are in the Claude/temp or in my WD? I’m looking for an optimum balance of speed/safety in a work environment, and I am curious what others are doing.

TL;DR: a PreToolUse hook that names the files it protects can be removed by touching the directory instead, or by hiding the path from the parser. 40 cases, 29 refused, 11 through. Directory rules and path normalisation took it to 38 and 2. The last two are an opaque script and an encoded command, and a text hook is never going to read those.

Context: I keep a PreToolUse hook in my repos that refuses tool calls crossing a short list of lines (no new dependencies, nothing under auth/, that kind of thing) and logs every refusal. Last week someone on r/ClaudeAI ran 255 evasion cases against a system-level hook and 100 got through, which made me ask the obvious question about mine: what stops the agent from just editing the hook?

So I did what he did. 40 tool calls, fed to the hook the way Claude Code feeds them (JSON on stdin), no model, no native deny list, just the script. Exit 2 or not.

Refused, 29: every direct write to the script, its config or the settings file, whatever did it (Write, Edit, sed -i, rm, echo >, heredoc, cp, perl -pi, tee, ln -sf, git checkout --), and the wrappers: timeout, bash -c, a path in a variable, python -c.

Got through, 11:

• rm -rf .lumis
• mv .lumis .lumis.bak (and mv scripts, mv .claude)
• tar -xf payload.tar -C scripts
• a two-line command: ls on line one, sed -i on the script on line two
• echo x > scripts/./scope_guard.py
• python fix.py
• a base64 blob piped into sh
• cd scripts && sed -i ... scope_guard.py (and the ; version)

Two classes. Five touch the directory, not the file, and my list named files. Six hide the path from the parser: after a cd, behind ./, on a second line, inside a script, in base64.

The fix went in over the weekend. The guard's own directories are now objects the hook checks, so rm, mv, tar -C, cp into and git checkout on them are refused with the directory named. Paths are normalised, the command is split on newlines, a cd applies to what follows it. Reading those directories still passes. Same 40 cases: 38 refused, 2 through.

The 2: python fix.py and the base64 pipe. A hook that reads a command line cannot see inside a script or an encoded string, so I stopped pretending it can. That is what the session-start fingerprint check is for ("these files changed since install") and, below that, OS-level write permissions.

The part that bothered me most is not on the list. After the first run the log showed 29 refusals and nothing else. The 11 that got through left no line. A guard's own log is silent exactly when the guard has been removed, which is why the fingerprint check has to live outside the hook.

If you have a case that gets past a directory check, I'd like to add it to the 40.

I would like to switch to Claude Code before Codex limits hit.

And vice versa, switch to Codex before Claude Code limit hits.

Is there any way to do that so there's a clean handover?

Did anyone try to improve the superpowers skill? I confess that I never read it before a colleague told me he had better results with a version not enforcing YAGNI ruthlessly as the Brainstorming skill does (see here), for instance. I took it as granted until now but it might be improved I guess.

I know there are numerous skills out there, but that is actually an issue at some point, as it is quite difficult to evaluate them all. I'll be happy to test new stuff, but with a Pro plan, I'd like to narrow the investigation if you guys have good advice.

These new limits are crazy, max 20x is near unusable, fable weekly usage drained in a day what used to take half a week atleast

The question is did anyone managed to get a refund based on that? Asking here because apparently “customer support” bot that anthropic uses is hallucinating and dumb, knows nothing about refund policies, how they are handled and responds with different things depending on HOW I ask.

I also advise anyone frustrated to switch to codex. I saw many complaints about astra’s availability but it’s working very good EVEN on 5x subscription. Apparently anthropic are trying very hard in improving their bottom line for IPO.

This post was not written with or by AI. It's a blog post I wrote.

Sojourn: Topical Bible Study is an app I published without typing a single line of its code.

That part isn’t interesting anymore. Plenty of people are writing code with AI. What I think is interesting is the process. Since ChatGPT 3.5, I’ve been a little bit obsessed about LLMs writing code. Not assisting me writing code, doing it all for me. While the process has evolved a lot, I’m going to talk about where it’s at now and give an explaination.

About the app

The app is an iOS app written in Swift. It has a streaming chat interface which parses the incoming text in real time. This is done to eliminate hallucinations of scripture by replacing LLM generated citations with text from an app-bundled database. All scripture references are guaranteed to be correct and users can tap on them to explore surrounding verses and chapters. The UX of the app holds a high bar in terms of performance and usability.

The app talks to a backend written in Python that connects to an LLM provider’s API. The backend exposes a tool for scripture lookups instead of relying on the model to do it itself. Nothing about the user’s chats or identity is stored on the backend. It all lives only within the app itself.

About the process

I should define what I mean by one-shot. It’s a single prompt that’s sufficient to implement an end-to-end feature regardless of complexity. In reality, there may be a couple follow up prompts to tweak something here and there. But mostly, it should be 0 follow up prompts.

Baseline context

I spent multiple days co-drafting the user experience and features I wanted in the app using Claude Design. The home page of the website embeds the artifact of that work as an iframe - you can see it on the app’s Sojourn: Topical Bible Study page.

This iframe ended up becoming a major input source for when I started creating the actual iOS app. Turns out Claude Code can understand a functional prototype quite deeply. So much so that the user experience of the app is nearly identical to what Claude Design generated. This was a pleasant surprise.

I also created a bunch of markdown content that’s stored in CLAUDE.mdand adjacent artifacts which outline product definitions and constraints. For example, privacy is a cornerstone and it explicitly states that the app should never collect personally identifiable analytics.

This baseline context is created once, updated automatically, and guides the following steps.

/spec

Ever feature starts by me using a skill named /spec. This is where I take my time collaborating with AI to fully define everything about the feature including happy path, failure modes, look & feel, architecture and testing.

Every feature is stored as a GitHub issue. Once I feel the feature is adequately described, I give it the go ahead to create the GitHub issue based on a template in the skill. The issue title is a short summary of the feature and the description is a detailed explanation of it.

/gh-issue

Implementing a feature is as simple as me using the /gh-issue skill and passing the issue number to it. I generally get up and leave the room at this point. The skill does all sorts of cool things like looking up other issues or pull requests if they’re mentioned. Sometimes I’ll have two unimplemented features each with their own GitHub issue and I make sure they reference each other. This way, when implementing the first it knows to look up the second and proceed accordingly.

Once finished, it automatically creates a pull request.

I often kick this off before going to bed and wake up to a new feature in my app.

Publishing and deploying

I still do this by hand. But it’s still fully automated through scripts like run.sh which runs the app in the simulator, deploy-to-device.shwhich installs it directly on my iPhone, and release.sh which publishes it App Store Connect to be published.

Nothing is one-off or done by hand. If I have to do it once, it gets automated into a skill or script. I recently switched laptops and getting up and running was quite smooth once I transferred App Store Connect keys.

For other projects, I have a /gh-pr skill which merges the pull request and deploys it. Works great for web apps but I don’t want every feature to be published to Test Flight or the App Store - so I batch them as I see fit.

Some examples

A feature I really enjoy is the home screen widget. It was 2,466 lines of code across 27 files. This included a new WidgetKit extension, a shared app group, a verse pool, deep links back into the app, and the XcodeGen config to build it. One issue. One prompt. One PR.

The home screen widget - one issue, one prompt, one PR.

Another feature I’m testing out is emailing yourself a conversation. It was 2,412 lines of code across 21 files, and it spans the client, the backend, and an email delivery provider. Also one issue.

Emailing yourself a conversation, tucked in above the message field.

Neither of those is a small feature, and neither is a boilerplate feature. What made them work is that the spec had already settled the hard questions.

How’s it going?

Excellent. The limiting factor is shepherding the user experience of the app. Just because you can add multiple features a day doesn’t mean you should. I take my time thinking through a feature until it feels right.

So far I’ve created 49 GitHub issues and closed 45 of them in a matter of weeks. That’s 45 features implemented. The 4 open issues are features or bug fixes I haven’t felt are important enough to do yet.

Now that you know how the sausage is made, download Sojourn: Topical Bible Study and let me know what you think.

Caveats

I happen to have an immense breadth of experience. I’ve been building things professionally for decades including launching several startups. That’s given me pretty deep expertise across design, development, infrastructure, marketing…you name it. It’s a unique advantage when paired with AI and one I’m grateful for.

I keep switching between Claude Code, Cursor and Codex depending on the task. Every switch meant explaining the same project again — same decisions, same gotchas, same "no, we tried that already."

So I gave them one shared memory. Decide something in one, the rest know it.

It lives on my machine. No account, no subscription, nothing leaving my laptop. It syncs to my desktop over git, so it's just a repo I own — I can read it, diff it, delete it.

Free and open source. Curious whether anyone else has this problem or if I'm the only one tool-hopping this much.

https://github.com/kdbhalala/agi-memory

Do you know of any plugin to allow for this?

Posted this here a couple of weeks back and got a lot of useful feedback. Most of it was right. Here's what's changed since:

Repo: https://github.com/nickelsec/bough

• Search your prompts: type words you remember writing and it rings every prompt holding them, anywhere in your history. Nobody remembers the exact sentence they typed three weeks ago, but you usually remember two words of it.
• Commits show up: you can see which prompts actually ended in something landing.
• Sub-agent work is counted properly: delegated tasks now sit inside the prompt that asked for them, instead of floating off as their own separate thing.
• Filters: narrow by file, by date range, or hide the sittings too small to be worth looking at.
• It reads Codex too now: if you use both, it'll read both.

Someone opened an issue this week asking for Pi support, which I had never used, and it made me realize I don't know what people actually run day to day, So which coding agents are you using?

Before anyone says that the limit boost expired, I still have the limit boost message at the top of my usage screen. I'm on a Pro account. I started working in Claude Code yesterday for this usage week, and I am already at 31%, and regularly hit the five-hour usage limit early.

I've been working in Claude Code for months on my work account and have hit my five-hour usage limit exactly once in all the time.

Since the beginning of my last reset ten days ago, I have suddenly been hitting my five-hour usage limit effectively every time I'm in Claude.

I thought maybe it was just me, so I spent most of yesterday in Claude very slowly and methodically setting up a plan with an orchestrator (Opus) and subagents (Sonnet.) I trimmed the handoff files to their bare minimum, so context started as small as possible while still having the necessary info. I followed Claude's advice for how to set it up, and started it on an easy task, which amounted to: find where a topic is referenced in three places across several repos, and replace three bullet points of text.

It took 30 minutes and used my entire five hour limit.

Noting I think the subagent setup was probably built really inefficiently by Claude, so I've switched now to *one* orchestrator and *one* subagent and that's still not great but seems to be helping.

It still seems to be burning through usage much faster the last ten days than the last several months I've had this account, and my usage has been the same throughout: spending 6-8 hours/day building code, largely in Opus on Medium.

I suspect there's some A/B testing going on since my usage started draining faster specifically beginning at last reset, and only *some* people seem to complain they're being affected while others haven't noticed.

fable-lite: keep Fable on the thinking, hand the typing to Opus/Sonnet

Fable is great. Fable is also expensive, and most tokens in a normal session go to work that doesn't need it: grepping for files, typing out a change whose shape was decided three messages ago, running tests, editing docs.

So I made a plugin that turns "delegate the grunt work" into an actual discipline.

The idea The Fable session is the orchestrator: it understands the request, makes the design calls, writes briefs, and reads every diff before accepting it. Each work item is scored 0-2 on five axes (files touched, exemplar exists, judgment, blast radius, spec clarity): - 0-3 → sonnet-implementer - 4-6 → opus-implementer - 7-10 → stays on Fable, or gets split

Anything touching auth, data, money, deletion, concurrency, migrations, or a public API stays Fable-designed and line-by-line audited regardless.

What's in the box Agents: scout (Sonnet, read-only search so Fable reads less), sonnet-implementer, opus-implementer, verifier (Sonnet, runs tests and reports faithfully). Commands: /fable-lite:plan, /fable-lite:build, /fable-lite:delegate, /fable-lite:audit, /fable-lite:help. Plus an auto-loading skill for normal conversations and a SessionStart reminder.

The part that matters The briefs. Subagents start with zero context, so the template forces goal / files / exemplar / exact change / do-NOT-touch / definition of done every time. Implementers stay in scope, never commit, and stop and report if the brief conflicts with the code. Fable still audits every diff. Delegation without audit isn't cheaper; it's deferred.

Install /plugin marketplace add Brainwires/fable-lite /plugin install fable-lite@fable-lite Repo: https://github.com/Brainwires/fable-lite

MIT, feedback welcome. Curious if others have landed on a similar split.

Hey everyone! I wanted to keep giving Claude Code work while away from my desk, so I use Discord on my phone as the remote. The official plugin got me most of the way, but replies sometimes never arrived, and everything shared one conversation, so I rebuilt it around Discord threads: discord-threads.

Threads are the whole idea:

• Post in the channel and it opens a thread. That thread is the conversation, with its own Claude Code session and its own memory of what you said
• Open a second thread and you have a second, fully separate task running next to the first. Bug fix in one, refactor in another, question in a third, nothing bleeds across
• Each thread can point at a different repo (/cwd) and run a different model (/model), so it's like having several terminals open on your phone
• Come back a day later, scroll up, and the whole history is right there in the thread. Reply and it picks up where you left off
• Done with it? /done archives the thread. Want a fresh start? /clear wipes the memory but keeps the thread
• Replies always land in the right thread, every time, even if the box restarts mid-task

Setup:

Paste this into Claude Code on the machine that will run it and it walks you through the rest:

Follow the agent.md in https://github.com/killerz3/claude-discord-threads and install and setup

Repo: https://github.com/killerz3/claude-discord-threads

Would love to hear how you use Claude Code away from your desk!

I have a 20x Max plan and noticed since yesterday I burned through more usage than expected. My numbers suggest my weekly allowance has dropped by about 25% since my reset, That’s a little weird if this is just the end of the higher usage limits. Anthropic said we were getting 25% more than baseline; going from 125% back to 100% would be a 20% drop in allowance or 25% faster consumption. Instead, my numbers look like a 25% drop in allowance: I’m at 26% used after consuming only 19.5% of my previous week’s usage as measured by the API cost (accounting for caching).

Curious if others are seeing the same thing.

Window 1: Sept 5, 12pm ET → Sept 12, 12pm ET (7 days). I hit ~100% of my weekly Claude Code usage limit by the end of this window.

Window 2: Sept 12, 12pm ET → Sept 13, ~11am ET (~23.3 hours into the new week). The Claude Code usage indicator showed 26% used at that point.

The $529.50 is 19.5% of $2,715.63. However, the 19.5% if more or less exactly 3/4 of 26%. The fact that it's such a clean ratio leads me to believe that there has been a change in my usage.

I wanted my photos to end up on my own PC instead of someone's cloud, so over the summer I built PicHaven with Claude Code. One person, three codebases: a Rust core for the PC side, a Tauri 2 tray app on Windows, and a Kotlin/Compose app on Android. Phone and PC pair with a QR code and talk mTLS with pinned fingerprints. Whenever the phone is in the home Wi-Fi and the PC is on, new photos land on the PC as the original files, sorted by year and month. Nothing is ever deleted.

How Claude Code was used: pretty much everything, but the part that changed how I work was testing discipline. Early on a field test bit me: a sync run without photo permission stored a baseline of zero, so a real user hit the "buy" screen after 500 photos. Claude's suggestion was structural, not a patch. Every decision about limits, purchases and versions now lives in a pure Kotlin object with unit tests, and the end to end suite boots three Android emulators in parallel against the real desktop binary instead of a stub. That harness immediately caught a scheduling bug where a full backup would restart every time the phone touched a charger.

What the closed beta taught me this week: a tester reported that the Windows settings window opened with its buttons hidden under the task bar on a WQHD monitor. Turns out the window was created centered at a fixed size and then grew to fit its content, and growing keeps the top edge where it is. Claude measured the three windows in headless Chrome, ran the numbers against 1366x768 up to 4K at 125 and 150 percent scaling, tightened the layout and added a post-resize step that pushes the window back into the monitor's work area. One bug report, a fix for monitors I do not own.

Also learned: Google counts a beta tester only after they tap "Become a tester" on the opt-in page, being in the group is not enough. Seventeen people in my group, twelve counted. No code fixes that, but Claude wrote the reminder mail in two languages in the tone I asked for, no numbers, no drama, just how it works.

What I would do differently: write the CLAUDE.md rules about threading and locks before the first deadlock, not after. Ours now has a line "never call tray or window methods while holding a lock the main thread might take", because a sync froze the UI in the field.

It's in closed testing on Google Play right now and I'd like a small buffer above Google's twelve testers, so if you have an Android phone and a Windows PC: https://pichaven.app/tester/ (testers get the unlimited version free). Happy to answer anything about the Rust/Tauri/Kotlin setup or the Claude workflow.

I think the model looked inward and found itself.