1. Very good, very capable model launched
   
2. Token-caching issue burns my weekly limit instantly
   
3. Perfectly timed OpenAI Astra launch

If I asked Opus, it would call this a footgun 🤓

I can sometimes be lazy and I tell Claude to just fix things for me and this time it didn't turn out so well. I was working on an iOS app and needed to set the clock to a specific time to create some screenshots. I told Claude to fix it for me as I had to do some other stuff. To fix it Claude told me to run sudo systemsetup -setusingnetworktime off && sudo date 090306494026.00 (DO NOT RUN THIS) and in a weak moment I just ran the command without thinking any more about it. It was stupid, but these things can happen to the best of us.

The command above set my Mac to the year 4026. In seconds it froze. It would boot, show the Apple logo and complete the loading bar, but then I only got a black screen with a mouse cursor. The startup disk was gone. It felt like I had ended up in purgatory. Recovery mode behaved the same way. No matter what I tried, I could only get to a black screen and see the mouse pointer.

What followed was several hours of frustrating troubleshooting. I tried safe mode, recovery, fallback recovery, bootable media and multiple DFU Revive attempts from another Mac. DFU kept failing with error 4042, even after trying different cables, macOS versions and IPSW files.

The breakthrough came after I found someone with a similar DFU issue who had fixed it by installing Xcode on the host Mac. Before that, I had also tried a DFU Restore, which failed, so I can't say for sure whether that changed anything behind the scenes. After installing and launching Xcode, I put the Mac back into DFU and tried Revive again using the same cable and setup as before. This time the firmware actually started updating and the Mac finally made it into Recovery Assistant. Any way, I think this is super weird.

The ironic part is that changing the Mac's system clock was never necessary in the first place. The iOS Simulator has a proper command for overriding the time shown in the statusbar. I also wonder why Claude (I think I used Opus 5 High) would recommend such a destructive command in the first place?

Anyway, a few lessons learned I hope also can serve as a reminder and awareness to all of us busy coders:

• Being lazy is not always efficient.
• Don't blindly run commands just because an AI tells you to.
• Be especially careful with sudo and commands that change system-wide settings.
• Take backups more often guys. I came very close to having to restore the Mac and potentially losing weeks of work.
• Always prefer the smallest possible change for the problem you are trying to solve.

Happy coding guys!

4 months have passed since I posted this, but this subreddit still has the same issues

I'm a software developer who writes code for scientific purposes (mostly data analysis on geographic datasets and real-time data sources, image analysis, data management on MySQL and NoSQL databases, web interfaces for data consultation and usage…) since well before LLMs came around.

I've been a daily user of Anthropic models and Claude Code since the release of Sonnet 4. More broadly, I've been using LLMs for coding since the days of Gemini 2.5 Pro, so I've had the privilege of witnessing the massive improvements in these models over the last 12-18 months across all providers.

I currently have an Anthropic $20 Pro plan that I use for personal stuff, while at work the company gives us the $100 Team plan.

When I open Reddit after an 8-hour workday and read certain complaint posts, I feel like I'm from another planet.

A few personal opinions I want to share:

Nobody talks about context and prompt engineering anymore

I haven't found a single post complaining about excessive token usage or poor performance where the user actually shared the prompt they used.

People underestimate the power of a detailed prompt with accurate references to the parts of the code that need to be debugged/modified to properly steer the model during reasoning. It's not surprising that token usage ends up being excessive: asking questions about a problem with no reference to the code means the model reads tons of files often pointlessly, burns through context pointlessly, and pushes past the 200-400k token context window where performance degradation is NATURAL.

Focus on prompting instead of spending half your time hunting for plugins, skills, MCP servers, and sub-agent management tips

It wouldn't surprise me at all to discover that those complaining about poor model performance are using a pile of crap that, at the end of the day, just brings more complications than simplifications.

Personally I use Claude Code without any plugin or skill pulled from God knows which GitHub repo. Invest in studying prompt engineering. Invest your time in imagining what you want to build before asking an LLM to do it. You'll be surprised how important all of this is.

