If you open a new projet and ask Claude to summarise everything to know about REA and aks it to make some guide it will do the search then trigger a safety guardrail mid sentence and tells you this:

if you have tried it and had underwhelming results, it is most likely because Opus (and all claude) was told to not perform well when doing this type of task.

I see so many of the marketing videos where people advertise their use cases and they are like:

Claude takes my TeAM opINIONS from SlACk and it gives me dashboard

PRs are open, and Claude bla bla bla

My Teaaaam on Slaaack discussion and we found a SoluuuTION

Claude is able to find Vegan restaurants near my Area in Silicon valley and book me a time at "Thiss time" yeahh because I'm vegan

Me and my wife wanted to do our vacation in HawAIII so claude went in booking.com and lowballed the guy for $2000/night and that was perfect for us. And they AllOW Dogs.

Like this feels like they live in an alternate reality from a majority of their userbase.

I've seen dozens of posts here: "Why do I run out of usage so much?", "Why do I have to keep repeating myself to Claude?", etc.

I've built a set up that works amazingly well, for me, as a solo developer. YMMV if trying to implement this in a team. But here goes.

Full disclosure: This post was generated by my prompting my Claude Code as follows:

I feel like most people that are using Claude Code are not doing it effectively. I feel that my use of Claude Code, with my setup of mcps, gitlab, etc. is VERY effective, however I struggle to explain it to other people.

Can you create a description of what our set up is? something that I can post to reddit?

---------------------------------------------------

I've been programming for a long time, and I use Claude Code heavily for personal projects, a homelab and day-job support. Most people I talk to use it as a smarter autocomplete: open a session, describe a problem, accept whatever it does, repeat. That leaves most of the value on the table. Here's how my setup is built and why each piece is there.

1. The rules live in hooks, not in prose

Everyone writes a CLAUDE.md full of rules, and the model drifts from them anyway. My rule of thumb: if I've corrected the same behaviour twice, it becomes a PreToolUse hook that denies the call. Some of the things enforced that way:

• Nothing is deleted. A delete is blocked and rewritten as a move into an _archive/ folder.
• Git commands go through one wrapper script, never cd && git.
• Commit messages can't contain closing keywords like fixes #12, because those auto-close issues and skip my close-out process. There's no AI co-author trailer either.
• Writes to my day-job systems (ticketing, work email, work repos) are blocked unless I've said OK for that specific action. Reads are fine.
• Work content can only go to approved models. Other vendors' agents are blocked from seeing it, with no override.

CLAUDE.md still exists, but it's short and points to the detail. The hooks do the enforcing.

2. A self-hosted git server is the system of record, and the workflow lives in the tools

I run my own GitLab and wrote an MCP server for it (around 90 tools). The key design choice is that the workflow rules are inside the tools, so the model can't skip them:

• Every issue has exactly one type:: and one status:: label, and status is a state machine. Only I can move backlog -> ready. An agent can move ready -> in-progress, -> blocked (and blocking means posting a question on the issue instead of guessing), and in-progress -> review, which requires an open MR. review -> done happens only when I say so.
• Closing an issue is one tool call that runs the whole protocol: cross-reference the commits, log estimated skilled-developer effort (not clock time), set the terminal status, close it and sync the wiki.
• Raw API calls are forbidden, because a raw call bypasses the rules.

So the AI doesn't decide when work is "done". The tracker does, and I do.

3. The main thread orchestrates; subagents do the work, routed by model tier

The main session doesn't edit code. It plans and dispatches:

• Cheap and fast (Haiku): drafting short text, finding docs, trivial one-line fixes
• Mid tier (Sonnet): implementation from a clear spec, reading and synthesizing documentation
• Strongest model: bugs that several attempts haven't cracked, real architecture tradeoffs
• Below all of these: Jev for typed judgments over large piles (next section). It doesn't write.

This keeps the main context clean and the cost sane. I can also send a task to another vendor's coding agent for a second opinion. It runs headless in a disposable git worktree and never writes to the real repo, and Claude reviews whatever comes back.

4. A cheap decision model sits under the agents: Jev

