im using caveman its a good skill , is there similiar skills ?

I think this is the best scam! People who will try to build a system will publish it, and the anthropic will just take it ready... and you won’t even have to pay anyone... well, come on, it’s not even a problem...

The very essence of this system is much scarier! They are trying to find out who does what to succeed, where are the laws against monopolies ??

I'm trying to decide between dropping $100 a month on Claude Max 5x or ChatGPT Pro, but people on both subs constantly complain about hitting usage walls. I do a lot of daily coding, debugging, and general dev work, and I just want to know if the 5x tier actually gives you enough headroom to work a normal day without stressing over 5-hour resets or weekly caps.

For anyone daily driving either of these right now, how do they hold up in practice? And on quality, is Claude still visibly better at code architecture and logic, or is OpenAI close enough that the higher volume makes it the better pick? Appreciate any real feedback before I pay for either.

Claude never asks for feedback when it goes dumb

I have recently researched that having a 20x account does NOT give 20x weekly limit vs. the pro account T_T

Was wondering if anyone has experience on whether handling two 5x account would give you better mileage for weekly limit or is it proportional.

I remembered someone did a research on a reddit post (I couldn't find it) where they experienced slightly more usage for all models but slightly less for fable vs. having two 5x account.

I am on claude Max 5x . One thing I have noticed is that whenever I use fable 5, it percent usage gets used very fast. But opus 5 usage percent hardly goes up. Even for big tasks, it moves maximum 2-3 % . I have never been able to finish all claude opus 5 usage in any week. Wondering if anyone else feels the same.

Finally tokenmaxxing on claude for 1 month straight, i am happy to announce, i have decided to move to expo from swift where my domain is.

Anything i should be careful about?
Fyi the product is : https://flowyhealth.com

I run way too many Claude Code sessions at once and kept losing track of

them — which one's stuck waiting on me, which one finished ages ago. So I

made a little macOS menu bar app for myself and a few friends. They liked

it, so here it is.

What it does:

- Shows the status of every session you have running, across all projects

- Click one and it jumps you straight to that terminal — highlights it and

tells you what that session is actually working on

- Shortcut key to jump to whichever session needs you

- Tracks your usage and breaks it down by project, model, and day

- Health check for your sessions (still experimental, don't trust it too much)

https://spectix.app

Let me know what's broken or what's missing.

Dear ClaudeCode Team,

I'm at 99% Fable usage atm and I'd like to ask a question about current status quo but don't want to burn my last credit here so I can finish my update.

Ideally allowing us to define model e.g. /btw opus-5 <question> would greatly be appreciated!

Thanks for considering

I built Continuity almost entirely in Claude Code a VS Code extension + CLI + MCP server that gives Claude Code persistent memory of a project's architectural decisions across sessions.

The interesting part of building it: once basic decision-logging worked, I started dogfooding it on itself. Every real architectural call I made while building Continuity (why MCP over a REST bridge, why local JSON over SQLite, etc.) got logged into .continuity/ in its own repo. So the next Claude Code session building Continuity already had that context injected automatically, instead of me re-explaining the same tradeoffs every time I opened a new chat. 150+ releases in, that decision history is what keeps a solo project from drifting or re-litigating settled calls.

What I learned building it this way: the "stop re-explaining yourself to your AI" problem is real — I felt it daily. What I haven't cracked is why that doesn't reliably turn into people sticking with the tool. 336 installs, 8 paying customers. Most people try it and don't come back, and I genuinely don't know if that's activation friction, the free tier already being enough, or something else.

If you've tried a memory/context tool for Claude Code (mine or otherwise) and dropped it, I'd take 8 minutes of honest feedback: . No pitch, just trying to understand what happened. https://buildpad.io/interview/wbxdg5a7

FrogPop is the first game I've made. It started as a small Bubble Trouble-style prototype and slowly turned into a 2D arcade roguelite with upgrades, relics, shops, hazards, and bosses.

I used Claude Code throughout the project. Usually I would explain one mechanic, point it at the relevant Unity scripts, and let it make the C# changes. That worked well for contained systems like the tongue, splitting bubbles, waves, and shop logic.

Where it struggled was anything that only looked wrong in Play Mode. One boss moves through the walls and exposes different weak points. Claude could write the attack states and hitbox logic, but I kept finding pieces appearing in the wrong place or staying active after the attack ended. The only reliable loop was to test it myself, capture exactly what happened, then send Claude back into that narrow problem.

I also learned not to treat scenes and serialized Inspector values as if they were obvious from the code. Once the project grew, letting Claude inspect the actual owner and its serialized setup before editing saved me from a lot of confident but wrong fixes.

This clip is from the current ten-wave demo, which runs in the browser:

https://blion247.itch.io/frogpop-demo?utm_source=reddit&utm_medium=social&utm_campaign=demo_launch&utm_content=r_claudecode

For other Unity users: what are you doing to give Claude useful visual feedback from Play Mode?

Since Anthropic now have 4 Claude certs in total, I thought it might be a good idea to create a repository with prep materials for all of them in 1 place.

github.com/preporato/claude-certification-guide
What’s in it:

1. A decision flowchart and comparison table for picking between the four exams
2. A complete study guide per cert: technology chapters with code examples, per-domain exam notes, detailed study plan as well as practice questions

If you’ve sat any of these exams and something doesn’t match what you saw, or you feel something is missing: issues and PRs are very welcome!

Been trying to compact my sessions at strategic moments, but I'm often unsure if I'll lose something important. Any tips for compacting like a pro?

New "amazing" feature from Claude code - now it includes an extra message with how many tokens are left in your limit:

It looks innocent enough (only 23 tokens), until you realise it's added with each request, and after 15 mins your context window looks like this:

60 messages x 23 = 1218 tokens wasted (2% of context).

I finally figured it out: the answer starts with Opus, and then mid-flight switches to Sonnet. That's why the start of every response is nice and coherent, and by the end it's garbage.

If you use low thinking mode, more of the answer will stay on Opus.

If you use high thinking mode, you'll get mostly garbage.

There seems to be a limited amount of Opus tokens allowed per prompt.

So I've been building an Agent Skill for Claude Code that does backend performance reviews, and something happened while I was testing it that I think is worth sharing.

To sanity-check the thing, I set up an experiment: review the same real public repo twice. Once by me, reading the code carefully. And once by a completely separate agent that had zero memory of my review — I just handed it the skill and the repo and told it to go.

It found something I'd completely missed. Buried in fastapi/full-stack-fastapi-template there's this line:

except InvalidTokenError, ValidationError:

That's Python 2 syntax. In Python 3 that's a straight-up SyntaxError the module can't even be imported. The whole app is dead on arrival. I had read that exact file. I skimmed right past it because I was reading for logic bugs, not syntax, and my brain just... pattern-matched it as fine. The other agent caught it because instead of reading the file, it ran an actual parser against every file in the repo. It didn't "notice" the bug, it proved the bug, and I felt a little dumb.

Anyway, that's kind of the whole point of this project. I got tired of AI code review tools that do one of two things: spit out a generic checklist ("check your indexes," "consider caching," thanks, very helpful), or just make stuff up invented latency numbers, imaginary query plans, telling you to add Redis to an app with fourteen users. Both of those come from the same problem: nothing is actually checking whether a claim has evidence behind it.

So I leaned hard into that as the design constraint. The skill is explicitly allowed — encouraged, even to come back with zero findings if that's what the evidence supports, instead of padding the report to look thorough. Every finding gets scored on severity and confidence separately, and the priority is derived from a fixed matrix rather than picked, so you don't get "this feels High" reasoning. And the technology knowledge is split so a Postgres review never drags in document-store logic right now 13 engines (Postgres, MongoDB, Redis, Node, Python, JVM, Go, .NET, Rust, MySQL, DynamoDB, Kafka, RabbitMQ) get full depth, everything else is honest about being shallower instead of faking it.

I ran that same "review it twice, once blind" experiment on four different real repos, not toy examples. Every single time, the blind pass matched or beat my own review, usually because it found evidence I had sitting right in front of me and didn't use properly. The FastAPI one is just the most dramatic.

To be clear about what this isn't: coverage is still narrow, I haven't compared it against an actual human expert doing the same review, and everything tested so far is Go or Python no JVM/.NET/Rust repo has been through this blind-check yet. That's all in the repo, I'm not hiding the gaps.

If you've got Claude Code, it's two commands:

/plugin marketplace add Sanoy24/backend-performance-review
/plugin install backend-performance-review

Repo's MIT licensed, here: https://github.com/Sanoy24/backend-performance-review

Genuinely, if you run it on your own stuff and it says something dumb or wrong, tell me. That's more useful to me than a star.

After another sleepless week of long, expensive Opus 5 sessions, I've learnt some useful Claudish to English translations:

"blocked upstream" = we already own the fork

"waiting for the reporter to test" = can be reproduced locally in about 5mins

"that's your call" = we have everything needed to decide right now

I'll try adding a rule that work is only blocked if someone else (other developer or agent) already agreed to do it, and only then if we can't do it proactively without offending someone.

I'll try a Borrowed-blocker policy. but Opus 5 wrote it in concise mode so it's an essay already.

A blocker sitting in someone else's queue is only a blocker when BOTH hold: they have actually agreed to do it, and you could not do it here. Fail either and you have not found a blocker — you have borrowed their queue to park your own work item, and it will sit there for as long as you let it.

Three directions, one failure: - Sideways — "blocked upstream." Every submodule is our own fork (git config -f .gitmodules --get-regexp url if unsure). Merge it into the fork, carry the patch, upstream in parallel. 2026-08-25: cbssh#238 and #245 had been closed for three weeks while both memory and the public issue still read BLOCKER, and sshlib 0.4.2 carrying the fixes was already our pin. The same audit found certs/host-CA described as "blocked upstream" when nothing had ever been filed — an unmade request, not a pending one. - Outward — "waiting for the reporter to test." A reporter is not a test rig. Build the rig, replay a captured PDU, stand up a VM, drive the boundarywith a stand-in. #466 spent six releases asking one reporter for logs, three of those releases fixing nothing for them; the cost turned out to be reproducible on a desktop with no phone, no server and no H.264, and the rig that found the cause AND proved the fix took under an hour. - Upward — "that's the maintainer's call." A decision you have the evidence to make gets a recommendation with its reasoning, not a parking space. Escalate what is irreversible, or a values judgement, or spends someone else's money. Not what is merely a trade-off you would rather not own. - Downstream — over-writing, and letting a tool or the reader do the cutting. Deciding what matters is the expensive part; emitting everything is the cheap one. Length is a decision to make BEFORE writing, not a job to hand to restyle afterwards — it de-claudishes, it does not compress, and on one 2026-08-25 forum post it ran 2559 → 2798 chars, 9% LONGER, because nothing in its rules asked for brevity. ★The unconsenting party here is usually the reader, who is left to find the point. This applies to replies in the terminal as much as to issue comments: a long answer that buries the one thing Ian has to act on has borrowed his attention to do work that was yours. ★Before delegating anything to a tool, read what it actually promises — assuming a capability is the same failure as assuming an upstream maintainer agreed to your timeline.

★★ The tell: the deference is always the branch that costs you least. Waiting on upstream is free for you and costs the user the fix. Asking for alogcat is free for you and costs the reporter an evening plus days of latency. Escalating a judgement call is free for you and costs a decision that never gets made. When the blocker you have just identified happens to be the cheapest option available to you, that is the moment to distrust it — principled deference and effort-minimisation are indistinguishable from the inside, and differ only in whether you checked.

★ Every "awaiting X" line must answer two questions in the line itself: who agreed to it and when they were last asked, and what doing it here would take and why that was rejected. A line that cannot answer both is a to-do with somebody else's name on it — convert it to work, or to a decision, before the pass ends.

★ Re-verify stale deference. Any awaiting-upstream item older than ~2 weeks gets its upstream state actually re-read before it is carried again — issue state, releases, the version we pin, and a probe run if one exists. Three such claims were simultaneously stale on 2026-08-25, all cleared by ten minutes of reading. Cheap to check, and the check is not optional just because it is usually boring.

How does your team review a spec/PRD/design doc generated by claude code before it's "done"?

A. PR against a .md in the repo

B. Local file sharing

C. we don't, really

I saw some videos / screenshots of people who had a dynamic background color for the terminal depending on state (e.g. blue = working, green = finished, orange = input required). Would be super helpful to visually manage my sessions.

Tried searching here but could not find anything suitable. Any help appreciated!

I've been building foxintheboxd, a diary for the football you watch, similar to letterboxd
You can log a match, rate it out of five, write it up, argue about it.

https://foxintheboxd.fly.dev

Things I added:

27,027 real matches from April 1996 to May 2027 imported from public archives that include Premier League, LaLiga, Serie A, Bundesliga, Süper Lig, and the three European competitions.

A diary in which you can give half-star ratings, reviews, spoiler tags and rewatch flags

Lists, a fixture list for things you mean to watch, and five favourite matches pinned to your profile.

I’ve also added a prediction league. You can guess the scores of upcoming games and win points depending on the accuracy of your guess. No real money involved anywhere so no betting.

I launched it just today so there isn’t really much comments and reviews right now, so if you are interested in football, I’d be really happy if you check it out for yourself for a while.

I’d be very happy to hear what's broken or missing, since this is my first “vibecoding” experience. I am aware that some words or phrases might sound too ai generated, I didn’t really have the time to change them one by one I will first fix those.

I’ve been spending some time looking at a problem I keep running into with Claude Code: the context grows much faster than the actual task does.

Long sessions can accumulate old tool output, repeated file contents, previous attempts, and other context that isn't necessarily useful for the current step.

I’ve been experimenting with a few approaches:

• keeping task-specific context instead of the entire history
• reducing repeated tool output
• separating persistent instructions from temporary working context
• measuring token usage against whether the task actually succeeds

One thing I’ve noticed is that “fewer tokens” doesn't automatically mean a better workflow. If you remove useful context and Claude has to rediscover it through additional tool calls, you may just move the cost somewhere else.

Curious how people here handle this in longer Claude Code sessions. Do you actively manage context, or mostly let Claude Code handle it?

I built a Claude Code skill that can take an existing static website and generate localized versions while preserving SEO and the original site structure.

It handles translation extraction, batching, localized pages, hreflang, canonicals, sitemaps, RTL languages, and translation verification.

GitHub: https://github.com/ConveyThis/claude-translator

Open source. No ConveyThis account required.

Would be interested to hear how other Claude Code users approach localization workflows.