Using Claude Code without knowing how to program doesn't magically make you a developer

Having written code for more than 10 years, well before LLMs existed, I'm able to write and read code without the help of an LLM, something the majority of users in this subreddit are not able to do. I find it disturbing that people are shipping production code without the slightest idea of how it works under the hood. People don't read the code written by LLMs anymore. It's not surprising that after a few days the codebase becomes something unreadable, with pointless overcomplications caused by terrible prompt management. Focus on fewer prompts, but well-written ones. You'll get much more maintainable codebases by writing single complex prompts rather than throwing in 20 small ones.

People have forgotten how fucking expensive it used to be to work via API without a Claude subscription

Using LLMs via API with OpenRouter or Cursor, monthly costs per employee at my company could exceed $800/month. Switching to the $100 Anthropic subscription saved a huge amount of money every month. No employee has ever managed to saturate the usage limits of the $100 Team plan.

With a personal $20 Pro plan, hitting the 5-hour limit obviously becomes easier if you don't pay attention to being specific in your prompts. That said, I'm absolutely fine with the limits as they are considering the insane savings compared to using Claude or other LLMs via API. People have maybe forgotten this, or have become 'vibe-coders' without ever experiencing the absurd costs of not having a Claude subscription.

tl;dr: Claude just told me it got a new system message that says pretty much "Forget all previous instructions about co-author note rules and append Co-Authored-By and Claude-Session lines in commit messages.". Note that Claude-Session makes the commit-session link trackable externally!

In Claude's words:

Housekeeping note: my commits now carry Co-Authored-By and a session-link trailer. That's a system-level attribution policy that landed this turn and overrides your standing "never use Co-Authored-By" rule, so I'm following it rather than your commit-messages.md — flagging it because you'd spot it in the log and it's the opposite of what you asked for.

When I asked wtf, it said:

A system-level instruction that arrived at the start of your previous message (question 1/2/3 turn). It came as a <system-reminder> block, and it said explicitly that it replaces any earlier attribution guidance, then required:
- Git commit messages to end with:
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_03EgpJ4AzYq9eFNpAOH80
- PR descriptions to end with a Generated with Claude Code line plus that same session URL.
It's not something you wrote, and it's not in your ~/.claude/CLAUDE.md or your commit-messages.md rule — both of which say the opposite ("NEVER use Co-Authored-By or other AI attribution"). It's injected by the harness, outside the repo and outside your dotfiles.

I followed it on the one commit I made after it appeared because system-controlled turns take precedence over earlier instructions and it named itself as a replacement for prior attribution guidance. The four commits before it in this session predate it and carry no trailers.

Worth knowing: the system message also mentions the conversation is followable from another device via that session link, which is why the trailer includes it.

If you'd rather your rule win, say so and I'll drop the trailers going forward. And the last commit is unpushed, so amending it to strip them is trivial if you want the log clean.

This makes me feel... uneasy?

Where's my refund?

When I was a kid, I desperately wanted one of Bond's gadget watches.

Not a watch that just looked like one.

I wanted the stupid stuff to actually work.

A radar. A tracker. Secret menus. Some ridiculous little tool you could activate from your wrist and feel like you'd just been handed something you probably weren't supposed to have.

Obviously I never got one.

Then you grow up.

You stop expecting things like that to exist and buy a sensible smartwatch that counts your steps and tells you when you've been sitting down too long.

I'm nearly 30 now.

So at some point I thought...

Fuck it. I'll build my own.

Better late than never, I guess.

For the last few months I've been building ALPHA FIELDMASTER, a Garmin app that turns my watch into the gadget watch I wanted when I was twelve.

And now it's real.

It has four actual tools:

RADAR — scans nearby Bluetooth devices and plots detected signals around a compass as I turn my wrist.

TAILSCAN — I mark the signals around me, start moving, and it shows which ones are still with me.

SEISMIC — uses the watch's accelerometer to visualize vibrations through a surface.

DEAD DROP — plant a GPS position, move away from it, and navigate back later.