Plenty of the work in this setup isn't writing. It's judging: is this issue ready, is this log line mine or the game's, is this alert noise, does this MR description match its diff. Sending all of that through Opus is expensive and fills the context. So there's a third tier below Haiku. Jev is TypeSafe's "System One" model, and it only returns typed judgments: pick one option, score on a scale, or give a yes/no probability. It can't write prose at all.

The standing rule is Jev decides, Claude writes. When Jev is unsure, Claude makes the call.

How it's wired:

• It's behind an MCP server I wrote. jev_ask takes questions (or a saved question set) plus file paths, globs or a GitLab query. The file contents never enter Claude's context. The server screens every item, sends them in parallel with back-off, and returns a compact table: accept / look / decide, with totals and a cost line. Claude reads only the items marked decide.
• Question sets are saved and re-measured. Confidence bands are tuned per question against real outcomes. The generic 0.8/0.2 thresholds left 80% of a backlog in the borderline zone; re-measured bands fixed that.
• It's embedded in other tools, not just called by hand:
  • The GitLab ready gate can run a Jev check on whether an issue still contains an unmade decision. It's advisory and opt-in per project.
  • Backlog grooming pre-sorts issues so the expensive model reads only the borderline ones.
  • An audit skill reports closed issues that don't meet their acceptance criteria, type:: labels that have drifted, and commits whose diff doesn't match the issue they cite. It reports only and never writes to GitLab.
  • The second-opinion workflow uses Jev as an acceptance gate on what the other vendors' agents return.
  • It also triages homelab alert noise, classifies game log origins, and finds duplicate memory files.
• Every turn that calls it reports the cost: calls, input tokens and USD. The API returns tokens, not dollars, so the cost is computed.

Measured accuracy against my own ground truth: 16/16 on the second-opinion gate, 92/97 on the backlog pre-sort, 18/18 on memory dedupe, 6/6 on MR-vs-diff.

The trap I measured, which most people will hit: a cheap model doesn't automatically save tokens. Each extra round trip resends 60-75k tokens of context to the orchestrator. On a 14-issue backlog, the Jev run used more Opus tokens than having Opus read the issues itself. Break-even came out at about 45-60 issues, or roughly 15-20k tokens of issue bodies. Above that, the gap widens fast. On 267 closed issues (about 1 MB of text):

• Opus usage: 1.7M tokens with Jev, against 9.5M without it. That's 5.7x fewer raw tokens, about 4x cost-weighted.
• Jev's own bill: 223 calls for $0.014.
• Verdicts: they agreed on 208 of 223. Jev was the stricter of the two, and it never passed something Opus failed.

And the safety lesson: anything sent to Jev leaves the machine. My first bulk run sent a memory file that contained a LAN login. The screen for client content didn't catch it, because it wasn't looking for secrets. Now every item goes through a credential screen as well, and work content is blocked outright. On one 267-issue run the screen held back 16% of the items, and the tool lists what it held back instead of dropping it silently.

5. Skills turn repeated workflows into one command

• Work the ready queue: one subagent per ready issue, each in its own worktree, in three phases: validate and lock, implement, review. It opens an MR and hands the issue back to review. It never merges or closes.
• Groom the backlog: check each issue against a definition of ready, draft acceptance criteria from the actual code, and promote only the issues I name.
• Work a milestone: walk it stage by stage, one branch, MR and delivery per lane, until nothing is left that doesn't need me.
• Ask the board: a panel of personas modelled on well-known engineers argues a decision from different angles, maps where they agree and split, and gives one recommendation. It's useful when I'm clearly talking myself into something.

6. Memory is a structured knowledge base, not a junk drawer

Each fact is its own file with typed frontmatter: who I am, feedback on how I want it to work, project state, or reference material. On top of that:

• stale_after dates on anything that ages (versions, IPs, prices, who owns what). At session start, a hook flags stale facts so they get re-checked before anyone relies on them.
• status: deprecated instead of deletion, so the history stays.
• verified: by human. A fact I confirmed beats one the model inferred.
• A hook validates every memory write, fixes the links and regenerates the index.
• Many entries are explicitly marked TRAP: things that cost me hours once ("this command exits 0 but does nothing"). Those are the most valuable entries in the whole thing.

The whole memory store is version-controlled.

7. Custom MCP servers for every domain I work in

