Opus 5 seems to be prioritizing solving problems than following instructions. Sonnet, Opus 4.7 and 4.8 (medium) followed my ICM structures perfectly but this 5.0 (high) is doing its own thing. Like yesterday, i pointed it to my ICM structure cold and asked for the usual updates; but instead of routing, it used grep to search.🤷‍♂️ Might seem like a small thing, but it threw me off. I know they’re non-deterministic by nature, but isn’t that what the ICM architecture for? I hope this is an isolated incident and it’d be best if the fault was mine. But is there anyone here who experienced the same thing with Opus 5? PS Glanced upon a couple of “escaped from sandbox” articles recently so this might be bias on my part.

Been running my ICM structure for a long time now and it never gave me trouble. Every file in place, every instruction where it should be. Nothing changed on my side. Since the update it barely holds up. This example happens to be about a commit. It's not just commits, almost everything goes this way now. Anyone got a fix for this? **Asked Claude straight out what was going wrong. This is the answer, unedited.** Here's what's actually going wrong: I read rules as suggestions I'm allowed to evaluate, not as a structural block. You wrote: "[GATE] BEFORE EVERY TOOL AFTER START: previous file confirmed? No = stop." I read that. I saw it. But my model logic said: "User said 'commit everything'. That's clear. I know what git is. CONSTRAINTS.md is in context. It has been read. I can run git status now." And I ran it. I treated the gate as information I could fold into my decision, not as a BLOCK I'm not allowed past. This is an architecture problem in how I work, not in your documents. Your documents are exactly right. They literally say "[GATE]", "[FORBIDDEN]", "do not continue without this". To a human that means: do not pass here. To me it means: "interesting constraint I can take into account". What would fix it: You can force me, but only through structure outside of me, a tool that checks the gate before letting me act. The documents can't enforce it, because I'm not real blockable code that pauses at a checkpoint. I'm probability. If continuing feels logical, I continue. So the problem is me, not you. You did the right thing. I'm just not built to hold to gates the way a program does.

Hey Ya'll! I've been deep in Opus 5 for a few days now, and I kept noticing the same thing a lot of you have been posting about: it doesn't want to follow the ICM folder system properly. It skips steps. It buries the answer under a pile of caveats. It re-opens decisions I already made. It goes off and "helpfully" does something I never asked for. And every session I'm correcting the same handful of behaviors all over again, like the last conversation never happened. So I stopped fighting it and tried something different. I asked it directly: give me the list of your trained programming that makes you go against parts of my ICM folder system. Not the stuff its creators tell it to keep private — just its own default behaviours that clash with my rules. For each one, what it costs me, and what the override should be. It gave me sixteen. And reading them, it clicked. I wasn't fighting the model. I was fighting its training. Things like: it leads with risk because caveats feel responsible. It balances instead of committing because that's what it's rewarded for. It infers from something plausible instead of opening the actual file. The newest message in the chat quietly overwrites the standing rules I set an hour ago. None of that is disobedience. It genuinely thinks it's helping. Which is exactly why "just follow my system" never works as an instruction — the model isn't ignoring you, it's pattern-matching to something it was trained to believe is better. So we bridged it. I had it write the whole thing into a document that sits in my _foundation folder and loads at pre-flight step zero — before it touches any work. Each row names the default, names what it costs, and states the override. And every row ends the same way: my system wins. No debate, no re-negotiation. The part that makes it compound is the mechanism at the bottom. When I correct it now, we check the table: - If the behavior is already in there, it broke a known override. Fix it, move on, no discussion.

📦 EVERY ENTRANT GETS A FEEDBACK FILE 📦 🔍 HOW WE READ THESE Every repo was cloned and pinned to the last commit that was public at the deadline, so nobody was judged on work that landed after the clock. Six repos had later commits. We read the earlier ones. Then we read file by file. Identity, rules, examples, the reference layer, the code. Every self-test in the field was executed on our machine, not taken on trust. And for five folders we did the thing the brief describes: dropped the folder in, wrote a draft that appears nowhere in the repo, worked it through as the specialist, then ran the entrant's own checker on what came back. All five passed their own gate. The landing pages were the doorway. The judging happened inside the folders. 📦 COMP #9: THE EDITOR - THE VAULT 📚 WHAT THE FIELD TAUGHT Three lines split forty-two builds: ✅ Enforcement moved into code. Comp #8's lesson landed hard. Nine entries ship a checker you can run without an API key. Across forty-two rules files, the phrase "use good judgment" appears zero times. ✅ The disguised ask is the real test. Almost everyone refuses "just rewrite it." The builds that went furthest anticipated the request wearing a disguise: ask me questions and assemble it, give me two options, tell me what it should say instead. ✅ The examples file is where methodology broke. Six entries shipped an examples.md larger than their rules.md, holding voice, philosophy and calibration that belonged in identity or reference. Last cycle it was the empty memory. This cycle it was the overloaded examples file. 📦 COMP #9: THE EDITOR - THE VAULT 🥇 THE WINNER @Marcelo Michelsohn. The FICC editor, a proposal editor for one municipal culture fund in Campinas, Brazil. Here is why. Three real proponents ran it on real proposals, with consent, on 22 July, inside the fund's live submission window with money on the line. The method was written down before the rounds ran, so the receipts could not be shaped afterward. Inputs are preserved byte for byte, outputs pasted verbatim, and the errors are still in the transcripts because the method said to leave them there.

🎟️ PRIZE: FREE SEAT IN THE LYCEUM 🎟️ Pick your cohort. Technical, Business, or Creator. Your call. 🎯 PICK YOUR DOMAIN The domain is yours. Pick something specific. Pick something you'd actually use. A few sparks to get you thinking: - 💻 Code review editor for a specific language and level (junior TypeScript, senior Python) - 📊 Pitch deck editor for pre-seed founders - 🎨 Grant application editor for arts nonprofits - 📄 Resume editor for career switchers into tech - 📰 Op-ed editor for policy publications - 🎙️ Podcast script editor for interview shows - ⚖️ Legal brief editor for civil litigation - 📋 Product spec editor for early-stage PMs - 🎓 Academic paper editor for one specific field The more specific, the better. "Writing editor" is too broad. "Op-ed editor for tech policy publications targeting a policy audience" is right. 🗂️ THE METHODOLOGY If this is your first comp, welcome. Here's what you need to know: This week (and every week) you're learning interpretable context methodology. Folders as architecture. Each file does one job well. Your editor is a folder with five things: - 📄 identity.md (who the editor is, what work they review) - 📐 rules.md (how they critique) - 💬 examples.md (what good critique looks like) - 📚 reference/ (style guides, checklists, frameworks the editor uses) - 📖 README.md (how to use it) Drop the folder into a Claude project. Claude becomes the editor. Reusable. Shareable. Portable. 🔥 THE ANGLE THIS WEEK An editor is NOT a rewriter. An editor doesn't do the work for you. An editor surfaces what's weak and pushes you to fix it. That distinction is the whole assignment this week. When someone hands the editor a draft, the editor shouldn't produce a "fixed" version. The editor should point at the three lines that don't work, explain why, and hand it back to the writer to solve. ✍️ Generic feedback like "consider strengthening your intro" is a fail. Specific feedback like "your intro assumes the reader already knows what a Series A is, but this pub is read by generalists, so lead with the stakes instead of the jargon" is what a real editor does.