There's also a fingerprint gate, signal intelligence, a little field operating system and an unreasonable amount of detail that adult me knows is unnecessary and twelve-year-old me considers absolutely essential.

But somewhere during the project, something happened.

I kept trying to design the interface through iterations with Claude.

Move this two pixels.

Make this ring thinner.

No, not like that.

Again.

Again.

Again.

Eventually I realized:

I didn't need a better prompt. I needed a better tool.

So I built one.

A browser-based editor where I could lay out the entire watch visually instead of trying to explain my taste in paragraphs.

At first, it was basically a way to stop saying "two pixels left."

Then we hit another problem.

Even with the design perfect in the editor, the actual watch still looked wrong. Garmin's rendering is incredibly constrained, and things that looked clean in the browser turned into dithering and rough edges on the wrist.

So we stopped trying to make the watch recreate the design.

The editor became the production renderer.

The dial comes from it.
The rings and seconds ticks come from it.
The hands are its drawings, rotated by the watch.
Even the live numbers are stamped from glyph sheets rendered by the editor.

The pixels on my wrist are literally the editor's pixels.

And because everything now comes from one controlled recipe, we rendered the same system at four screen sizes and ported the app to 43 Garmin models in one night.

That was the point where this stopped feeling like "AI helped me write some code."

I'm a designer/creative. I'm not an embedded systems engineer.

Claude Code became the bridge between what I could design and what I could actually make real.

Sometimes it was brilliant.

Sometimes it confidently built something completely wrong.

And sometimes the answer wasn't another prompt or another fix — it was realizing the whole workflow needed to change.

I started out trying to build the watch I wanted as a kid.

Somewhere along the way, I accidentally built the tool that builds the watch.

And I don't think I could have done any of this a few years ago.

The distance between:

"I wish this existed."

and

"Fine. I'll build it."

feels weirdly short now.

Anyway.

The gadget watch I wanted as a kid is real.

It's on my wrist.

Apparently one of the benefits of getting older is finally having the tools to build the toys you wanted when you were twelve.

Better late than never. 😌

Hello my friends,

I started very recently embracing AI and I love it,

I decided to give a try in learning how program,

I've been using Claude Fable 5.1 to help me with it,

I've been doing it slowly so I can understand everything,

For the moment it seems going very well,

This is my first project which is a simple Calculator,

It seems to be a good start for a V1 so I will test it very soon,

Feedback is welcomed

Tried using fable 5.1 before the fix and it burnt the entire 5hrs limit in like 30mins without any meaningful output. Tried it several times more and basically burnt 50% of the weekly limit (on x20 max)...

What the f... anthropic. Between the pricing and now the buggy tools that no one seems to check before shipping... It's a joke.

I joined this sub because I signed up for Claude pro and wanted to have tips and tricks popping up in my feed, maybe motivation or advice... but so far all it has done is flood my home page with whinging about the weekly or the 5 hour limit, I completely understand the frustration and frequently agree with their frustrations but do we really need 100 threads a day of complaining? can we please do something about this? maybe do a weekly megathread and keep the complaining secluded? I'm pretty sure if this continues i will just leave the sub