• Homelab: provisions VirtualBox VMs over SSH, reads the installer screen, waits for boot and registers the new host in an inventory.
• Git hosting: described above.
• Jev: described above.
• A game-modding toolkit: compile checks, log and screenshot retrieval.
• Work mailbox: read-only, and it deliberately has no send or delete verb. The safest permission is a capability that doesn't exist.

Each server has a help() tool that serves as its catalogue, so the model looks up what's available instead of guessing.

8. Standing rules for infrastructure

When a VM, host or container comes into existence, three things happen in the same pass without me asking: it's registered in the inventory (and proven reachable with a real command, not just a ping), it gets a tile on my homelab start page if it has a web UI, and its timezone is set. CI on the container stack fails any service that's missing a timezone.

9. Verify, don't assert

• "Verify before asking or asserting" is a hard rule. Before it asks me something, it goes and checks.
• Deliveries are verified by file hash, not by poking at the app.
• Word documents go through a render loop (docx -> PDF -> images, then the model looks at the pages) before I see them.
• Code gets a compile check before every deploy.

What I think most people get wrong

1. Rules written as prose and expected to stick. Enforce them with hooks.
2. No system of record. The AI shouldn't decide what's done; a tracker with a state machine should.
3. One model for everything. Route by difficulty and keep the orchestrator's context clean.
4. Memory as a dumping ground. Type it, date it, mark what's verified, and record your traps.
5. Generic MCPs only. The best MCP servers are the ones you write for your own domain, with your rules built in.
6. Trusting "done". Make verification part of the workflow.
7. Using an expensive model for every decision. Put a cheap classifier under it, but measure the break-even first. On small piles it costs more, not less.

The result is that I spend my time making decisions (what's ready, what's done, which tradeoff to take) and very little on supervising keystrokes.

----------------------------------------------

I don't claim to be an expert in any of this, but I'm a seasoned developer with 45 years of professional programming experience.

Some of the stuff you see here might sound familiar, like "grooming", I use Matt Pocock's skill for that (more accurately I took the idea of his grooming skill and built my own), the "ask the board" I took the idea from one of Austin Marchese's Youtube videos.

I don't have ANY skill "packs", plugins, etc. installed in my environment.

I wish I could share some of the stuff that I've built, like my gitlab-mcp, but unfortunately when I built it I was building it for me, and there is way too much I would have to sanitize before making it public. What I can say is that EVERYTHING talked about above WAS built by Claude. I just told it what I wanted.

If I had to answer "What is single most important thing in your setup?" I would have to say my locally hosted Gitlab server. By using the "Issues" module in Gitlab I can keep track of everything that is going on, no matter how many projects I have going at a time. In the past 60 days I've worked and closed 1,160 issues across 15 different projects. Of all of those issues, EVERY SINGLE ONE was written by Claude by prompting "Create an issue in project xyz to solve/implement .... Validate the issue against current code", or something to that effect. I believe all of this could also be accomplished using Github, for those not inclined to host their own gitlab.

Below is the diagram for the state machine that controls my process:
(created with the prompt:
show me the diagram for the issue state machine
)

to me this is insane, I am used to paying a premium to get first person weapons and hands rigged posed and animated, and to have opus 5.5 do the whole deal in blender and be able to import it into unity and unreal, any animation in my head, is crazy. If opus 5.5 is at this level can't tell what the future will look like. im hyped!

It’s called spelunkr.

28 channels (so far) of forgotten videos organized into themed "cable tv channels" that play on a synced schedule 'round the clock.

The entire collection so far is about 2,700 hours of video, running around the clock. You tune in and land in the middle of whatever is on, at the same moment as everyone else watching, the way TV used to work.

Codebase is about 87,000 lines, made up of 24,000 of app code, 13,000 of CSS, 28,000 of tooling scripts, 16,000 of tests and 5,000 of SQL. 670 commits over 8 months, and we run over 850 unit tests and 160 browser tests. It's been a real passion project for me, really my first idea of what to build with Claude and has just been growing slowly as I've had time to work on it.

I've been plugging away at this off and on for the past 8 months, about 40 days of "total" work across that time, nearly all of it done with Claude Code. Here's how it works under the hood:

All videos on the website are streamed directly from the Internet Archive. The player is a plain HTML <video> element pointed at the Archive’s own file. No iframe, no proxy, no re-encoding, no copy. Spelunkr itself serves the page (about 110 KB of JavaScript, gzipped), small JSON schedules, and about 200 public domain or CC BY or BY-SA music tracks for the breaks. Every title links to the tape’s own page at the Archive.

There are station "bump" breaks between videos as an homage to the classic Adult Swim bumps.

Channels are built from Archive search audits to see if the IA has enough content to support a full length channel. Some channels are classed as "REWIND" and usually are 2 to 6 hour long VHS rips of actual live cable TV from someone's VCR in 1993. There's also classic movie channels dedicated to horror, monster flicks, detective noir capers, and western flicks. I even found every episode of The Joy of Painting and gave it CH 12: HAPPY TREES.

Claude checks all the tapes to make sure they're legit, then formulates the descriptions, facts, and schedule for me to approve. Each channel has its own branding, a 32×32 pixel logo drawn from eight color tokens, its own station-break voice and its own music pool.

A channel orders its tapes one of three ways: by year (8 channels), shuffled (12), or block rotation (4). Block rotation is a few episodes of one show, then the next show, round and round.

A channel is a published list of tapes with a start time.

“What is on now” is arithmetic: walk the schedule from its start to the present. The same code runs in the browser, the publishing tool and the tests, in whole milliseconds, so every machine gets the identical spot on every channel's schedule across the globe.

The math also accounts for the bump breaks, which get re-picked on every pass through the lineup. The browser measures its clock against the server’s once (the HTTP Date header) and corrects it only when it is more than 2 seconds off. A new lineup is published at least two minutes ahead and takes over at the end of a break. Open tabs hear of it over a websocket and switch without a reload.

Some key features built in:

• Limited DVR: Pause, skip back 15 seconds, or scrub within the tape that is on. The player shows how far behind live you are, and LIVE snaps back. (While paused you fall further behind each second)
• Machine Generated Subtitles: IA doesn't always have subtitles, so I use local software on my hardware to transcribe the tapes in their native language, and then translate them and output as subtitles overlaid on the player.
• In-line timestamped comments and reactions: A comment is stored against the tape (its Archive identifier) and a second within it, not against a channel or an air date. It comes back at that second every time the tape airs, on any channel that carries it. I've linked up a discord to help moderate potential comments (there are none yet lol). Signing in to comment also joins you to the Discord. Reactions work the same way and require no account or Discord. Its a free for all. A reaction from someone within 10 seconds of your playhead floats up over your picture as it happens.
• Comments are permanent pins on the timeline and pop up over the picture as the playhead crosses them. I like to think of it as pop-up video cable graffiti.

Urban planner here building a realistic city simulator. It’s more policy oriented than cities skylines, which tends to be more authoritarian esque and entirely focused on the urban design. My game is more realistic where you physically build less but influence growth through public policy. It’s much more in depth when it comes to inequality, disinvestment, public transit, coordination with state and federal gov, etc.

ANYWAYS, I’m more here to discuss the asset creation using blender. These assets are insane quality for being created by Claude with blender.

That said, any suggestions on other tools that deliver similar performance/outcomes as I refine the UI, menus, and landscape? Even suggestions on refining the simulation would be greatly appreciated.

I wanted a personal game for me and my friends to play on our iPhones, something that replicates the experience and joy we get when we go to the sand dunes in real life with our Nissan patrols and buggies. All I had to do was prompt opus 5.5 with a vague idea, and it came into fruition in around 24 hours UNATTENDED! ,what a freaking world we live in, with a trailer to showcase it to I didn't realize opus could pull of trailers! thing has taste for a text generator llm quite the powerhouse lol

The incredible part is how accurate the suspension works relative to real life, feels amazing to play on my iPhone, how the vehicle handles, how the tires dig tire tracks into the sand, how I can pull of harpin u turns going up steep dunes with that solid axel vehicle body roll. This is the dream. How it pulled of getting the solid axel suspension to articulate that realistically is crazy thing is just like my real Nissan Patrol and how it got that running on an iPhone 17 at a smooth 60 fps is also quite the achievement for demanding physics.

It used Xcode and swift and blender, no game engine was used using claude code desktop UI on my MacBook laptop. I used max reasoning and limited its sub agent use to a maximum of 3 sub agents.

I wonder what it can do with more passes and polish.

“…and make no mistakes.”

Hi everyone, I'm very new here. Last night, I hit the hourly limit reset. At that moment, there was a plan to implement, so I used Grok (Cursor) to implement it. It worked well, and the result is fine with me. This morning, I wrote a prompt to Claude Code like, "Hey, check, I implemented your plan when you were sleeping."

Then boooom 30% is gone from my hourly limit! I was on the Opus plan with medium effort at that moment. Please let me know if you guys have had similar scenarios like me.

Change your environment variables

I have Claude Code running on a separate laptop, usually working on stuff that takes a while.

What kept annoying me was having to check whether it was still doing its thing or just sitting there waiting for me to answer some question.

Had an old Kuando Busylight lying around, so I hooked it up to Claude Code using hooks.

Now it blinks red while Claude is working, stays solid red when it needs input, and turns green when it's idle.

That's it. No more constantly glancing at the other screen.

Probably one of the more useful things I've done with a USB light.

I have built a pretty robust set of agents I can now easily multitask on 10+ very different projects across agents and let each one work. But….

It is getting very difficult to keep track of which agents are working on what and what screen are they on. I find myself clicking from one agent to another to see their current status and what if anything they are waiting on me for further direction.

I am revering to keeping a notebook beside me with pencil and eraser and keeping notes of what project each agent is actively working on which seems bizarrely redundant. I do have a central dispatching agent which I could actively query, but that needs more screen space I don’t have available. My notebook is always readily available.

So my challenge is how do you keep pushing the boundaries of multitasking with agents when it starts exceeding what you can mentally keep track of.

In this reference, I am not talking about project management and keeping track of the status of projects over time, but more of an active session reference and context switching my mind across active AI sessions.

Maybe developers don’t run into this as much as admins do?

Everyone's been saying "expires Oct 22," but nobody had an exact time, and Anthropic's help page only says it expires "on the day and time listed on the offer." So I dug into the network responses on the usage page.

The offer object contains:

"starts_at":"2026-09-22T16:00:00+00:00",
"ends_at":"2026-10-22T16:00:00+00:00",
"clears":["five_hour","seven_day"]

So it's exactly 30 days, from 9 AM Pacific to 9 AM Pacific. It expires Oct 22 at 16:00 UTC:

That also explains why some people in Asia see "Expires Oct 23": the UI shows the date in your local time zone.

Verify it yourself (Firefox/Chrome):

1. Go to claude.ai → Settings → Usage
2. Open DevTools (F12) → Network tab, then reload
3. Use the search in responses (magnifier icon in Firefox, Ctrl+Shift+F in Chrome) and search for ends_at or 2026-10-22

If you're in the US, don't wait until the evening. Use it before your Thursday morning or lunch break is over.

It's called hopchat.

You control your home by chatting with it, and it all runs in the terminal.

Type "@home dim the living room lights" or "@home put YouTube on the TV", and a local AI model turns that into actions. It works with Wiz lights, LG TVs and Home Assistant devices. Nothing goes to the cloud.

It's also a chat app for everyone on your Wi-Fi:
🔹 Finds people nearby on its own. No server, no accounts, no sign-up.
🔹 Every message is end-to-end encrypted.
🔹 Send files up to 100 MB, with delivery and read receipts.
🔹 Ask "@ai" anything in any chat. Only one person needs to run a model, and the rest of the group can borrow it.
🔹 Set todos and reminders in plain English, like "standup every weekday at 9:30".
🔹 If someone's offline, their messages wait and arrive when they're back.

Because hopchat announces itself the same way every Offline Protocol app does, apps built with the SDK on iOS, Android and Python can find it on the network too.

All of this runs on the Offline Protocol SDK. It handles the hard parts:
• Encryption with MLS (RFC 9420), the same standard modern secure messengers use
• A signed identity for every device, so you always know who you're talking to
• Encrypted groups, file transfers and offline delivery

The interface is built in Rust with ratatui.

Your lights, your TV, a local AI and your friends, all in one chat, and none of it leaves your network.

The project: https://github.com/bahdotsh/hopchat
Checkout the SDK here: https://github.com/Offline-Protocol/offline-protocol-sdk