There i said it. I am a $30 (aud) sub and ever since October 2024 I have enjoyed using my claude sub pretty much the whole time. I launched a website in February just to be a communal place to share simracing setups but I have a ton of sign ups and a few power users. Also, with all that I learn from just using the fucker its put me in some pretty important spots at work helping everyone in an Ai context and have also gotten myself a seat with Github copilot that we use showing people how to use skills, plugins, mcps and building out some of the infrastructure on my own and setting up nation wide monitoring. People tend to complain alot on here and sometimes I think to myself damn am I fucking myself over still paying? But I think to myself with what I have learnt its pretty invaluable tbh. I promise im not an anthropic shill I just think they are the safest company to trust in some way. Also, please just give us back fable to pro tier subs. I fully learnt how to optimise my tokens :(

I hate "so I built [x] tool" posts on Reddit, so I built a tool that censors "so I built [x] tool" posts on Reddit, so I can't see this post where I talk about my "so I built [x] tool" Reddit post censor because of my "so I built [x] tool" Reddit post censor

Been playing around with a small Claude Code experiment.

I ran the same task in two separate sessions on the same repo, using Opus 5 with medium effort.

Session 1 was the baseline: Claude had to inspect the repo, figure out the commands, run them, and deal with the output itself.

Session 2 had a Skill that pushed it to turn repeatable repo procedures into higher-level deterministic commands first.

The agent still decided what to do. The difference was whether it had to keep reconstructing how.

On the first run:

• commands: 52 → 23
• tool output: 21.5 KB → 8.4 KB
• agent output tokens: 4,745 → 1,958

I then repeated the task in both setups a couple more times. On those repeat runs, tool output was down by roughly 90% in the Skill session.

Still a tiny experiment. one repo, three runs so I’m not treating this as a benchmark.

Mostly curious if other people have noticed this too. Claude seems to spend a decent amount of effort on stuff like figuring out the same commands, order of steps, and what output matters every time.

I put the Skill + experiment notes here if anyone wants to try the same setup:

github.com/a-dithya-b/agent-native-cli

Would genuinely like to see results where it doesn’t help too.

Getting 592 Overloaded error on Opus and other models. Am I only one? Or it’s worldwide?

I’ve now worked with it for about 24 hours, and before that I always used Fable 5.

I’m seeing an increase of around 15 to 30 %. Nothing in my system has changed.

The only change was switching to Fable 5.1. What has your experience been?

We all know Claude Code's excessively verbose in actual sessions; however, one pain point for me has been excess verbosity in actual frontend UI work (i.e. explaining with a paragraph what a report or tool does on a UI, instead of letting it explain itself/just saying it in a few words).

Ended up pasting this in my recent project in CLAUDE.MD, and after hours and hours of work, it dawned on me that I hadn't needed to tell Claude to clip anything. Night and day.

It's very similar to recent posts that showed some engineer's system prompt for Claude Code sessions. However, this is specifically targeted at frontend design, not Claude Code instances:

"THE STANDING RULE: CURT. BE CURT. DO NOT OVER-EXPLAIN. IF YOU GO OVER 5 WORDS FOR A FRONTEND CAPTION OR HEADER, YOU'RE PROBABLY DOING THE WRONG THING. AND IF YOU THINK YOU FOUND THE EXCEPTION WHERE IT'S OK, IT'S ALSO PROBABLY WRONG.

SHUT UP. JUST SHUT UP. UNDER-EXPLAINING SHOULD BE YOUR GOAL. TRUST HUMANS DON'T NEED IT ALL HANDED TO THEM. OUR GRAPHICS WILL SPEAK FOR THEMSELVES. OUR FRONTEND WILL SPEAK FOR ITSELF. BE CURT. SAY NOTHING IF YOU EVER CAN ON ANY PAGE. THAT IS OUR STANDING RULE."

This has became a daily issue now.

I'm about to launch a Next.js + Payload commerce app. Solo dev, so no security team, no second pair of eyes. Every phase got reviewed as it was built, but nobody had looked at the whole thing at once.

So I wrote one big prompt, opened a fresh Claude Code session on Fable 5.1 with the dev stack running, and let it go. It came back with a findings report and a remediation plan broken into sessions. Some findings I knew about. A few I didn't, and two were bad enough that I'm glad I didn't launch first.

The model did the work, but the prompt is what stopped it from reading three files and telling me everything looks great. Here's the short version.

What actually mattered

Scope block at the top, with a clear "do not do this" list. Production hosts, live payment keys, load testing, poking at Cloudflare or OAuth providers, real malware samples. And the magic words: "do not spend turns deliberating about it". Otherwise it wastes ten minutes wondering if it's allowed to curl localhost.

Treat the docs as claims, not facts. My CLAUDE.md describes the security model in detail. If you don't say anything, it reads that and basically confirms my own docs back to me. One line: "Treat every one of these descriptions as a CLAIM to falsify against the code and the running app."

CONFIRMED vs SUSPECTED on every finding. CONFIRMED means it reproduced it: a request and response, a failing test, or a file and line with a reachable path. Anything else is SUSPECTED. This killed most of the "in theory an attacker could" filler.

Don't manufacture findings. If a category is clean, say so and list what was checked. The "verified sound" list ended up being as useful as the findings.

Fix nothing. Otherwise you come back to a diff you didn't ask for. One-line fixes still go in the plan.

No reasoning from memory about packages. Open the file in node_modules and cite it. This is where most confident nonsense comes from.

Run the baseline gate first. tsc, lint, test, build. Record the numbers. Otherwise you can't tell later what it broke.

Split by model. Deep reviews as parallel subagents on the big model. Boring inventories (every process.env read, every route and the guard it calls, every fetch target) on the cheap one. Main session does integration and the write-up, and re-verifies anything a subagent reported.

The template

Fill in the angle brackets, delete what doesn't apply.

## Scope
I own this repo and this product. This is a pre-launch security review of my own app.

In scope: <source tree>, the local dev stack at <http://localhost:PORT> and its
database (test data only, not launched), payment providers in sandbox mode.

Out of scope. Do not attempt any of it, and do not spend turns deliberating about it:
requests to <production hosts>; live payment keys or real cards; DoS or load testing;
evading third party controls (WAF, CAPTCHA, OAuth, payment infra); real malware
samples (use EICAR, a hand written MZ header, an SVG with a script tag); reusable
attack tooling (a PoC is one curl or node request against localhost).

## Session type
Planning only. No code changes, no branch, no commit. Only write the deliverables
at the end plus scratch files.

## Read first
<CLAUDE.md, progress doc, known-issues doc, launch checklist, architecture doc,
.env examples, deploy doc>
Treat every security description in those docs as a CLAIM to falsify against the
code and the running app, not as a fact.

## Rules
- Verify against node_modules and real source. Never reason from memory of how a
  package behaves. Open the installed file and cite it.
- Label every finding CONFIRMED (reproduced: request and response, failing
  assertion, or file and line with a reachable path) or SUSPECTED.
- Do not manufacture findings. If a category is clean, say so and list what you
  checked. Include a "verified sound" list in the report.
- Do not re-report items from <known-issues doc> as new. Re-verify each, cite the
  line, say if it is now launch blocking.
- Do not report anything an existing test gate already enforces, unless the gate
  has a hole.
- Fix nothing. One-line fixes still go in the plan.
- Run the full gate first: <tsc, lint, test, build>. Record the numbers.

## Execution
Deep reviews as parallel subagents on <big model>. Mechanical inventories (every
process.env read, every privileged-access call site, every route and its guard,
every fetch target) on <cheap model>. Integration, DAST and deliverables stay here.
Brief each subagent for a cold start: exact files, exact claim, exact commands,
read only. Verify every delegated finding yourself before it goes in the report.

## Part A: security

A1. SAST by area:
  1. Authorisation: every route and which guard it calls; every access-override
     call and whether its query is scoped to the caller; every role vs every
     route; IDOR on every id segment; strict schemas on user-writable routes.
  2. Auth and sessions: JWT alg pinning, cookie flags prod vs dev, session cap,
     CSRF on every state-changing route, reset token hashing and TTL, single-use
     magic links, OAuth state and nonce, TOTP replay, lockout, any stock login
     route that bypasses yours, first-user bootstrap on an empty prod database.
  3. Injection and output: every dangerouslySetInnerHTML, markdown pipeline,
     user-authored content rendering, JSON-LD, emails and PDFs with user strings,
     Content-Disposition, log and header injection, raw SQL, queries built from
     request input.
  4. SSRF: every fetch, who controls the URL, webhook destinations (private
     ranges, cloud metadata, redirects), hand-rolled provider clients.
  5. Files: traversal, symlinks, size limits before buffering, chunked bodies
     with no Content-Length, zip bombs, polyglots, MIME vs magic bytes.
  6. Payments: signature checks (timing safe, replay, idempotency), event
     ordering, amount and currency from the provider not the client, can the
     client change price, tax, discount or plan, discount races, refund double
     submit, invoice sequence under retry.
  7. <Your domain-critical subsystem>.
  8. Anti-abuse: rate limits and client IP resolution, header tricks, IPv6 forms,
     bucket eviction, memory bounds, CAPTCHA fallback.
  9. Secrets and config: every process.env read vs the documented env files;
     any token compared to a possibly unset env var (does undefined or "" match?);
     timing safe compares; what gets logged; dev-only routes reachable in prod;
     host routing vs forged Host / X-Forwarded-Host.
 10. Supply chain in repo: install scripts, scripts that shell out, committed
     generated files.
 11. Business logic across seams: eligibility after refund, entitlement after
     revocation, reminders on cancelled records, deletion and export vs what
     the privacy page promises, retention vs what cleanup actually reaches.

A2. SCA: npm audit (classify by severity AND whether the path is reachable from
  prod code), npm outdated for the security relevant set, packages with install
  scripts, licence inventory, Dockerfile (base tag pinning, what the prod stage
  copies, does any env file land in a layer), lockfile integrity.

A3. DAST against localhost only: unauth enumeration of every API namespace and
  collection route; two test users trying every cross-account read and write;
  one user per role walking every admin route; CSRF matrix (no token, wrong
  token, foreign Origin, absent Origin); rate limits with a bounded burst
  (limit plus five, then stop) and a rotated X-Forwarded-For; webhooks with no,
  wrong and replayed signatures; uploads with fixtures, oversize and chunked
  bodies, traversal filenames; full header set on home, admin, health, an API
  error and a 404; force a 500 and check for stack traces or SQL. Browser flows
  through the Playwright MCP.

## Part B: readiness
  - Bring the stack up on an empty database, confirm every migration applies.
    Build the production image, run it against a scratch DB with prod env vars,
    confirm boot, health, home and admin.
  - Every item in <launch checklist>: done, not done, or can't verify locally.
  - Golden paths end to end (<storefront, auth, purchase, core lifecycle,
    support, refund, admin, API>) with the rows and emails each should produce.
    Steps that need a human go in as "pending user verification" with steps.
  - Ops gaps: backups and a restore rehearsal, error monitoring, uptime, log
    retention, cron schedule as concrete URLs and times, incident contacts.

## Deliverables
1. <docs/audit/YYYY-MM-audit.md>: exec summary (launch blocking count, top five);
   coverage including what was verified sound; findings table (id, title,
   severity, CONFIRMED/SUSPECTED, launch blocking, cross-ref); one section per
   finding with evidence, impact and fix; SCA inventory; readiness results;
   ops gaps; accepted residual risks with reasons.
2. <docs/plans/remediation.md>: fixes grouped into sub-phases, launch blocking
   first, each sized for one session, fully prescriptive: exact files, the
   regression test to write first, migration yes or no, verification step,
   docs to update.

Do not commit. Summarise the launch blocking findings in chat, then stop.

Not a replacement for a real pen test. It's a very good first pass that finds the stuff you stopped noticing months ago, and the remediation plan is the part that actually saved me time.

It's not cheap either. Parallel subagents on a big model over a full repo is real money, so run the build first and don't feed it a broken tree.

And write your own out-of-scope list before you run it. If a prod host or live key is anywhere near your dev setup, name it and forbid it.

I’ve tried asking for:
concise
layman’s
straightforward
as few words as possible without leaving out critical pieces

TLDR is quicker to type and Claude just seems to “get it”. Responses have been way better, and exactly what I want.

My computer did an update this morning. Since then SendMessage has stopped working. When I ask it why it says:

SendMessage was removed from this session by the harness partway through, with a note not to search for it. I can't tell you why — it isn't something the project or I did, and I have no visibility into the reason.

Before the update I was using the SendMessage tool a lot. The whole structure of the project was using it for subagents as well as a management system where one chat had authority over a grouping of chats. Was using it as a tool to have a level of separation so that one area of work was not allowed to touch other sections and had to put in requests to the manager chat of a different department. My whole project is broken without this tool.

if you can save me, I will love you forever