I feel anxious bout even stepping away for a few mins in case something idiotic is done or it get stuck on something. I find it crazy how some ppl are burning so much tokens on overnight tasks, where lot can go wrong. Whats keeping it under control and prevent delivering bad results?

Hey everyone,
I’ve been trying to use the REA (Reverse Engineer Anything) toolkit within Claude Code with Opus 5.5, but I keep running into a wall: almost any command or context related to unpacking APKs, inspecting smali/dex, or setting up proxy intercepts triggers a false ⁠[cyber]⁠ safeguard flag.

Can you share a working prompt/workflow? If you have a prompt pattern that actually gets Opus 5.5 to cooperate with reverse engineering an Android app to capture and map out encrypted API traffic (without getting flagged or giving up), I’d love to see it.

Appreciate any tips or prompt templates you've found success with!

Hey ,

I am a senior developer/architect working with softwares for 12+ years now. I work claude for more than a year now. I am starting to feel. Is there way for claude to internalise our decisions regularly and able mimic our working style. Instead of starting from a clean slate every time. Ive notice people mostly work with 3-5 projects mostly repeatedly, so internalising it over a period is a good thing to start with.

Question 1: is there a way to save more context about a large scale project better way? Instead of re reading it every time

Step 2: can it store the decisions that was taken earlier. So it can suggest decisions based on our working style and latest industry standards?

Most software factories you see build from a spec, on a side project. Ours is a Lemma teammate. It fixes real bugs, reported by users, in Lemma itself. It hands the coding to Claude Code, Codex or its own builder. This post is about what happens after: how a fix gets tested.

I'm one of the people building Lemma, an open-source (AGPL-3.0) workspace for AI teammates: https://github.com/lemma-work/lemma-platform. This software factory runs on it.

question I get most is "does it test its own code?" No. agent that tests a fix didn't write it, and it can't change it. It has no GitHub access at all. It can read the pull request, the issue and its own test records, and that's it.

Here's a real one.

Lemma's Files page had no way to make a folder. The fix had already merged when one of us asked the tester to check it. I'll be upfront about that order: the tester runs when someone asks. The reviewer, a separate agent, runs on every PR and already looks at the app at three widths. The tester goes further and replays the bug.

What it did:

1. Booted two copies of the app, one from the fix's commit and one from the commit the fix branched from.
2. On the old copy, did what a user would: opened Files, clicked New. No "New folder". It recorded that.
3. On the fixed copy, ran the same steps. New folder, named Reports. It showed up, and it was still there after a reload.
4. Ran the same check on both. It fails on the old code and passes on the fix. The fix's own new tests do the same.
5. Repeated the steps at phone, tablet and desktop widths, and put the recordings on the fix's page.

The reason for step 2: a check that also passes on the old code proves nothing. So the bug has to show up on the old code before the fix gets any credit.

Then it wrote down what it hadn't proven. The original report also said dragging a folder in from the desktop failed. Its test browser can't fake a drag from outside the browser, so it wrote that this half wasn't tested. That line is why we believe the rest.

Every bug also gets a proof ladder that only climbs on evidence. This one, today:

• It's real: proven
• We know why: proven
• The change fixes it: proven
• Nothing else broke: proven
• It shipped: in dev, not in production yet
• It works in the world: waiting on the reporter
• It stays fixed: unknown

Each test run is a row in a table: which two versions, what passed, who asked for it. So anyone on the team can open the recordings, not just whoever was in the chat when it ran.

How do you check that Claude Code's fix actually fixes the bug, instead of just passing its own tests? Replaying on the old code is ours. What else has worked for you?

When I review a front end PR I click through the preview and try to spot what moved. changereel does that for me: it builds both versions, screenshots every page, finds the changes and renders a video. In the PR it leaves a comment with a moving preview and a list of what changed where. Works as a GitHub Action and in GitLab CI.

How it tells "added" from "everything moved down": each page is compared like a text file whose lines are rows of pixels, so an inserted section is one added band.

Random parts (testimonials, carousels) are its weak spot. It visits pages several times and leaves out what differs between visits, but it is not perfect; you can exclude parts by CSS selector.

Optional: one sentence per change from a local model (Ollama) or Claude, spoken by a local voice (Kokoro or Piper).

`npx changereel --help` · https://github.com/derblub/changereel · MIT

Feedback welcome, especially pages where it gets it wrong.