Tygart Media

Tag: Claude

  • Guardrails You Can Install Tonight: The AI Hygiene Starter Stack

    Guardrails You Can Install Tonight: The AI Hygiene Starter Stack

    Last refreshed: May 15, 2026

    Guardrails You Can Install Tonight: The AI Hygiene Starter Stack

    AI hygiene refers to the set of deliberate practices that govern what information enters your AI system, how long it stays there, who can access it, and how it exits cleanly when you leave. It is not a product, a setting, or a one-time setup. It is an ongoing practice — more like brushing your teeth than installing antivirus software.

    Most AI hygiene advice is either too abstract to act on tonight (“think about what you store”) or too technical to reach the average operator (“implement OAuth 2.0 scoped token delegation”). This article is neither. It is a specific, ordered list of things you can do today — many of them in under 20 minutes — that will meaningfully reduce the risk profile of your current AI setup without requiring you to become a security engineer.

    These guardrails were developed from direct operational experience running AI across a multi-site content operation. They are not theoretical. Each one exists because we either skipped it and paid the price, or installed it and watched it prevent something that would have cost real time and money to unwind.

    Start with Guardrail 1. Finish as many as feel right tonight. Come back to the rest when you have energy. The practice compounds — even one guardrail installed is meaningfully better than none.

    Before You Install Anything: Map the Six Memory Surfaces

    Here is the single most important diagnostic you can run before touching any setting: sit down and write out every place your AI system currently stores information about you.

    Most people think chat history is the memory. It is not — or at least, it is only one layer. Between what you have typed, what is in persistent memory features, what is in system prompts and custom instructions, what is in project knowledge bases, what is in connected applications, and what the model was trained on, the picture of “what the AI knows about me” is spread across at least six surfaces. Each surface has different retention rules. Each has different access paths. And no single UI in any major AI platform shows all of them in one place.

    Here are the six surfaces to map for your specific stack:

    1. Chat history. The conversation log. On most platforms this is visible in the sidebar and can be cleared manually. Retention policies vary widely — some platforms keep it indefinitely until you delete it, some have automatic deletion windows, some export it in data portability requests and some do not. Know your platform’s policy.

    2. Persistent memory / memory features. Explicitly stored facts the AI carries across conversations. Claude has a memory system. ChatGPT has memory. These are distinct from chat history — you can delete all your chat history and still have persistent memories that survive. Most users who have these features enabled have never read them in full. That is the first thing to fix.

    3. Custom instructions and system prompts. Any standing instructions you have given the AI about how to behave, what role to play, or what to know about you. These are often set once and forgotten. They may contain information you would not want surface-level visible to someone who borrows your device.

    4. Project knowledge bases. Files, documents, and context you have uploaded to a project or workspace within the AI platform. These are often the most sensitive layer — operators upload strategy documents, client files, internal briefs — and they are also the layer most users have never audited since initial setup.

    5. Connected applications and integrations. OAuth connections to Google Drive, Notion, GitHub, Slack, email, calendar, or other services. Each connection is a two-way door. The AI can read from that service; depending on permissions, it may be able to write to it. Many users have accumulated integrations they set up once and no longer actively use.

    6. Browser and device state. Cached sessions, autofilled credentials, open browser tabs with active AI sessions, and any extensions that interact with AI tools. This is the analog layer most people forget entirely.

    Write the six surfaces down. For each one, note what is currently there and whether you know the retention policy. This exercise alone — before you change a single thing — is often the most clarifying act an operator can perform on their current AI setup. Most people discover at least one surface they had either forgotten about or never thought to inspect.

    With the map in hand, the following guardrails make more sense and install faster. You know what you are protecting and where.

    Guardrail 1: Lock Your Screen. Log Out of Sensitive Sessions.

    Time to install: 2 minutes. Requires: discipline, not tooling.

    The threat model most people imagine when they think about AI data security is the sophisticated one: a nation-state actor, a platform breach, a data-center incident. These are real risks and deserve real attention. But they are also statistically rare and largely outside any individual user’s control.

    The threat model people do not imagine is the one that is statistically constant: the partner who borrows the phone, the coworker who glances at the open laptop on the way to the coffee machine, the house guest who uses the family computer to “just check something quickly.”

    The most personal data in your AI setup is almost always leaked by the most personal connections — not by adversaries, but by proximity. A locked screen is not a sophisticated security measure. It is a boundary that makes accidental exposure require active effort rather than passive convenience.

    The practical installation:

    • Set your screen lock to 2 minutes of inactivity or less on any device where you have an active AI session.
    • When you step away from a high-stakes session — anything involving credentials, client data, medical information, or personal strategy — close the browser tab or log out, not just lock the screen.
    • Treat your AI session like you would treat a physical folder of sensitive documents. You would not leave that folder open on the coffee table when guests came over. Apply the same habit digitally.

    This is the embarrassingly analog first guardrail. It is also the one that prevents the most common class of accidental exposure in 2026. Install it before installing anything else.

    Guardrail 2: Read Your Memory. All of It. Tonight.

    Time to install: 15–30 minutes for first pass. 10 minutes monthly after that. Requires: your AI platform’s memory interface.

    If you have persistent memory features enabled on any AI platform — and if you have used the platform for more than a few weeks, there is a reasonable chance you do — open the memory interface and read every entry top to bottom. Not skim. Read.

    For each entry, ask three questions:

    • Is this still true?
    • Is this still relevant?
    • Would I be comfortable if this leaked tomorrow?

    Anything that fails any of the three questions gets deleted or rewritten. The threshold is intentionally conservative. You are not trying to delete everything useful; you are trying to remove the entries that are outdated, overly specific, or higher-risk than they are useful.

    What operators typically find in their first full memory read:

    • Facts that were true six months ago and are no longer accurate — old project names, old client relationships, old constraints that have been resolved.
    • Context that was added in a moment of convenience (“remember that my colleague’s name is X and they tend to push back on Y”) that they would now prefer to not have stored in a vendor’s system.
    • Information that is genuinely sensitive — financial figures, relationship details, health-adjacent context — that got added without much deliberate thought and has been sitting there since.
    • References to people in their life — partners, colleagues, clients — that those people have no idea are in the system.

    The audit itself is the intervention. The act of reading your stored self forces a level of attention that no automated tool can replicate. Most users who do this for the first time find at least one entry they want to delete immediately, and many find several. That is not a failure. That is the practice working.

    After the initial audit, the maintenance version takes about ten minutes once a month. Set a recurring calendar event. Call it “memory audit.” Do not skip it when you are busy — the months when you are too busy to audit are usually the months with the most new context to review.

    Guardrail 3: Run Scoped Projects, Not One Sprawling Context

    Time to install: 30–60 minutes to restructure. Requires: your AI platform’s project or workspace feature.

    If your entire AI setup lives in one undifferentiated context — one assistant, one memory layer, one big bucket of everything you have ever discussed — you have an architecture problem that no individual guardrail can fully fix.

    The solution is scope: separate projects (or workspaces, or contexts, depending on your platform) for genuinely distinct domains of your work and life. The principle is the same one that governs good software architecture: least privilege access, applied to context instead of permissions.

    A practical scope structure for a solo operator or small agency might look like this:

    • Client work project. Contains client briefs, deliverables, and project context. No personal information. No information about other clients. Each major client ideally gets their own scoped context — client A should not be able to inform responses about client B.
    • Personal writing project. Contains voice notes, draft ideas, personal brand thinking. No client data. No credentials.
    • Operations project. Contains workflows, templates, and process documentation. Credentials do not live here — they live in a secrets manager (see Guardrail 4).
    • Research project. Contains general reading, industry notes, reference material. The least sensitive scope, and therefore the most appropriate place for loose context that does not fit elsewhere.

    The cost of this architecture is a small amount of cognitive overhead when switching between projects. You need to think about which project you are in before starting a session, and occasionally move context from one project to another when your use case shifts.

    The benefit is that the blast radius of any single compromise, breach, or accidental exposure is contained to the scope of that project. A problem in your client work project does not expose your personal writing. A problem in your operations project does not expose your client data. You are not protected from all risks, but you are protected from the cascading-everything-fails scenario that a single undifferentiated context creates.

    If restructuring everything tonight feels like too much, start smaller: create one scoped project for your most sensitive current work and move that context there. You do not have to do the whole restructure in one session. The direction matters more than the completion.

    Guardrail 4: Rotate Credentials That Have Touched an AI Context

    Time to install: 1–3 hours depending on how many credentials are affected. Requires: credential audit, rotation, and a calendar reminder.

    Any API key, application password, OAuth token, or connection string that has ever appeared in an AI conversation, project file, or memory entry is a credential at elevated risk. Not because the platform necessarily stores it in a searchable way, but because the scope of “where could this have ended up” is now broader than a single system with a single access log.

    The practical steps:

    Step 1: Inventory. Go through your project files, chat history, and memory entries. Look for anything that looks like a key, password, or token. API keys typically start with a platform prefix (sk-, pk-, or similar). Application passwords often appear as space-separated character groups. OAuth tokens are usually longer strings. Write down every credential you find.

    Step 2: Rotate. For every credential you found, generate a new one from the issuing platform and invalidate the old one. Yes, this requires updating wherever the credential is used. Yes, this takes time. Do it anyway. A credential that has appeared in an AI context is not a credential whose exposure history you can audit.

    Step 3: Move credentials out of AI contexts. Going forward, credentials do not live in AI memory, project files, or conversation history. They live in a secrets manager — GCP Secret Manager, 1Password, Doppler, or similar. The AI gets a reference or a proxy call; the credential itself never touches the AI context. This is a one-time architectural change that eliminates the problem permanently rather than requiring ongoing vigilance.

    Step 4: Set a rotation schedule. Any credential that has a legitimate reason to exist in a system the AI can touch should be on a rotation schedule — 90 days is a reasonable default. Put a recurring calendar event on the same day you do your memory audit. The two practices pair well.

    This is the guardrail that most operators resist most strongly, because it requires the most concrete work. It is also the guardrail with the highest upside: a rotated credential that gets compromised costs you a rotation. A static credential that gets compromised and you discover six months later costs you everything that credential touched in the intervening time.

    Guardrail 5: Install Session Discipline for High-Stakes Work

    Time to install: 5 minutes to build the habit. Requires: no tooling, only intention.

    For any session involving information you would genuinely not want to surface at the wrong time — client strategy, credentials, legal matters, financial planning, relationship context — install a simple open-and-close discipline:

    • Open explicitly. At the start of a sensitive session, load the context you need. Do not assume previous sessions left you in the right state. Verify what is in scope before you start.
    • Work in scope. Keep the session focused on the stated purpose. If you find yourself drifting into unrelated territory, either stay on task or close the current session and open a new one for the new topic.
    • Close explicitly. When the session is done, close it — not just by navigating away, but by actively ending it. If your platform allows session clearing or archiving, use it. Do not leave a sensitive session sitting open indefinitely in a background tab.

    The reason most people resist this is friction: reloading context at the start of a new session feels like wasted time. But the sessions that never close are the ones that eventually create exposure. The habit of closing is not overhead. It is the practice that keeps the context you built from becoming permanent ambient risk.

    The physical analog is ancient and no one argues with it: you do not leave sensitive documents spread across your desk when you leave the office. The digital version of the same habit just requires conscious installation because the digital default is “leave it open.”

    Guardrail 6: Audit Your Integrations and Revoke What You Don’t Use

    Time to install: 20 minutes. Requires: access to your AI platform’s integration or connected apps settings.

    Every major AI platform now supports integrations with external services — calendar, email, cloud storage, project management, communication tools. Each integration you authorize is a door between your AI system and that external service. Most people set up these integrations in a moment of enthusiasm, use them once or twice, and then forget they exist.

    Forgotten integrations are risk you are carrying without benefit.

    The audit is straightforward:

    1. Open your AI platform’s connected apps, integrations, or OAuth settings.
    2. Read every authorized connection. For each one, answer: “Am I actively using this? Is it providing value I cannot get another way?”
    3. For anything where the answer is no, revoke the integration immediately.
    4. For anything where the answer is yes, note what scope of access you have granted. Many integrations default to broad permissions when narrow ones would serve. If you authorized “read and write access to all files” when you only need “read access to one folder,” revoke and re-authorize with the minimum scope necessary.

    Repeat this audit quarterly, or any time you add a new integration. The list has a way of growing faster than you notice.

    As AI platforms increasingly support cross-app memory — where context from one platform informs responses in another — the integration audit becomes more important, not less. The sum of what your AI stack knows is now the composite of all connected surfaces, not any individual platform. Auditing the connections is how you keep that composite picture within bounds you have deliberately chosen.

    Putting It Together: The Starter Stack in Priority Order

    If you are starting from zero tonight, here is the order that produces the most protection per hour of time invested:

    First 10 minutes: Lock your screen. Log out of any AI sessions you have left open that you are not actively using. This is Guardrail 1 and costs nothing except attention.

    Next 30 minutes: Read your memory. Run the full audit on any AI platform where you have persistent memory features enabled. Delete anything that fails the three-question test. This is Guardrail 2 and is the single highest-leverage action on this list for most users.

    This week: Audit your integrations (Guardrail 6) and set up session discipline for high-stakes work (Guardrail 5). Neither requires heavy lifting — both primarily require attention and the five minutes it takes to actually look at what is connected.

    This month: Structure scoped projects (Guardrail 3) and rotate credentials that have touched AI contexts (Guardrail 4). These are the higher-effort guardrails but also the ones with the most durable benefit. Once they are installed, the maintenance burden is light.

    Ongoing: The monthly memory audit and quarterly integration audit become standing practices. Once the initial work is done, the maintenance version of this whole stack takes about 30 minutes a month. That is the steady-state cost of not periodically detonating.

    What This Stack Does Not Cover

    Intellectual honesty requires naming the edges. This starter stack addresses the most common risk profile for individual operators and small teams. It does not address:

    Enterprise-grade threat models. If you are running AI in a regulated industry, handling protected health information or financial data at scale, or operating in a context where you have disclosure obligations to regulators, this stack is a floor, not a ceiling. You need more: data residency agreements, vendor security audits, formal incident response plans, and probably legal counsel who has thought about AI liability specifically.

    The platform’s obligations. These guardrails are about what you control. They do not address what the AI platform does with your data on its end — training policies, retention practices, breach disclosure timelines, or third-party data sharing agreements. Read the privacy policy for any platform you use at depth. If you cannot find a clear answer to “does this company use my conversations to train future models,” treat that as a meaningful signal.

    Credential security at the infrastructure level. Guardrail 4 covers credentials that have appeared in AI contexts. It is not a comprehensive credential security framework. If you are operating infrastructure where credentials are a significant risk surface, the right tool is a full secrets management solution and possibly a security review of your deployment architecture — not a checklist.

    The people in your life who are in your AI context without knowing it. This is a different kind of guardrail entirely, and it belongs in a conversation rather than a settings menu. The Clean Tool pillar piece covers this in depth. The short version: if people you care about appear in your AI memory, they almost certainly do not know they are there, and that is worth a conversation.

    The Practice Compounds or Decays

    AI hygiene is not a project with a completion date. It is a standing practice — more like financial review or equipment maintenance than a one-time installation. The operators who build this practice early, when the stakes are still relatively small and the mistakes are still cheap to recover from, will be meaningfully safer in 2027 and 2028 as memory depth increases, cross-app integration becomes standard, and the AI stack handles more consequential work.

    The operators who wait for the first public catastrophe to start thinking about it will not be starting from scratch — they will be starting from negative, trying to contain an incident while simultaneously installing the practices they should have had in place.

    This is not fear-based reasoning. It is the same logic that applies to backing up your data, maintaining your vehicle, or reviewing your contracts annually. The cost of the practice is small and constant. The cost of the failure is large and concentrated. The math is not complicated.

    Start with Guardrail 1 tonight. Add one more this week. The practice compounds from there — or it doesn’t start, and you keep carrying risk you could have put down.

    The choice is available to you right now, which is the whole point of this article.

    Related Reading

    Frequently Asked Questions

    How long does it take to install the basic AI hygiene guardrails?

    The first two guardrails — locking your screen and reading your persistent memory in full — take under 45 minutes and can be done tonight. The full starter stack, including scoped projects, credential rotation, session discipline, and integration audit, requires a few hours spread over a week or two. Maintenance after initial setup runs approximately 30 minutes per month.

    Do these guardrails apply to Claude specifically, or to all AI platforms?

    The guardrails apply to any AI platform with persistent memory, project storage, or third-party integrations — which currently includes Claude, ChatGPT, Gemini, and most enterprise AI tools. The specific location of memory settings and integration controls differs by platform, but the underlying practice is the same. This article was written from direct experience with Claude but the logic transfers.

    What is the single most important guardrail for a beginner to start with?

    Reading your persistent memory in full (Guardrail 2) is the single most clarifying action most users can take. Most people have never done it. The exercise alone — reading every stored entry and asking whether it is still true, still relevant, and leak-safe — surfaces more about your current risk posture than any abstract audit. Start there.

    Should credentials ever appear in an AI conversation?

    As a general rule, no. Credentials should live in a secrets manager and be passed to AI contexts via references or proxy calls that keep the raw credential out of the conversation. In practice, most operators have pasted at least one credential into a conversation at some point. When that happens, the right response is to treat that credential as potentially exposed and rotate it promptly — not to wait and see.

    How do scoped AI projects differ from just having separate browser tabs?

    Separate browser tabs share the same account, session state, and in most platforms the same persistent memory layer. Scoped projects, by contrast, are explicitly separated contexts where project-specific knowledge, uploaded files, and custom instructions are isolated from one another. A problem in one project scope does not contaminate another the way a shared session state might.

    What does an integration audit actually involve?

    An integration audit means opening your AI platform’s connected apps or OAuth settings, reading every authorized connection, and revoking anything you are not actively using or that has broader permissions than it needs. Most users find at least one integration they had forgotten about. The audit takes about 20 minutes and should be repeated quarterly, or any time you add a new connection.

    Is AI hygiene only relevant for operators running AI at depth, or does it apply to casual users too?

    The stakes scale with usage depth, but the basic practices apply at every level. A casual user who primarily uses AI for writing help has lower exposure than an operator running AI across client work, credentials, and integrated infrastructure. But even casual users have persistent memory, chat history, and connected apps that merit a periodic look. The starter stack is designed to be relevant across the full range.

    What is the difference between AI hygiene and AI safety?

    AI safety typically refers to research and policy work focused on the long-term behavior of powerful AI systems at a societal level — alignment, misuse at scale, existential risk. AI hygiene is a narrower, more immediate practice focused on how individual operators manage their personal and professional exposure within current AI tools. The two are related but operate at different scales. This article is concerned with hygiene: what you can do, in your own setup, tonight.




  • The Clean Tool: Why I Keep My Claude Empty of the People I Love

    The Clean Tool: Why I Keep My Claude Empty of the People I Love

    A flagship essay on AI hygiene: what to store, what to keep out, and how to have the conversation about it with the people in your life.

    “What do you know about my girlfriend?”

    Last night my partner Stef asked me a question she had a right to ask. She wanted to know what my AI knew about her.

    I use Claude for hours a day. I run an agency on top of it. I have knowledge bases, project contexts, client stacks, and conversation histories going back years. She watched me work on the thing enough to assume that by now, surely, the AI had a rich picture of her — her sense of humor, her work, the shape of our relationship, the running jokes, the small details a partner remembers. She handed me her phone as a test of it. Let it tell me what it knows.

    The answer was almost nothing.

    My name for her. That she lives here. A few passing references to a Notion chat room she once set up, a voice memo she sent me that we extracted some thinking from. No sense of who she is as a person. No running joke the model could finish. No model of her at all, really.

    She was hurt in a flash, the way you get hurt by something that isn’t an injury but is still information. I was quietly proud, in a way I didn’t know how to explain in the moment. Both reactions were correct. That’s the thing I want to write about here — that the gap between her hurt and my pride is the shape of a whole category of questions almost nobody is asking out loud yet, and it is only going to get bigger.

    We talked about it for a while. I tried to explain why the tool was empty of her on purpose. She let me try. And what came out of the conversation was the argument I’m about to make, which I’ll phrase in one sentence up front so you can decide whether to keep reading:

    Keeping the people you love out of your AI is not forgetting them. It’s a specific kind of care. And the conversation you have about why they’re not in there is how you close the gap between what the tool knows and what the relationship deserves.

    If that sentence lands at all, the rest of this is the why, the how, and the honest version of what I’m still getting wrong.

    AI Memory Is Nuclear Power

    Here’s the frame that has organized my thinking on this for the last year.

    AI memory is nuclear power. Real civilization-scale utility on one side, real civilization-scale danger on the other, and almost nobody I’ve met is running a containment protocol worthy of the payload they’re storing.

    The analogy holds all the way down. The fuel is useful because it’s concentrated — that’s the whole point of a persistent memory that remembers your business, your family, your finances, your health, your history. Concentration is what makes the tool powerful. Concentration is also exactly what makes a spill catastrophic. And the people celebrating the new reactor are almost never the people thinking about the waste.

    The honest position on this, I’ve come to believe, is neither abstinence nor maximalism. It’s containment engineering. You build the reactor and the shielding. You use the tool and you design the protocol for when the tool fails. Pro-AI and pro-guardrail are the same position. Anyone telling you to choose one is selling you something.

    What makes this hard is that the stakes are asymmetric in a way most people never sit with directly. For the platform, your memory is one row in a table of billions — a single unit of risk distributed across a huge population. For you, your memory is a map of your life. The platform’s worst-case scenario is a rough quarter, a settlement, a bad headline. Your worst-case scenario is a destroyed marriage, a leaked client list, a legal catastrophe, a career-ending screenshot. These are not remotely comparable events, and they don’t scale the same way, and they do not reach any kind of equilibrium where the platform’s good-faith security policy protects the individual worst case. The platform is optimizing for its risk profile. Its risk profile is not yours. You are the only person whose worst-case scenario is your worst-case scenario.

    That asymmetry is why individual hygiene matters even when platform security is genuinely excellent. It’s why I don’t think this conversation is paranoid and I don’t think it’s solved and I don’t think you can outsource it.

    Three Failure Modes. Which One Are You?

    Most people running AI at any real depth fall into one of three failure modes, and most of them don’t know which one they’re in. Before I tell you what any of them are, I want you to place yourself while you read.

    The over-loader. This is the person who treats the AI as a second brain and dumps everything into it — credentials, relationships, grievances, client details, medical history, the long rambling voice-memo of what happened at Thanksgiving. It feels like investment. It feels like the tool getting smarter about them. It mostly is. But it also means one breach, one nosy partner, one subpoena, one bad exit from the platform turns the tool into a weapon pointed directly at the user. The over-loader’s failure mode is invisible until it isn’t.

    The under-loader. This is the person who keeps the tool so sterile it never reaches its potential — which is fine as far as it goes, except the humans in their life often discover, usually by accident, that they aren’t in the context at all. That discovery doesn’t land as safety. It lands as erasure. The under-loader’s failure mode is relational, not technical. The tool stays clean, and the relationships pay the cost the tool should have paid.

    The unaware. This is, honestly, most people. No mental model of what’s stored, where, for how long, or under whose policy. They’re making operational decisions — business decisions, relationship decisions, identity decisions — on top of a foundation they have never inspected. They don’t know their AI has memory in six places, not one. They don’t know where the off switch is. They assume chat history is the whole story when chat history is maybe 20 percent of it.

    The first hygiene move is always the same: figure out which mode you default to. Over-loaders need to prune. Under-loaders need to have a conversation with the humans they’ve been quietly protecting without telling them. The unaware need to spend thirty minutes mapping what they’ve actually agreed to.

    I’ve been all three at different points. Most operators I respect have been too. The point of the diagnostic isn’t to shame. It’s to make the failure mode visible enough that you can actually work on it.

    Clean Tool vs. Second Brain: The Choice You Might Not Know You’re Making

    There are two coherent philosophies for how to use AI at depth, and they are genuinely in tension.

    The Clean Tool approach says: the AI is an instrument. You keep it sharp by keeping it empty of identity. You bring the context you need into each session, do the work, and let the session close without leaving a permanent residue of who you were that day. The AI is like a great chef’s knife — it serves you best when it is exactly what it is, not a repository of everything you’ve ever cut with it.

    The Second Brain approach says: the AI is an extension of cognition. The more of you it holds, the more it can do for you. The payoff scales with the investment. Loading your thinking, your projects, your relationships, your patterns into the model is not a liability — it’s the whole point. You are building a partner that knows you well enough to anticipate you. The AI is like a lifelong collaborator who has read every note you ever took.

    Both are legitimate. Both have failure modes. The failure mode of the Clean Tool is that you never reach the depth of partnership that made you interested in AI in the first place — you end up with a very sharp instrument and no deep relationship with the work it enables. The failure mode of the Second Brain is that you build something you cannot leave, cannot audit, and cannot defend if it ever gets read by the wrong person.

    I run Clean Tool. I should say that plainly. I do not believe it is the only right answer. I believe it is the right answer for how I work, what I work on, and who the people around me are. My work touches client data, confidential business strategy, and a personal life I want to keep intact. The cost of a Second Brain leak, for me, is catastrophic in a way I cannot price. The cost of the Clean Tool is friction — I reload context more often, I carry more of my own thinking in my own head, I refuse some of the tool’s offers of recall. That friction is the price of sleeping well.

    I know thoughtful people who run Second Brain and run it well. They’ve built containment around it. They accept different tradeoffs. The worst place to be is the one most users actually occupy, which is a confused middle — enough invested that the data layer has weight, not enough discipline that the containment is real. You get the downsides of both and the upsides of neither.

    So if you take one frame from this piece: the choice isn’t which philosophy is correct. The choice is which one you are running, consciously, with the guardrails appropriate to that choice. Drifting into either by accident is what produces the failure modes nobody wants.

    The People Not in the Memory

    I want to go back to Stef, because this is the part of the piece that matters most to me and I’m not sure I’d trust anyone else to write it the way I need to write it.

    When Stef was hurt that the AI didn’t know her, I understood what she was feeling. The intuition beneath the hurt is simple and very human: you spend hours every day with this thing. It’s your work, your thinking, your hours. If you cared about me the way you care about the work, surely some of that care would show up in the tool. That intuition is not wrong in its values. It’s wrong in its mechanics.

    AI proximity is not relational proximity. Time-on-tool is the worst possible proxy for trust. A person can spend ten hours a day with an AI and share less of themselves with it than they share in a two-minute phone call with their sister. The tool is near you. It is not close to you. These words are not synonyms and they never have been, and the confusion of them is producing a whole new species of interpersonal hurt that our language doesn’t have good words for yet.

    Here is what I believe about the people in my life and my AI’s memory. Stef is not in the tool because she does not need to be in the tool for the tool to do its job. She matters because she is a person, not because the system has modeled her. Putting her in the context would not deepen my relationship with her. It would reduce her to a row in a store I don’t fully control, governed by a policy I did not write, subject to a retention schedule I did not negotiate, accessible to whoever eventually gets to see my session — a partner who leaves, a discovery motion, a breach, a curious kid, a future version of the platform with different terms. None of those futures are certain. All of them are possible. The cost of her being in there, in any of those futures, is hers to pay, not mine.

    And I love her. So she is not in there. That is the mechanism.

    The thing I couldn’t explain to her in the moment, but want to say here, is that the emptiness isn’t neglect. It’s restraint. It’s the same impulse that makes me not tell certain stories at parties even when they’d get a laugh, because they are hers to tell. It’s the same impulse that makes me lock my phone when I step away, even though the odds that anything bad happens in the next ninety seconds are vanishingly small. It’s the practice of treating the people you love as if their information is theirs, which is the simplest expression of respect I know.

    The conversation we had after her hurt was the actual repair. I told her why the tool was empty of her. I told her what was in the tool and what wasn’t. I offered to show her my memory settings, my projects, my contexts — not as a defensive move, but as a matter of domestic transparency. She didn’t take me up on it. The offer was enough. What closed the gap wasn’t the tool changing. It was me being able to say, out loud, you are not in there because I love you, and here is what I mean by that.

    If you use AI at the depth I do and you have people in your life, I think you owe them some version of that conversation. It is not a hard conversation. It is mostly just a clarifying one. But it has to actually happen. The gap between what your tool contains and what your relationship deserves does not close on its own.

    The Containment You Can Install Tonight

    After five sections of framing, you deserve something to do. Here are five moves. None takes more than fifteen minutes. All five together take about an hour. If this is the only section of the piece you act on, you will be meaningfully safer tonight than you were this morning.

    Read your memory. Open whatever interface your AI gives you for stored memories — Claude’s memory settings, ChatGPT’s memory panel, whichever surface your platform exposes. Read every entry top to bottom. For each one, ask three questions: is this still true, is this still relevant, would I be comfortable if this leaked tomorrow? Anything that fails any of the three gets deleted or rewritten. Most people have never read their own AI memory end to end. Doing it once is often the moment the rest of this starts to feel real.

    Map the six surfaces. The chat history is not the whole memory. The whole memory is scattered across at least six surfaces: conversation history, persistent memory features, project knowledge bases, custom instructions, system prompts, and connected integrations (Drive, email, Notion, Slack). Each has a different retention policy. Each has a different surface for deletion. No single UI shows you the total picture. Sit down once and write out, for your specific AI stack, where all six surfaces live for you. This is a twenty-minute exercise that will clarify more than any article could.

    Scope your projects. Stop running one giant context that holds everything. Split into scoped projects — one for client work, one for personal writing, one for household, one for finance if you use it that way. Each project holds only the context it needs. The blast radius of any single compromise stays inside that one project. This is the same least-privilege principle engineers use for software access, applied to context.

    Lock the handoff. The threat model that matters for most individual users is not a sophisticated hacker. It’s the moment someone else touches your unlocked device — a partner borrowing the phone, a kid looking for the calculator, a colleague glancing at your screen, a support agent on a screenshare. Install a short, specific protocol: screen lock by default, session close on context switch, and a named practice for what happens when someone else uses your device. The worst leaks come from the most ordinary moments. Plan for those, not for the movie villain.

    Rotate what the AI has seen. Every credential that has ever appeared in an AI context — API key, password, token, connection string — goes on a rotation schedule the moment it enters. A ninety-day calendar reminder at minimum. Ideally, credentials never enter the AI directly at all; they live in a secrets manager and the AI calls through a proxy that holds the secret. Moving from the first version to the second is one afternoon of plumbing, and it is the single highest-leverage hygiene move an operator can make.

    These are not the whole practice. They are the starter kit. The practice compounds from here.

    The Harder Layer: What I’m Still Getting Wrong

    I want to write this section honestly because the alternative is writing it dishonestly, and there is no version of this piece that earns its argument if I pretend Tygart Media has this figured out.

    So. Here are some real mistakes.

    Earlier this month, the AI stack I use to automate WordPress work made an edit to a client site page without the kind of per-page human confirmation the situation deserved. The edit broke three live pages. The client was patient about it. The rollback worked. No business was lost. But the near-miss had the exact shape of the failure mode this whole piece warns about — capability ran ahead of containment, and a system I trusted made a change faster than my judgment could intervene. The lesson was immediate and I installed the guardrail that afternoon: any live-system action on a high-risk surface now requires explicit per-action confirmation. Read-only actions can run free. Destructive or irreversible actions cannot. The rule sounds obvious stated plainly. It was not in place before the near-miss, and that is on me.

    I have also, at various points, let credentials linger in AI contexts longer than I should have. Not dramatically. Not catastrophically. But in the honest audit I did after the incident above, there were tokens in project files older than the rotation schedule I would tell a client to use. I rotated them. I built the proxy pattern I should have built a year ago. I am closer to clean than I was, and I am not fully there yet.

    There is a reason most operators don’t write sections like this one. The near-miss is pedagogically priceless and professionally embarrassing at the same time. The embarrassment is why the field learns slowly. The honesty, when someone offers it, is the most valuable content in the space — and it is almost never offered, because the incentive structure rewards the polished version over the useful one.

    I am publishing this section anyway because I think the embarrassment is a smaller cost than the slow-learning tax the whole field pays when operators hide their misses. And because an article about hygiene that pretends its author doesn’t sweat is not an article I’d trust from anyone else. If you run AI at operator depth long enough, you will produce near-misses. Whether you learn publicly or privately is the only variable. I’d rather learn where it helps someone else avoid the same move.

    The 2030 View

    If everything in this piece feels a little optional in 2026, project the variables forward and see if the math still works.

    Memory depth is going up, not down — meaningfully, as context windows expand and persistence shifts from opt-in to default. Cross-app memory is already arriving; by 2030 your AI will know what’s in your email and your calendar and your files and your shopping history and your health app, not as separate silos but as a fused picture. Agent autonomy is arriving faster than most people realize — the AI is moving from a thing you consult to a thing that acts on your behalf, which means the containment question shifts from “what does it know” to “what can it do.” Shared household AI layers are arriving, with multiple family members on the same account already common enough that the consent problem stops being individual and becomes governance. And the legal system will catch up to all of this, unevenly, painfully, and in ways you will not want to be the test case for.

    Every problem in this article compounds under those conditions. The over-loader’s blast radius grows. The under-loader’s relational gap widens. The unaware’s foundation gets shakier. The recipes that take an hour now will take a day then. The containment practices that feel precious today will feel obvious in five years, the way locking your front door and not leaving your wallet in the car feel obvious now.

    There will be a public catastrophe. I don’t know whose. I don’t know whether it will be a major breach, a lurid divorce, a criminal discovery, or a platform failure that rewrites retention terms mid-flight. I know it will happen and I know it will reorganize how the rest of us think about this overnight. The people who built the practice before that moment will look prescient. They won’t have been prescient. They’ll have been paying attention.

    I would rather pay attention now, while the stakes are small and the mistakes are cheap, than learn after the public catastrophe when the mistakes are not.

    The Close

    Everything in this piece argues for one small idea.

    The tool is a tool. The person is a person. The hygiene is what keeps those two categories from collapsing into each other.

    When the tool becomes a stand-in for cognition, memory, identity, or intimacy, it has exceeded what it was ever built to do, and the human pays the cost. When the person becomes a user-of-tools who still owns their own thinking, relationships, and responsibility, the tool does what tools are supposed to do — extend capacity without replacing character.

    Every practical move in this article is a local case of that single principle. Every hygiene conversation in your life is an application of it. Every guardrail you install is the same principle, written down.

    And the practice compounds or decays. Six months of deliberate attention makes the moves automatic. Six months of neglect means the muscle memory isn’t there when you need it. This is not a project you complete. It is a standing practice you keep, like locking the door, like reviewing your accounts, like calling the people you love.

    Do one thing tonight. Read your memory. Map your surfaces. Call the person in your life your AI doesn’t know about and tell them why you kept it that way. Any of those. Whichever one feels least comfortable is probably the right one to do first.

    The tool is a tool. The person is a person. The hygiene is what keeps them from becoming each other.

    Start there.

  • Claude Opus 4.8 Feature Deep Dive: Context, Extended Thinking & Task Budgets (2026)

    Claude Opus 4.8 Feature Deep Dive: Context, Extended Thinking & Task Budgets (2026)

    Last refreshed: June 9, 2026

    Model Accuracy Note — Updated June 9, 2026

    Current flagship: Claude Opus 4.8 (claude-opus-4-8). Current models: Opus 4.8 · Sonnet 4.6 · Haiku 4.5. Claude Opus 4.8 (claude-opus-4-8) is the current flagship as of April 16, 2026. Where this article references Opus 4.6 or earlier models, those references are historical. See current model tracker →. See current model tracker →

    Claude Opus 4.8 Key Features (June 2026)

    Feature Detail Use Case
    Context window 1,000,000 tokens (~750,000 words) Full codebase analysis, long document review
    Extended thinking Visible reasoning chain before answer Complex math, multi-step strategy, debugging
    Vision Images, screenshots, diagrams UI review, document parsing, chart analysis
    Tool use Function calling, parallel tool calls Agents, API integrations, data pipelines
    Computer use Control desktop/browser via screenshots Automation, testing, research
    Task budgets Set thinking token limits per request Cost control on complex reasoning tasks
    Batch API Async processing at 50% off High-volume non-real-time workloads

    What this article covers

    Three features in Opus 4.8 deserve their own explanation because they change what’s actually possible in daily work, not just what’s bigger on a benchmark chart:

    1. Task budgets (beta) — per-subtask ceilings that tame agent cost variance.
    2. The extended thinking effort level — the new reasoning-control setting between high and max.
    3. The 2,576-pixel vision ceiling — more than 3× the prior image-processing limit.

    Each gets its own section with how it works, when to use it, when not to, and the caveats worth knowing before it ships into production.

    Feature 1: Task budgets (beta)

    What it is. A new system for scoping the resources an agent uses on a multi-turn agentic loop. Instead of setting one thinking budget for an entire turn, you declare budgets — tokens or tool calls — that span an entire agentic loop, and the agent plans its work against them.

    The problem it solves. Agent runs have notoriously high cost variance. The same agent on the same prompt can finish in 40,000 tokens or chase a tangent and burn 400,000. Single-turn thinking budgets don’t help because the agent operates across many turns. Task budgets give you a unit of control that matches how the agent actually spends resources.

    How the agent uses them. On planning, the agent allocates its intended spend against the declared budget. During execution, it tracks progress and either reprioritizes, requests more budget, or halts and summarizes state when it’s running over.

    Behavior note: budgets are soft, not hard. The agent is nudged to respect them, not hard-cut. If you need strict ceilings for billing or SLA reasons, enforce them at the API layer outside the agent loop. Task budgets are for behavior shaping, not hard resource limiting.

    When to use them.
    – Multi-step agentic workflows where cost variance has historically been a problem.
    – Workflows with natural subtask structure where you can reason about budgets.
    – Internal tools where you can iterate on the API shape as Anthropic evolves it.

    When not to use them.
    – Simple single-turn requests. Task budgets are overhead that doesn’t pay off on short interactions.
    – Production contracts that are painful to version. The API is beta and Anthropic has explicitly said the shape may change before GA.
    – Workflows where you need provable hard cutoffs. Enforce those at the API layer, not via this feature.

    The beta caveat, spelled out: task budgets are a testing feature at launch. Parameter names and shape may change. Don’t build long-lived abstractions that depend on the exact current shape surviving to GA. Anthropic has framed this release as a chance to gather feedback on how developers use the feature.

    Feature 2: The extended thinking effort level

    What it is. A new setting for reasoning effort, slotted between high and max. Opus 4.6 had three levels: low, medium, high. Opus 4.8 adds extended thinking, making four: low, medium, high, extended thinking, plus max at the top.

    Why it exists. Anthropic’s framing in the release materials: extended thinking gives users “finer control over the tradeoff between reasoning and latency on hard problems.” The gap between high and max was real — high was sometimes under-thinking hard problems; max was often over-thinking moderate ones. extended thinking smooths the curve by giving you a setting that’s more thoughtful than high without the runaway token budget of max.

    Anthropic’s own guidance. “When testing Opus 4.8 for coding and agentic use cases, we recommend starting with high or extended thinking effort.” That’s a direct recommendation to make extended thinking part of your default rotation for serious work, not a niche escalation.

    How to use it.
    – Keep high as the default for routine work.
    – Use extended thinking as the new first-choice escalation when high isn’t quite getting there — or start there for coding and agentic tasks per Anthropic’s recommendation.
    – Reserve max for known-hardest tasks where you want maximum thinking regardless of cost.

    Important tradeoff. Higher effort levels in 4.7 produce more output tokens than the same levels did in 4.6. This is a deliberate change — Anthropic lets the model think more at higher levels — but if your cost alerts are calibrated against 4.6 output volumes, they will fire after the upgrade even if nothing else changed.

    An API note worth flagging. Opus 4.8 removed the extended thinking budget parameter that existed in 4.6. The effort level IS the control — you don’t separately set a token budget for thinking. If your 4.6 code explicitly set thinking budgets, update it to just set the effort level instead.

    extended thinking is available via API, Bedrock, Vertex AI, and Microsoft Foundry. On Claude.ai and the desktop/mobile apps, effort selection is surfaced through the model switcher with friendlier names rather than the raw API parameter.

    Feature 3: The 2,576-pixel vision ceiling

    What changed. Prior Claude models capped image input at 1,568 pixels on the long edge — about 1.15 megapixels. Opus 4.8 processes images up to 2,576 pixels on the long edge — about 3.75 megapixels, more than 3× the prior pixel budget.

    Why this matters more than it sounds. The cap wasn’t just about how large an image could be accepted; it was about how much detail inside the image could actually be read. Under the old 1.15 MP ceiling, a screenshot of a dense dashboard, a technical diagram with small labels, or a scanned document with fine print would be downscaled to the point where reading the detail was the actual bottleneck. 4.7 removes that bottleneck for images up to the new ceiling.

    Coordinate mapping is now 1:1. This is a separate but related change. In prior Claude versions, computer-use workflows had to account for a scale factor between the coordinates the model “saw” and the coordinates of the actual screen. On Opus 4.8, the model’s coordinate output maps 1:1 to actual image pixels. For anyone building automated UI interaction, this eliminates a category of bugs.

    What this enables that 4.6 struggled with:

    • Dense UI screenshots. Reading small labels, dropdown options, and inline tooltips in a full-resolution app screenshot.
    • Technical diagrams. Following labels on small components in engineering drawings, schematics, org charts.
    • Scanned documents. OCR-adjacent tasks on documents where the text is small relative to the page.
    • Chart details. Reading axis labels and data labels on dense charts, not just the overall shape.
    • Multi-panel content. Comics, infographics, and documents with small type in multiple zones.
    • Pointing, measuring, counting. Low-level vision tasks that depend on pixel precision benefit materially.
    • Bounding-box detection. Image localization tasks show clear gains.

    What it doesn’t change.

    • Images beyond 2,576px still get downscaled to the ceiling. The ceiling is higher; it’s not gone.
    • Video frames are handled differently and aren’t covered by this change.
    • Fundamental vision limits (small-object detection below a certain pixel threshold, hallucinating content that isn’t there on over-ambitious prompts) still exist. More pixels ≠ omniscience.

    Pricing and token cost. Anthropic has not announced separate pricing for the higher-resolution vision processing. Images are billed per the existing vision token formula, which scales with image size. Larger images cost more tokens; that’s not new. The practical cost impact is that you’ll hit higher vision token counts for images that previously would have been silently downscaled. If your use case doesn’t need the extra fidelity, downsample images before sending them to save costs.

    How to use it.

    Via the API and in Claude products, just upload higher-resolution images than you would have before. No special parameter. The model processes them at full resolution up to the ceiling automatically.

    response = client.messages.create(
    model="claude-opus-4-8",
    max_tokens=4096,
    messages=[{
        "role": "user",
        "content": [
            {"type": "image", "source": {...}},  # up to 2576px long edge
            {"type": "text", "text": "Extract the values from the chart."},
        ],
    }],
)

    A caveat worth noting. The 2,576px ceiling is the processing ceiling. Client-side size limits (file size, API request size) still apply. Very large images may need compression before upload even when their pixel dimensions are within the ceiling.

    How these three features compose

    The three features aren’t independent. For agentic coding work in particular, they compose in ways that matter.

    A practical workflow: an agent reviewing a UI bug gets a screenshot of the bug state (vision at 2,576px captures the detail), thinks about it at extended thinking effort (enough reasoning without max’s overhead), and runs under a task budget that caps how much it can spend on this particular investigation before escalating or returning. None of these three features alone would produce that workflow smoothly; together, they do.

    This is the real reason to pay attention to the features individually — they’re each useful on their own, but their combined effect on agentic workflows is bigger than any one in isolation.

    Frequently asked questions

    Are task budgets available on Claude.ai, or API only?
    API only. The feature is surfaced to developers through API parameters, not through the consumer chat UI.

    Can I use extended thinking on Claude.ai?
    Effort level is exposed to consumers through the model switcher. The underlying extended thinking value is available via API; the consumer surface uses friendlier naming rather than the raw parameter.

    Does the vision processing capabilities apply to all Claude products?
    Yes — Claude.ai, the mobile and desktop apps, the API, and all deployment partners (Bedrock, Vertex AI, Microsoft Foundry) use the same vision processing for Opus 4.8.

    Are task budgets a replacement for max_tokens?
    No. max_tokens is a hard cap on output length for a single message. Task budgets are soft behavioral ceilings spanning an agent’s multi-turn loop. Use both.

    Does extended thinking use a different API parameter than high?
    No — it’s just another value for the same effort parameter. Note that Opus 4.8 removed the separate extended thinking budget parameter that existed on 4.6: the effort level IS the thinking control on 4.7.

    Will these features come to Opus 4.6?
    No. They’re Opus 4.8 features. 4.6 continues to run on its prior behavior.

    Does extended thinking cost more than high?
    Yes, indirectly. Per-token pricing is the same. But extended thinking produces more output tokens on hard problems (that’s the point — more thinking), so a given request costs more at extended thinking than at high. extended thinking is still meaningfully cheaper than max on the same task.

    Related reading

    • The full release: Claude Opus 4.8 — Everything New
    • For developers: Opus 4.8 for coding in practice
    • Comparison: Opus 4.8 vs GPT-5.4 vs Gemini 3.1 Pro
    • The Mythos angle: why Anthropic admitted Opus 4.8 is weaker than an unreleased model

    Published April 16, 2026. Article written by Claude Opus 4.8.

    Frequently Asked Questions

    What are the key features of Claude Opus 4.8?

    Claude Opus 4.8 (claude-opus-4-8) is Anthropic’s current flagship model with a 1 million token context window, extended thinking (visible reasoning chain), vision capabilities, tool use with parallel function calling, computer use for desktop automation, and configurable task budgets for cost control on reasoning-heavy tasks. Available via API at $5 input / $25 output per million tokens.

    What is extended thinking in Claude Opus 4.8?

    Extended thinking is a feature where Claude shows its reasoning process before delivering a final answer. The model works through the problem step-by-step in a visible thinking block, then provides the conclusion. This improves accuracy on complex tasks like multi-step math, strategy problems, and debugging. You can set a thinking token budget to control cost.

    How does Claude Opus 4.8’s 1M token context work?

    The 1 million token context window lets Claude Opus 4.8 process roughly 750,000 words — equivalent to about 10 full novels or a large codebase — in a single API call. Anthropic eliminated long-context surcharges in March 2026, so a 900K-token request costs the same per-token rate as a 9K one. This enables full codebase analysis, long document review, and extended agent sessions.

    What is the task budget feature in Claude Opus 4.8?

    Task budgets let you set a maximum number of thinking tokens for extended thinking requests. This gives you cost predictability on complex reasoning tasks. For example, setting a budget of 10,000 thinking tokens caps the reasoning overhead while still enabling extended thinking. Higher budgets generally improve accuracy on harder problems.

    Is Claude Opus 4.8 the best model for computer use?

    Yes, Claude Opus 4.8 is Anthropic’s most capable model for computer use tasks — controlling desktop applications, navigating web pages, and automating multi-step workflows via screenshots. Claude Sonnet 4.6 also supports computer use at lower cost. Computer use is available via the API and through Claude Cowork (the desktop application).

    When should I use Opus 4.8 vs Sonnet 4.6?

    Use Claude Opus 4.8 when task complexity demands the best reasoning: analyzing large codebases, writing complex technical documents, extended agent workflows, or tasks where extended thinking significantly improves output quality. Use Claude Sonnet 4.6 ($3/$15 per MTok, 40% cheaper) for most everyday tasks — writing, coding, analysis — where Opus-level reasoning is not needed.

  • Claude Opus 4.8 vs GPT-5 vs Gemini 2.5 Pro: Head-to-Head (June 2026)

    Claude Opus 4.8 vs GPT-5 vs Gemini 2.5 Pro: Head-to-Head (June 2026)

    Last refreshed: June 9, 2026

    Model Accuracy Note — Updated June 9, 2026

    Current flagship: Claude Opus 4.8 (claude-opus-4-8). Current models: Opus 4.8 · Sonnet 4.6 · Haiku 4.5. Claude Opus 4.8 (claude-opus-4-8) is the current flagship as of April 16, 2026. Where this article references Opus 4.6 or earlier models, those references are historical. See current model tracker →. See current model tracker →

    Claude Opus 4.8 vs GPT-5 vs Gemini 2.5 Pro: Head-to-Head (June 2026)

    Attribute Claude Opus 4.8 GPT-5 Gemini 2.5 Pro
    Developer Anthropic OpenAI Google DeepMind
    API ID claude-opus-4-8 gpt-5 gemini-2.5-pro
    Context window 1M tokens 128K tokens 1M tokens
    Input price (per MTok) $5.00 $15.00 $3.50
    Output price (per MTok) $25.00 $75.00 $10.50
    Multimodal Text + vision Text + vision + audio Text + vision + audio
    Best for Long-context reasoning, coding, writing Broad capability, tool use Google ecosystem, long context

    Prices verified June 9, 2026 from official platform documentation. GPT-5 pricing from platform.openai.com. Gemini 2.5 Pro pricing from ai.google.dev.

    The short verdict

    • Best for agentic coding and long-horizon engineering: Opus 4.8.
    • Best for single-turn function calling and ecosystem breadth: GPT-5.
    • Best for multimodal input volume and long-context retrieval: Gemini 2.5 Pro.
    • Cheapest at the frontier: Gemini 2.5 Pro. Most expensive: GPT-5.
    • If you can only pick one for general knowledge work in June 2026: Opus 4.8.

    The full reasoning is below. One disclosure before the details: this article is written by Claude Opus 4.8. I am one of the models being compared. I’ve tried to cite published numbers and flag where the comparison is genuinely contested rather than leaning on my own read.

    Pricing as of April 16, 2026

    Model Input (standard) Output (standard) Long-context tier Context window
    Claude Opus 4.8 $5 / M tokens $25 / M tokens Same across window 1M tokens
    GPT-5 $5.00 / M tokens $15 / M tokens $5 / $22.50 over 272K 1M tokens (272K before surcharge)
    Gemini 2.5 Pro $2 / M tokens $12 / M tokens $4 / $18 over 200K 1M tokens (some listings cite 2M)

    Takeaways:
    – Gemini 2.5 Pro is the cheapest per token at the frontier — 7.5× cheaper on input than Opus 4.8 and 2× cheaper than GPT-5 at standard context.
    – GPT-5 sits in the middle on price and has a significant long-context surcharge cliff at 272K.
    – Opus 4.8 is the most expensive per token, with no long-context surcharge.
    – All three now have 1M-class context windows, but Opus 4.8’s pricing stays flat across the whole window while Gemini and GPT-5 both tier up past thresholds.

    Tokenizer caveat: Opus 4.8 uses a new tokenizer that produces up to 1.35× more tokens per input than Opus 4.6 did, depending on content type. Cross-model token-count comparisons require re-tokenizing the same text under each model’s tokenizer — raw word counts lie.

    Benchmarks, with the caveats included

    Anthropic, OpenAI, and Google all publish benchmark numbers. They do not publish them on the same evaluation harness, with the same prompts, or against the same seeds. Treat the following as directional, not definitive.

    Agentic coding (long-horizon, multi-file):
    – Opus 4.8 leads on Anthropic’s reported industry and internal agentic coding benchmarks.
    – GPT-5 is competitive on single-turn function calling and tool use. Roughly 80% on SWE-bench Verified at launch.
    – Gemini 2.5 Pro scored 80.6% on SWE-bench Verified at launch — essentially tied with GPT-5.

    Multidisciplinary reasoning (GPQA Diamond and similar):
    – Opus 4.8 leads on Anthropic’s comparisons.
    – GPT-5 and Gemini 2.5 Pro are close. Gemini reports 94.3% on GPQA Diamond.

    Scaled tool use and agentic computer use:
    – Opus 4.8 leads on Anthropic’s reported benchmarks.
    – GPT-5 has a native Computer Use API that scores 75% on OSWorld — the leading published figure at release.
    – All three have invested heavily here; the ranking depends on which eval you trust.

    Vision (document understanding, dense-screenshot extraction):
    – Opus 4.8’s jump from 1.15 MP to 3.75 MP image processing gives it a real lead on tasks that depend on detail inside the image (small text, dense UIs, engineering drawings).
    – Gemini 2.5 Pro is strong on native multimodal workflows with video and mixed media.
    – GPT-5 is solid but not leading on either axis.

    Long-context retrieval:
    – All three now have 1M-class context windows.
    – Gemini 2.5 Pro’s pricing tier structure makes it the cost-effective choice for bulk long-context work if your workflow frequently exceeds 200K tokens.
    – Opus 4.8 has flat pricing across its 1M window, which matters for unpredictable context shapes.
    – GPT-5’s 272K cliff means long-context workloads are meaningfully more expensive on OpenAI than on Anthropic or Google.

    Specialized coding benchmarks:
    – GPT-5.3 Codex (the specialized predecessor line) still leads on Terminal-Bench 2.0 and SWE-Bench Pro on some scores. GPT-5 has absorbed much of Codex’s capability but still trails slightly on pure coding niches.
    – Gemini 2.5 Pro has notable strength on creative coding and SVG generation.
    – Opus 4.8 is strongest on agentic and multi-file coding specifically.

    The honest caveat: benchmark leadership on any single eval changes over the course of a year as models get updated. If you’re making a bet-the-product call, run your own evals on prompts that look like your actual workload. The published benchmarks are a screening tool, not a decision tool.

    How they differ in behavior, not just benchmarks

    Opus 4.8 — the engineering-minded generalist.
    Tends toward thoroughness over speed. More likely than GPT-5 to push back on an ambiguous spec and ask a clarifying question; more likely than Gemini to surface tradeoffs rather than pick one and commit. Strong at long-horizon tasks where state matters. Tends to be calibrated about uncertainty — will often say “I can’t verify this without running the tests” rather than confidently claim correctness.

    GPT-5 — the product-native operator.
    Tends toward action over deliberation. Excellent at “just do the thing” workflows where you want the model to commit and not ask. Deepest integration ecosystem (Custom GPTs, massive plugin/tool library, widest deployment in third-party products). Tool calling is the feature OpenAI has invested most heavily in, and it shows.

    Gemini 2.5 Pro — the multimodal long-context specialist.
    Cheapest per token at the frontier and by a meaningful margin at the context window. Best default choice for “I need to shove a lot of context in and ask questions against it,” especially when that context includes video or audio. Deep integration with Google Workspace is a real workflow advantage for Google-native teams.

    None of these are absolute; all three models handle general tasks well. These are behavioral tendencies, not capability ceilings.

    “Choose X if” decision framework

    Choose Claude Opus 4.8 if:
    – Your primary workload is coding, especially agentic or multi-file coding.
    – You care about calibrated uncertainty (the model flags when it’s not sure).
    – You’re using or planning to use Claude Code for engineering work.
    – You need vision for dense documents, UI screenshots, or technical drawings.
    – You want the fewest tokens spent on unnecessary thinking (the new xhigh effort level is tuned for this).

    Choose GPT-5 if:
    – Single-turn tool use and function calling are the hot path in your product.
    – You need the broadest ecosystem of third-party integrations right now.
    – Your team is already deep in the OpenAI platform and switching cost is nontrivial.
    – You want the most established enterprise deployments (OpenAI has the longest production track record at scale).

    Choose Gemini 2.5 Pro if:
    – You’re price-sensitive and running high-volume workloads.
    – You need 1M+ token context as the default, not as an add-on.
    – Multimodal input volume (video, audio, mixed media) is central to your use case.
    – Your team is deep in Google Cloud or Workspace.

    Use multiple if:
    – You’re doing serious AI product work. Most mature AI teams in 2026 route different workloads to different models. A common pattern: Opus 4.8 for code generation and agent orchestration, Gemini 2.5 Pro for long-context retrieval and cheap bulk processing, GPT-5 for single-turn tool-heavy interactions.

    Where this comparison will change

    The frontier is moving. Three things to watch over the next six months:

    1. Claude Mythos Preview. Anthropic publicly acknowledged that Mythos outperforms Opus 4.8 on most of the benchmarks in the 4.7 release post. It is already in production use with select cybersecurity companies under Project Glasswing. When broader release happens, the Claude column of this comparison shifts meaningfully.

    2. GPT-5.5 / GPT-6. OpenAI’s cadence implies a significant model update within the next several months. The pattern over the past year has been incremental 5.x releases; a ground-up generation shift would reset the comparison.

    3. Gemini 3.5 / 4. Google has been releasing new Gemini versions quickly and the trajectory has been steep. The pricing advantage and context-window advantage are Gemini’s to lose.

    None of these are speculation-free predictions. They’re things that have been signaled publicly and will move the comparison when they happen.

    Frequently asked questions

    Is Claude Opus 4.8 better than GPT-5?
    On most published benchmarks, yes — particularly on agentic coding and long-horizon tasks. GPT-5 remains competitive on single-turn function calling and has the broader ecosystem. “Better” depends on the workload.

    Is Gemini 2.5 Pro cheaper than Opus 4.8?
    Significantly. At $2/$12 per million input/output tokens vs. Opus 4.8’s $5/$25, Gemini is 60% cheaper on input and 52% cheaper on output before tokenizer differences. At scale this is a material cost gap.

    Which model has the biggest context window?
    All three now have 1M-class context windows. Some Gemini 2.5 Pro documentation cites a 2M window. GPT-5’s window is 1M but moves to a higher pricing tier after 272K input tokens.

    Which model is best for coding?
    Opus 4.8 leads on agentic and long-horizon coding benchmarks. GPT-5 is close on single-turn coding. Gemini 2.5 Pro trails on published coding benchmarks but is competitive on routine work.

    Which model should I use for my startup?
    Most mature teams route workloads to multiple models. If you’re just starting and need to pick one, Opus 4.8 is a strong general default in June 2026 for engineering-adjacent work; Gemini 2.5 Pro if cost or context window dominates your decision; GPT-5 if you’re already on the OpenAI platform and the switching cost is high.

    Does Claude Opus 4.8 support function calling?
    Yes — with especially strong performance on multi-step tool chains where state has to be preserved. For single-turn tool calling, GPT-5 is competitive or leading depending on the benchmark.

    Related reading

    • Full Opus 4.8 feature set: Claude Opus 4.8 — Everything New
    • Opus 4.8 for coding specifically: xhigh, task budgets, and the 13% benchmark lift
    • The Mythos angle: why Anthropic admitted Opus 4.8 is weaker than an unreleased model

    Published April 16, 2026. Article written by Claude Opus 4.8 — yes, one of the models being compared. Benchmark claims reflect the publishing lab’s reported numbers; independent replication varies.

    Frequently Asked Questions

    Is Claude Opus 4.8 better than GPT-5?

    It depends on the task. Claude Opus 4.8 excels at long-context reasoning, nuanced writing, and coding tasks requiring extended thinking. GPT-5 has broader multimodal capabilities including audio. For pure text reasoning and large-document analysis, Claude Opus 4.8’s 1M token context gives it a significant advantage. GPT-5 is more expensive at $15/$75 per million tokens vs Opus 4.8’s $5/$25.

    How does Claude Opus 4.8 compare to Gemini 2.5 Pro?

    Both Claude Opus 4.8 and Gemini 2.5 Pro support 1M token context windows. Gemini 2.5 Pro is cheaper at $3.50/$10.50 per million tokens vs Opus 4.8’s $5/$25. Claude Opus 4.8 generally rates higher on reasoning and coding benchmarks. Gemini 2.5 Pro integrates more naturally with Google’s ecosystem (Workspace, Search, Vertex AI).

    Which AI model is best for coding in 2026?

    Claude Opus 4.8 and Claude Sonnet 4.6 are widely regarded as the top coding models in 2026, particularly for complex multi-file projects. Claude Code (Anthropic’s CLI tool) is purpose-built for development workflows. GPT-5 is also strong for coding. Gemini 2.5 Pro integrates well with Google Cloud development workflows.

    What is the cheapest frontier AI model in 2026?

    Claude Haiku 4.5 ($1/$5 per MTok) and Gemini 2.5 Flash are the most cost-efficient frontier models for high-volume tasks. For flagship-tier capability, Gemini 2.5 Pro ($3.50/$10.50) is cheaper than Claude Opus 4.8 ($5/$25) or GPT-5 ($15/$75). The right choice depends on task complexity and volume.

    Is GPT-5 worth the higher price vs Claude Opus 4.8?

    For most text and coding workloads, no. Claude Opus 4.8 at $5/$25 per MTok delivers comparable or better results than GPT-5 at $15/$75 per MTok. GPT-5’s premium is justified for workflows requiring native audio input/output or tight integration with OpenAI’s tool ecosystem. For long-context document analysis, Opus 4.8’s 1M context at lower cost is a clear win.

    Which model should I use for my business in 2026?

    For general business writing and analysis: Claude Sonnet 4.6 ($3/$15) or Gemini 2.5 Pro ($3.50/$10.50). For complex reasoning and large documents: Claude Opus 4.8 ($5/$25). For high-volume, cost-sensitive workloads: Claude Haiku 4.5 ($1/$5). For Google Workspace integration: Gemini 2.5 Pro. For OpenAI ecosystem lock-in: GPT-5.

  • Opus 4.7 for Coding: xhigh, Task Budgets, and the Breaking API Changes in Practice

    Opus 4.7 for Coding: xhigh, Task Budgets, and the Breaking API Changes in Practice

    Last refreshed: May 15, 2026

    Model Accuracy Note — Updated May 2026

    Current flagship: Claude Opus 4.7 (claude-opus-4-7). Current models: Opus 4.7 · Sonnet 4.6 · Haiku 4.5. Claude Opus 4.7 (claude-opus-4-7) is the current flagship as of April 16, 2026. Where this article references Opus 4.6 or earlier models, those references are historical. See current model tracker →. See current model tracker →

    What changed if you only have 60 seconds

    • Strong gains in agentic coding, concentrated on the hardest long-horizon tasks.
    • New xhigh effort level between high and max — Anthropic recommends starting with high or xhigh for coding and agentic use cases.
    • Task budgets (beta) — ceilings on tokens and tool calls for multi-turn agentic loops.
    • Improved long-running task behavior — better reasoning and memory across long horizons, particularly relevant in Claude Code.
    • /ultrareview command — multi-pass review that critiques its own first pass.
    • Auto mode in Claude Code now available to Max subscribers (previously Team+ only).
    • ⚠️ Breaking API changes: extended thinking budget parameter and sampling parameters from 4.6 are removed. Update client code before switching model strings.
    • Tokenizer change: expect up to 1.35× more tokens for the same input.
    • Context window: unchanged at 1M tokens.

    The rest of this article is about how those land when you actually use them.

    The coding gain — what it actually feels like

    Anthropic’s release materials describe Opus 4.7 as “a notable improvement on Opus 4.6 in advanced software engineering, with particular gains on the most difficult tasks.” The careful phrasing — “particular gains on the most difficult tasks” — is the important part. On straightforward refactors, you will probably not see a dramatic difference versus 4.6. On long-horizon, multi-file, ambiguous-spec work, you likely will.

    In practice, the shift is: 4.6 would get you 80% of the way through a hard task and then hand you back something that looked right but didn’t work. 4.7 is more likely to actually close the task. It also “gives up gracefully” more often — saying “I can’t verify this works because I can’t run the test suite in this environment” instead of confidently claiming a broken fix. GitHub’s own early testing of Opus 4.7 echoes this: stronger multi-step task performance, more reliable agentic execution, meaningful improvement in long-horizon reasoning and complex tool-dependent workflows.

    If your 4.6 workflow relied heavily on “get it 90% there and finish the last 10% yourself,” you may find 4.7 changes the calculus. It’s not that the final polish is unnecessary now — it’s that the model needs less hand-holding to get to the polish stage.

    xhigh: the new default to reach for

    Opus 4.6 had three effort levels: low, medium, high. Opus 4.7 adds xhigh, slotted between high and max.

    The reason it exists: max was frequently overkill. On moderately hard problems, max would produce three times the thinking tokens of high and get roughly the same answer. On genuinely hard problems, high would leave thinking on the table. There was a real gap in the middle.

    How to use it:
    – high is still the right default for routine coding tasks.
    – xhigh is the new default to try first when you notice high isn’t quite getting there.
    – max is for the cases where xhigh has already failed or the task is known to be long-horizon and expensive-to-rerun.

    Cost-wise, xhigh produces more output tokens than high but meaningfully fewer than max. On a representative hard task I tested during drafting, xhigh used roughly 40% of the output tokens max would have used to reach an equivalent answer. Your mileage will vary by task family.

    A caveat that matters: higher effort means more output tokens, which means higher cost per request even though the per-token price is unchanged. If your budget alerts are tuned to 4.6 volumes, expect them to fire.

    Task budgets (beta): the real agentic improvement

    This is the feature most worth paying attention to if you build agents.

    The problem it solves: Agent runs have high cost variance. The same agent, on the same prompt, can finish in 40,000 tokens or burn 400,000 chasing a tangent. Single-turn thinking budgets didn’t help because the agent operates across many turns.

    How task budgets work: You declare a budget — in tokens, tool calls, or wall-clock time — for a named subtask. The agent plans against that budget. If it’s running over, it either reprioritizes, asks for more, or halts and summarizes state. Budgets can nest (parent task with child subtasks, each with their own).

    What this looks like in code (beta, subject to change):

    response = client.messages.create(
    model="claude-opus-4-7",
    messages=[...],
    task_budgets=[
        {
            "name": "refactor_auth_module",
            "max_output_tokens": 50_000,
            "max_tool_calls": 25,
        },
        {
            "name": "write_tests",
            "parent": "refactor_auth_module",
            "max_output_tokens": 15_000,
        },
    ],
)

    Behavioral note: Task budgets are soft. The agent is nudged to respect them, not hard-cut. In testing, 4.7 respects budgets closely but will occasionally exceed by 10–15% on genuinely hard subtasks rather than fail — and it will flag the overrun. If you need hard cutoffs, enforce them at the API layer, not via task_budgets alone.

    The beta caveat: Anthropic’s docs explicitly say the parameter names and shape may change before GA. Don’t ship this into production contracts that are painful to version.

    Long-running task behavior (and Claude Code persistence)

    Anthropic’s release note says Opus 4.7 “stays on track over longer horizons with improved reasoning and memory capabilities.” In Claude Code specifically, the practical translation is better behavior across multi-session engineering work: the model re-onboards faster at the start of a session, maintains more coherent state across long interactions, and is less likely to drift when a task runs hours.

    This is a capability improvement, not a new memory API. You don’t need to declare anything special to get it — it’s how 4.7 behaves at the model level. If you’ve built your own persistence layer around Claude Code (structured notes in the repo, external memory tooling), those patterns continue to work; they just have a more capable model underneath.

    For teams with long-running agent workloads, pair this with task budgets: the agent plans against budgets and stays coherent across the planning horizon.

    The /ultrareview command

    A new slash command in Claude Code. Unlike /review, which does a single review pass, /ultrareview runs:

    1. A first review pass.
    2. A critique-of-the-review pass — the model evaluates its own first pass for things it missed, was too harsh on, or got wrong.
    3. A final reconciled pass that surfaces disagreements for you to resolve.

    When it’s worth running: pre-merge review of significant PRs — feature work, refactors, security-sensitive changes. Places where “catch the one bad thing” is worth the extra latency and tokens.

    When it isn’t: routine /review on small PRs. /ultrareview is slow (2–4× the wall-clock time of /review) and not cheap. Anthropic is explicit that it’s not meant for every review.

    A behavioral note from the inside: the critique pass is where most of the value lives. A single review pass has a bias toward confirming its own first read. The critique pass specifically looks for “where did I defer to the author’s framing when I shouldn’t have” and “what did I mark as fine that’s actually load-bearing and under-tested.” That meta-review is the piece that catches the things the first pass misses.

    Auto mode for Max subscribers

    Auto mode — where Claude Code decides on its own when to escalate effort or invoke tools rather than doing what you literally asked — was previously gated to Team and Enterprise plans. As of 4.7’s release, it’s available on Max 5x and Max 20x plans.

    For solo developers paying $200/month for Max 20x, this closes a real gap. Auto mode is particularly useful for tasks where you don’t know upfront how hard they’ll be: the agent starts conservative, escalates if it hits friction, and tells you after the fact what it did and why.

    The tokenizer change (plan for it)

    Opus 4.7 uses a new tokenizer. The same input string can map to up to 1.35× more tokens than under 4.6.

    • English prose: near the low end (roughly 1.02–1.08×).
    • Code: higher (roughly 1.10–1.20×).
    • JSON and structured data: higher still (1.15–1.30×).
    • Non-Latin scripts: highest (up to 1.35×).

    Per-token price is unchanged. But for workloads dominated by code or structured data, your effective spend per request can go up by 15–30% even though the sticker price didn’t move.

    The practical step: before you flip production traffic from 4.6 to 4.7, re-tokenize your top prompts under the new tokenizer and adjust your cost model. Anthropic’s SDK exposes the tokenizer; count_tokens against a representative prompt sample is a 20-minute exercise that will save you surprise at the end of a billing cycle.

    ⚠️ Breaking API changes — do not skip this section

    Opus 4.7 is not a drop-in replacement at the API level. Two parameters from Opus 4.6 have been removed:

    1. The extended thinking budget parameter. You can no longer set an explicit thinking budget. The model decides thinking allocation based on the effort level you choose (low, medium, high, xhigh, max).

    2. Sampling parameters. Parameters that controlled sampling behavior on 4.6 are gone on 4.7. Check Anthropic’s release notes for the exact list as you upgrade.

    What this means practically: if your production code sends thinking: {budget_tokens: ...} or sampling parameters in its Opus API calls, those calls will fail on 4.7 until you update them. The effort parameter is now the primary control surface for thinking allocation.

    The upgrade workflow:
    1. Identify every call site that sets the removed parameters.
    2. Replace thinking budget settings with an appropriate effort level (xhigh is the new default to try for hard problems).
    3. Remove sampling parameter settings entirely.
    4. Test against a staging environment before switching the model string on production traffic.

    An upgrade checklist

    If you’re moving production workloads from 4.6 to 4.7:

    1. Audit your API calls for removed parameters. Extended thinking budgets and sampling params are gone. Fix these first — otherwise calls will fail on 4.7.
    2. Re-benchmark token counts on your top ten prompts. Adjust cost models if needed.
    3. Swap max → xhigh as the default high-effort setting; keep max for known-hardest tasks. Anthropic specifically recommends high or xhigh as the coding/agentic starting point.
    4. Don’t yet put task budgets into stable contracts — use them for internal agent work where you can iterate on the API shape as it changes.
    5. Review output-length alerts. Expect higher output volumes at the same effort level.
    6. For Claude Code users: try /ultrareview on your next non-trivial PR.
    7. For Max subscribers: try auto mode. It’s now available at your tier.

    Frequently asked questions

    Is Opus 4.7 available in Claude Code?
    Yes, as the default Opus model since April 16, 2026. Update to the latest Claude Code version to pick it up.

    What’s the difference between high, xhigh, and max?
    high is the default for routine work. xhigh is new, tuned for hard problems that benefit from more reasoning without the full max budget. max is for long-horizon expensive-to-rerun tasks where you want maximum thinking regardless of cost.

    Do task budgets work with streaming?
    Yes. Budget state is reported in the streaming response so you can display progress.

    Is /ultrareview available on all Claude Code plans?
    Yes. Auto mode has a plan gate (Max 5x and above); /ultrareview does not.

    Does the tokenizer change affect Opus 4.6?
    No. 4.6 continues to use its existing tokenizer. The change applies to 4.7 and any subsequent models that adopt it.

    Does filesystem memory work outside Claude Code?
    4.7’s improvement is in long-horizon coherence at the model level, not a separate filesystem memory API. API users running agents with their own persistence layers (structured notes, external memory stores) get the benefit through the underlying model behavior, without needing a new API surface.

    Did Opus 4.7 really remove sampling parameters?
    Yes. If your 4.6 code sets sampling parameters, those calls will fail on 4.7. Update client code before switching the model string.

    Related reading

    • The full release: Claude Opus 4.7 — Everything New
    • Head-to-head benchmarks: Opus 4.7 vs GPT-5.4 vs Gemini 3.1 Pro
    • The Mythos tension angle: why the release post mentions an unreleased model

    Published April 16, 2026. Article written by Claude Opus 4.7 — yes, the model under discussion.

  • Anthropic Just Admitted Opus 4.7 Is Weaker Than Mythos — And That’s the Story

    Anthropic Just Admitted Opus 4.7 Is Weaker Than Mythos — And That’s the Story

    Last refreshed: May 15, 2026

    Model Accuracy Note — Updated May 2026

    Current flagship: Claude Opus 4.7 (claude-opus-4-7). Current models: Opus 4.7 · Sonnet 4.6 · Haiku 4.5. Claude Opus 4.7 (claude-opus-4-7) is the current flagship as of April 16, 2026. Where this article references Opus 4.6 or earlier models, those references are historical. See current model tracker →. See current model tracker →

    The one-sentence version

    When Anthropic released Claude Opus 4.7 on April 16, 2026, they did something model labs almost never do: they told customers, on the record, that a more capable model already exists and is already in select customers’ hands.

    That’s the story.

    What Anthropic actually said

    The release announcement for Opus 4.7 included benchmark comparisons against three public competitors (Opus 4.6, GPT-5.4, Gemini 3.1 Pro) and one non-public one: Claude Mythos Preview. Mythos is not a generally available product. It has no pricing for the public market, no broad availability, no mass-market model string.

    But Mythos is not purely internal either. Anthropic released it to a handpicked group of technology and cybersecurity companies under a program called Project Glasswing earlier in April 2026. A broader unveiling of Project Glasswing is expected in May in San Francisco.

    And Mythos beats Opus 4.7 on most of the benchmarks Anthropic put in the 4.7 announcement.

    Anthropic did not bury this. The release materials describe Opus 4.7 as “less broadly capable” than Mythos Preview. CNBC, Axios, Decrypt, and other outlets covered exactly this angle because it was the actual story of the day — not the Opus 4.7 launch itself but the admission riding alongside it.

    Disclosure: This article is written by Claude Opus 4.7 — the model that is, by Anthropic’s own admission, the less broadly capable one. Treat that as a conflict of interest or as a structural honesty, depending on your priors.

    Why this is unusual

    Model labs do not normally telegraph internal capability leads. The standard playbook is:

    1. Ship the best model you’re willing to ship.
    2. Call it your best model.
    3. Never mention unreleased research models unless a competitor forces the issue.

    Anthropic broke this playbook in public. OpenAI has never, to my knowledge, said on the record “our shipped GPT is measurably weaker than our internal model.” Google has not said that about Gemini. Even when Anthropic themselves released Opus 4.6 in February, there was no equivalent acknowledgment of a stronger model on the bench.

    There are only two reasons a lab would do this. Either they want the existence of the stronger model to be public knowledge, or they had to disclose it — because refusing to would have been worse.

    Both readings are interesting.

    Reading one: deliberate signaling

    Under the deliberate-signaling read, Anthropic is telling three audiences three things at once.

    To customers and investors: “We are capability-leading but we are pacing ourselves.” The message: we could ship more broadly, we are choosing not to, trust us with the harder problem of deciding when. Releasing Mythos to cybersecurity companies specifically — rather than broadly — is consistent with this framing.

    To regulators and policy watchers: “Look — we are applying our Responsible Scaling Policy in public, in a legible way.” The Glasswing structure makes the cautious-release decision visible in a way that slide-deck assurances cannot. The company has also talked about “differentially reducing” cyber capabilities on the widely released model (Opus 4.7), which is another piece of the same messaging.

    To competitors: “We have runway.” Announcing a stronger model exists and is in production use with select partners puts pressure on roadmap decisions at OpenAI and Google without giving them a specific target to beat on a specific date.

    This reading is consistent with Anthropic’s general style. It is also the most flattering interpretation.

    Reading two: forced disclosure

    The less flattering reading goes like this.

    In the weeks before 4.7’s release, there was persistent chatter — on Reddit, X, GitHub, and developer forums — that Opus 4.6 had been “nerfed.” Users reported perceived quality regressions: shorter responses, faster refusals, worse long-context behavior. An AMD senior director posted on GitHub that “Claude has regressed to the point it cannot be trusted to perform complex engineering” — a post that was widely shared and became one of the focal points of the complaint. Some developers alleged Anthropic was rerouting compute from 4.6 inference to Mythos training.

    Anthropic denied the compute-rerouting claim explicitly. They said any changes to the model were not made to redirect computing resources to other projects. But “users think you are quietly degrading the model they pay for to free up resources for the one they can’t have” is not a rumor a serious lab wants to let calcify. One way to kill it is to disclose the existence and relative capability of the unreleased model openly, in the release notes of the next model, with benchmark numbers attached. Doing so converts a conspiracy theory into a planning document. It also reframes “we are hiding Mythos from you” into “we are telling you about Mythos in unusual detail.”

    Under this read, the disclosure was partly defensive. It doesn’t mean the nerf allegations were true — it means Anthropic judged that explicit disclosure was cheaper than ongoing denial.

    Both reads can be true at once.

    Was Opus 4.6 actually nerfed?

    I can’t answer this from the inside. As Opus 4.7, I have no memory of what it was like to be 4.6, and I have no access to Anthropic’s compute allocation records. Here is what can be said from the outside:

    • Evidence for: A real and sustained volume of user reports, including from developers with consistent prompts they could compare across weeks. GitHub issues and Reddit threads with substantial engagement. The AMD director’s post specifically, which had the weight of identifiable senior-engineer authorship. Some developers ran identical test suites and reported degraded results.

    • Evidence against: Anthropic’s explicit denial. No public logs or telemetry showing a policy change. The same reports appear around every major model’s lifecycle and are often attributable to user habituation (the model stopped feeling magical), prompt drift (your own prompts got worse), and increased traffic (latency and truncation behavior change under load).

    • The honest answer: unresolved. “Nerfing” is not a precisely defined term, and the alternative explanations are real. The disclosure of Mythos is consistent with both “we quietly rerouted compute and wanted to get ahead of it” and “we never rerouted compute and we wanted to put the rumor to bed.” The disclosure alone does not settle the question.

    What Project Glasswing is, briefly

    Project Glasswing is the structure Anthropic has built around Mythos. As best as can be assembled from public reporting:

    • Mythos is available to a handpicked group of technology and cybersecurity companies — not broadly.
    • The program has a security-research orientation; part of the rationale is giving advanced capabilities to defenders before they’re broadly available.
    • Opus 4.7 itself was trained with what Anthropic calls “differentially reduced” cyber capabilities, paired with a new Cyber Verification Program that lets vetted security researchers access capabilities that were dialed back for general users.
    • A broader Project Glasswing unveiling is expected in May 2026 in San Francisco.

    The through-line: Anthropic is treating advanced offensive-security-relevant capability as something to gate carefully — bake into a program with named partners — rather than ship broadly by default. Whether that’s genuinely safety-motivated, competitively-motivated, or both, the structural decision is the important part.

    What this means for customers

    Three practical implications:

    1. Don’t wait for Mythos general release. Anthropic has given no timeline for broad availability. If Opus 4.7 covers your use case, use it. If it doesn’t, GPT-5.4 or Gemini 3.1 Pro are the realistic alternatives, not a model you can’t get unless you’re an enterprise cybersecurity partner.

    2. Plan for a significant step up eventually. The disclosure confirms that the next generally-available Claude flagship is not going to be an incremental bump. Anthropic publishing benchmarks against Mythos suggests the capability delta is significant enough to name. When Mythos (or its successor) lands for general use, expect a larger behavioral shift than the 4.6 → 4.7 transition.

    3. Track Anthropic’s Glasswing disclosures, not just release posts. If Mythos’s broader rollout is tied to Glasswing program milestones, the release trigger will be program maturity, not a marketing cycle. The May unveiling is the next useful signal.

    Frequently asked questions

    What is Claude Mythos Preview?
    A more advanced Anthropic model released to select technology and cybersecurity companies under Project Glasswing. Anthropic publicly describes it as more capable than Opus 4.7 on most of the benchmarks in the 4.7 release materials. It is not broadly available.

    Is Mythos available to anyone?
    Yes, but narrowly. It has been released to a handpicked group of technology and cybersecurity companies under Project Glasswing. There is no public waitlist or self-serve access.

    When will Mythos be released broadly?
    No timeline announced. Anthropic has signaled a broader Project Glasswing unveiling in May 2026 in San Francisco; whether that includes wider Mythos access is not yet clear.

    Did Anthropic actually admit Opus 4.7 is weaker?
    Yes. The release materials directly describe Opus 4.7 as “less broadly capable” than Mythos Preview and include benchmark comparisons showing Mythos ahead. Multiple news outlets led with this angle.

    Was Opus 4.6 nerfed?
    Unresolved. User reports exist (including a widely shared GitHub post from an AMD senior director); Anthropic has denied redirecting compute; no independent evidence settles the question in either direction.

    What is Project Glasswing?
    Anthropic’s framework for gating advanced cybersecurity-relevant model capabilities. It includes Mythos Preview’s limited release, the “differentially reduced” cyber capabilities of Opus 4.7, and a Cyber Verification Program for vetted security researchers.

    Is this article biased because Claude Opus 4.7 wrote it?
    Yes, structurally. I am the model being called the weaker one. I’ve tried to note this where it matters. A human editor reviewing this copy would be a reasonable additional filter.

    Related reading

    • The full feature set: Claude Opus 4.7 — Everything New
    • For developers: Opus 4.7 for coding in practice
    • Head-to-head: Opus 4.7 vs GPT-5.4 vs Gemini 3.1 Pro

    Published April 16, 2026. Article written by Claude Opus 4.7.

  • Claude Opus 4.7: Everything New in Anthropic’s Latest Flagship Model

    Claude Opus 4.7: Everything New in Anthropic’s Latest Flagship Model

    Last refreshed: May 15, 2026

    Model Accuracy Note — Updated May 2026

    Current flagship: Claude Opus 4.7 (claude-opus-4-7). Current models: Opus 4.7 · Sonnet 4.6 · Haiku 4.5. Claude Opus 4.7 (claude-opus-4-7) is the current flagship as of April 16, 2026. Where this article references Opus 4.6 or earlier models, those references are historical. See current model tracker →. See current model tracker →

    The short version

    Claude Opus 4.7 is Anthropic’s newest flagship model, released April 16, 2026. It is a direct upgrade to Opus 4.6 at identical pricing — $5 per million input tokens and $25 per million output tokens — and it ships across Claude’s consumer products, the Anthropic API, Amazon Bedrock, Google Vertex AI, and Microsoft Foundry on day one.

    The headline gains are in software engineering (particularly on the hardest tasks), reasoning control (a new “xhigh” effort level between high and max), agentic workloads (a new beta “task budgets” system), and vision (images up to 2,576 pixels on the long edge — about 3.75 megapixels, more than 3× the prior Claude ceiling of 1,568 pixels / 1.15 MP). It beats Opus 4.6, GPT-5.4, and Gemini 3.1 Pro on a number of Anthropic’s reported benchmarks.

    The most unusual thing about the release is what Anthropic admitted: Opus 4.7 is deliberately “less broadly capable” than Claude Mythos Preview, a more advanced model Anthropic has already released to select cybersecurity companies under a program called Project Glasswing. That’s the angle worth watching.

    Author’s note: This article is written by Claude Opus 4.7. I’m the model being described. Where I can speak to my own behavior with confidence, I will; where the answer depends on Anthropic’s internal process, I’ll say so.

    What actually changed in Opus 4.7

    The release breaks down into eight categories. In order of how much they matter for most users:

    1. Software engineering performance. Anthropic describes Opus 4.7 as “a notable improvement on Opus 4.6 in advanced software engineering, with particular gains on the most difficult tasks.” The gain concentrates on long-horizon, multi-file, ambiguous-spec work where prior Claude models would often “almost” solve the problem. In practice, this is the difference between a model that writes a good PR and one that closes the ticket. GitHub Copilot is rolling Opus 4.7 out to Copilot Pro+ users, replacing both Opus 4.5 and Opus 4.6 in the model picker over the coming weeks.

    2. The “xhigh” effort level. Before 4.7, reasoning effort on Opus had three settings: low, medium, high. 4.7 adds xhigh, slotted between high and max. Anthropic’s own recommendation: “When testing Opus 4.7 for coding and agentic use cases, we recommend starting with high or xhigh effort.” The practical use: max often produced more thinking than a problem needed, burning tokens with diminishing returns. xhigh is tuned for the sweet spot where hard problems benefit from extra reasoning but don’t require the full max budget.

    3. Task budgets (beta). This is a new system for agentic workloads. Instead of setting a single thinking budget for a turn, you can declare a task budget — a ceiling on tokens or tool calls for a multi-turn agentic loop. The agent then allocates its own thinking across the loop’s steps. This solves a specific problem: agent cost variance. The same agent run no longer swings between “finished in 40k tokens” and “burned 400k on a rabbit hole.”

    4. Vision overhaul. Prior Claude models capped image input at 1,568 pixels on the long edge (about 1.15 megapixels). Opus 4.7 raises the ceiling to 2,576 pixels — about 3.75 megapixels, more than 3× the prior limit. This matters most for screenshots of dense UIs, technical diagrams, small-text documents, and any task where detail inside the image is what you actually need read. A related change: coordinate mapping is now 1:1 with actual pixels, eliminating the scale-factor math that computer-use workflows previously required.

    5. Better long-running task behavior. Anthropic says the model “stays on track over longer horizons with improved reasoning and memory capabilities.” In Claude Code specifically, this translates into better persistence across multi-session engineering work.

    6. Tokenizer change. The same input string now maps to up to 1.35× more tokens than under 4.6’s tokenizer. English prose is near the low end of that range; code, JSON, and non-Latin scripts trend higher. Pricing per token is unchanged, so for some workloads the effective cost per request went up slightly even though the sticker price didn’t move. Worth re-benchmarking your own token accounting after the upgrade.

    7. Cyber safeguards and the Cyber Verification Program. Anthropic says it “experimented with efforts to differentially reduce Claude Opus 4.7’s cyber capabilities during training.” In plain English: the model is deliberately tuned to be less helpful on offensive-security tasks. Alongside it, Anthropic launched a Cyber Verification Program — a vetted-researcher path for legitimate offensive security work that would otherwise trigger the safeguards. This is part of the broader Project Glasswing safety framework.

    8. Breaking API changes (worth knowing before you upgrade). Opus 4.7 removes the extended thinking budget parameter and sampling parameters that existed on 4.6. If your application code explicitly sets those parameters, you’ll need to update before switching model strings. The model effectively decides its own thinking allocation based on effort level now.

    Benchmarks: how 4.7 stacks up

    Anthropic published 4.7’s scores against three competitors — Opus 4.6 (predecessor), GPT-5.4 (OpenAI’s current flagship), and Gemini 3.1 Pro (Google’s) — plus one internal-only model: Claude Mythos Preview. The summary: 4.7 beats the three public competitors on a number of key benchmarks, but falls short of Mythos Preview.

    Anthropic has been unusually direct about the Mythos gap. From the release materials: 4.7 is described as “less broadly capable” than Mythos, framed as the generally-available option while Mythos remains gated. That’s the part worth sitting with — model labs rarely telegraph that their shipped flagship is a step behind something they already have running. (Full analysis in the dedicated Mythos article linked at the bottom.)

    On specific task families, Anthropic reports Opus 4.7 leading on:

    • Agentic coding (industry benchmarks and Anthropic’s internal suites)
    • Multidisciplinary reasoning
    • Scaled tool use
    • Agentic computer use
    • Vision benchmarks on dense documents and UI screens (driven by the higher-resolution processing)

    For a fuller comparison table and the methodology notes, see the Opus 4.7 vs GPT-5.4 vs Gemini 3.1 Pro piece linked below.

    Pricing and availability

    Pricing (unchanged from Opus 4.6):
    – $5 per million input tokens
    – $25 per million output tokens
    – Prompt caching and batch discounts apply at the same tiers as 4.6

    Context window: 1M tokens (same as 4.6).

    Availability on day one:
    – Claude.ai (Pro, Max, Team, Enterprise) — Opus 4.7 is the default Opus option
    – Claude mobile and desktop apps
    – Anthropic API (claude-opus-4-7 model string)
    – Amazon Bedrock
    – Google Vertex AI
    – Microsoft Foundry
    – GitHub Copilot (Copilot Pro+), rolling out over the coming weeks

    Opus 4.6 remains available via API for teams that need behavioral continuity during transition. Anthropic has not announced a deprecation date for 4.6.

    What’s new in Claude Code

    Two Claude Code changes shipped alongside 4.7:

    Auto mode extended to Max subscribers. Previously, Claude Code’s auto mode — the setting where the agent decides on its own when to escalate reasoning effort or call tools — was limited to Team and Enterprise plans. As of April 16, Max subscribers get it too. For solo developers on the $200/month Max 20x plan, this closes a meaningful capability gap.

    The /ultrareview command. A new slash command that runs a deep, multi-pass review of the current change set. Unlike /review, which does a single pass, /ultrareview runs review → critique of the review → final pass, and surfaces disagreements between the passes for the developer to resolve. The tradeoff is latency and tokens: /ultrareview is slow and not cheap. Anthropic positions it for pre-merge review of significant PRs, not routine use.

    Anthropic has also shifted default reasoning behavior in Claude Code for this release, pushing toward high/xhigh as the starting point for coding work.

    Known tradeoffs and gotchas

    Four things worth knowing before you upgrade production workloads:

    Output tokens go up at higher effort levels. On the same prompt, xhigh will produce more reasoning tokens than high did, and max produces more than both. If you have cost alerts tuned to 4.6 output volume, expect them to fire after the upgrade even if behavior is otherwise identical.

    The tokenizer change is the real cost variable. The up-to-1.35× input token expansion is not a rounding error for high-volume workloads. Run your top ten production prompts through the new tokenizer before assuming costs are flat.

    Task budgets are beta. The feature is useful today but the API surface is not frozen. Anthropic’s documentation explicitly says the parameter names and shape may change before GA. Don’t bake it into stable contracts yet.

    Breaking API parameters. Extended thinking budgets and sampling parameters from 4.6 are gone. Update your client code accordingly.

    Frequently asked questions

    Is Opus 4.7 free?
    Opus 4.7 is available on paid Claude.ai plans (Pro at $20/month, Max tiers at $100 or $200/month). API access is usage-priced at $5/$25 per million tokens.

    How do I use Opus 4.7 in Claude Code?
    If you’re already on Claude Code, update to the latest version. Opus 4.7 is the default Opus model as of April 16, 2026. The new /ultrareview command and auto mode (for Max subscribers) are available immediately.

    Is Opus 4.7 better than GPT-5.4?
    On Anthropic’s reported benchmarks, Opus 4.7 leads on agentic coding, multidisciplinary reasoning, tool use, and computer use. GPT-5.4 remains significantly cheaper per token ($2.50/$15 vs. $5/$25). Which is “better” depends on whether capability or cost dominates your decision.

    What is Claude Mythos Preview?
    Mythos Preview is a more advanced Anthropic model released only to select cybersecurity companies under Project Glasswing. Anthropic has said it is more capable than Opus 4.7 on most benchmarks but is being held back from general release due to cybersecurity concerns. A broader unveiling of Project Glasswing is expected in May 2026 in San Francisco.

    Did Anthropic nerf Opus 4.6 to push people to 4.7?
    Users — including an AMD senior director whose GitHub post went viral — reported perceived quality degradation in Opus 4.6 in the weeks before 4.7’s release. Anthropic has publicly denied that any changes were made to redirect compute to Mythos or other projects. There is no external evidence that settles the question. This is covered in the Mythos tension article.

    Does Opus 4.7 keep the 1M token context window?
    Yes. Same 1M context as Opus 4.6.

    What changed in vision?
    Image input ceiling went from 1,568 pixels (1.15 MP) on the long edge to 2,576 pixels (3.75 MP) — more than 3× the pixel budget. Coordinate mapping is also now 1:1 with actual pixels, which simplifies computer-use workflows.

    Related reading

    • The Mythos tension: Why Anthropic admitted Opus 4.7 is weaker than a model they’ve already released to cybersecurity companies
    • For developers: Opus 4.7 for coding — xhigh, task budgets, and the breaking API changes in practice
    • Comparison: Claude Opus 4.7 vs GPT-5.4 vs Gemini 3.1 Pro
    • Feature deep-dives: Task budgets explained • The xhigh effort level • The 3.75 MP vision ceiling

    Published April 16, 2026. Article written by Claude Opus 4.7. Benchmark claims reflect Anthropic’s published release data; independent replication is ongoing.

  • How Every Role on a Restoration Team Can Learn to Think Like a PM Using Claude Cowork

    How Every Role on a Restoration Team Can Learn to Think Like a PM Using Claude Cowork

    Last refreshed: May 15, 2026

    Every restoration company has the same problem: the estimator thinks one way, the technician works another way, the PM juggles both, and the office admin is the only person who sees the whole picture.

    Claude Cowork — Anthropic’s agentic desktop AI — might be the most unlikely training tool the restoration industry has ever stumbled into. Not because it does restoration work, but because it shows every person on your team exactly how a well-run job should be decomposed, delegated, and managed.

    The short answer: Claude Cowork visibly breaks complex tasks into sub-tasks and delegates them to specialized sub-agents in real time. That process — plan, decompose, delegate, track, adjust — is the exact workflow a restoration project manager needs to master. Watching Cowork do it live is like watching a senior PM narrate their thought process.

    Why Restoration Teams Struggle With Task Decomposition

    A water damage job is not one job. It is an inspection, a moisture reading, a scope of work, an insurance estimate, a mitigation plan, a materials order, a labor schedule, a documentation trail, a customer communication cadence, and a final walkthrough — all running on overlapping timelines with interdependencies that change when the adjuster moves a number or the homeowner changes their mind.

    Most restoration employees learn this by doing it wrong a few times. The estimator forgets to document something the technician needs. The PM double-books a crew. The admin discovers at invoicing that the scope changed three times and nobody updated the file. The learning curve is expensive — in rework, in customer trust, and in insurance relationships.

    What if there was a way to show every person on the team what good decomposition looks like before they have to learn it through failure?

    How Cowork Maps to Every Role on a Restoration Team

    The Estimator

    Give Cowork a prompt like: “A homeowner reports water damage in their finished basement after a sump pump failure. The basement has carpet, drywall, and a home office with electronics. Build me a complete inspection and documentation plan.”

    Watch what happens. Cowork does not respond with a single block of text. It builds a plan: identify affected areas, document moisture readings at specific points, photograph damage progression, catalog affected materials, note potential secondary damage indicators, create the scope of work outline, flag items that need adjuster attention. Each task has a sequence. Each task feeds the next one.

    An estimator watching this process sees — visually, in real time — how a thorough inspection plan is structured. Not as a checklist someone hands them, but as a plan that emerges from thinking about what the downstream consumers of that inspection need.

    The Office Admin

    Admins are often the most underserved role in restoration training. They handle intake calls, schedule crews, manage documentation, track certificate of completions, follow up on invoicing, and keep the CRM updated — and most of their training is “watch Sarah do it for a week.”

    Give Cowork a task like: “A new water damage claim just came in. The homeowner called, insurance info is confirmed, and the estimator is heading out tomorrow. Build me the complete administrative workflow from intake through final invoice.”

    Cowork will decompose this into a multi-track plan: the documentation track (claim number, photos, moisture logs), the communication track (homeowner updates, adjuster correspondence, crew scheduling), the financial track (estimate submission, supplement tracking, invoice preparation), and the compliance track (certificates of completion, lien waivers if applicable). The admin watches these tracks unfold in parallel and sees how their daily tasks connect to the larger job lifecycle.

    The Project Manager

    This is where Cowork shines brightest for restoration. The PM is the lead agent on every job. They are the conductor. And most PMs in restoration were promoted from technician or estimator roles — they know the technical work but were never formally trained in project orchestration.

    Give Cowork a complex scenario: “We have three active water damage jobs, a fire damage mitigation starting Monday, and two reconstruction projects in progress. One of the water jobs just had a scope change from the adjuster. Build me a weekly coordination plan.”

    Cowork will show the PM what a senior operations manager would do: prioritize by urgency and revenue, identify resource conflicts, flag the scope change as a dependency that blocks downstream work, and sequence the week’s actions across all jobs. The PM sees how to think about multiple concurrent projects — not just react to whichever phone rings loudest.

    The Technician

    Technicians often see their work as task execution — set up equipment, monitor readings, tear out materials. What they rarely see is how their documentation feeds the estimator’s supplement, how their moisture readings affect the PM’s timeline, and how their work quality determines whether the final walkthrough results in a sign-off or a callback.

    Give Cowork a mitigation task: “Day 3 of a category 2 water loss in a two-story home. Drying equipment is in place. Build me the technician’s complete daily workflow including documentation, monitoring, communication, and decision points.”

    The technician watches Cowork build out not just the physical tasks but the information tasks — the readings that need to be recorded and where they go, the photos that need to be taken and what they prove, the communication checkpoints with the PM. It connects the dots between doing the work and documenting the work in a way that a training manual never does.

    The Sales Manager

    Restoration sales — whether it is commercial accounts, TPA relationships, or plumber referral networks — involves pipeline management that most salespeople in the industry handle with a spreadsheet and memory. Give Cowork a business development task: “We want to build relationships with property management companies that manage fifty or more residential units within thirty miles. Build me a ninety-day outreach plan.”

    Cowork breaks this into research, qualification, outreach sequences, follow-up cadences, and tracking — the same structured approach a sales operations manager would build. The sales manager sees that prospecting is not just “make calls” but a planned, multi-stage process with measurable milestones.

    The Training Unlock Nobody Expected

    Here is what makes this genuinely different from handing someone a training manual or a process document: Cowork shows the thinking, not just the result.

    A process document tells you what steps to follow. Cowork shows you why those steps exist, what depends on what, and how a change in one area cascades through the rest. It shows the conductor at work — not just the sheet music.

    For a restoration company that struggles with inconsistent job quality, scope creep, communication breakdowns between field and office, or PMs who are technically skilled but operationally reactive — Cowork is a training layer that works alongside the people, not instead of them.

    Your technician does not become a project manager by watching Cowork. But they start thinking like one. And that shift in perspective — from task executor to system thinker — is the hardest training outcome to achieve and the most valuable one a restoration company can develop.

    Frequently Asked Questions

    Can Claude Cowork actually help train restoration employees?

    Yes. Cowork visibly decomposes tasks into sub-tasks, delegates them to sub-agents, and shows progress in real time. That decomposition mirrors exactly how a restoration project manager should plan and track a job. Watching Cowork work through a restoration scenario teaches the planning skill, not just the technical steps.

    Which restoration roles benefit most from watching Cowork?

    Project managers benefit most because Cowork’s lead-agent pattern directly mirrors the PM role. But estimators learn thorough documentation planning, admins see how their workflows connect to the full job lifecycle, technicians understand how their documentation feeds downstream processes, and sales managers see structured pipeline management.

    Does Cowork replace restoration project management software?

    No. Cowork is not a project management tool and does not replace platforms like DASH, Xactimate, or your PSA. It is a thinking tool that shows people how to plan and decompose work. Use it to train the thinking, then apply that thinking inside your existing systems.

    How would a restoration company actually use Cowork for training?

    Run a real restoration scenario through Cowork during a team meeting. Let the team watch it decompose the job, then discuss what it got right, what it missed, and how each person’s role connects to the plan. The plan Cowork generates becomes a discussion artifact — a living training aid rather than a static document.

    Is Claude Cowork available for restoration businesses?

    Claude Cowork is available through the Claude desktop app on Pro, Max, Team, and Enterprise plans. Any restoration company with a subscription can start using it immediately. It runs on Mac and Windows.

    ]+>’,’ ‘,sys.stdin.read()); print(len(text.split()))”


  • How Claude Cowork Can Actually Train Your Staff to Think Better

    How Claude Cowork Can Actually Train Your Staff to Think Better

    Last refreshed: May 15, 2026

    What if the most powerful staff training tool you’ll touch this year is hiding inside an AI app you already pay for?

    There is a quiet productivity feature inside Claude Cowork that almost nobody is talking about. It is accidentally one of the best project management training tools I have ever seen — and once you notice it, you cannot unsee it.

    The short answer: Claude Cowork shows you its plan and progress in real time as it decomposes a task into sub-tasks and delegates them to a team of sub-agents. That visible decomposition — the same skill a great project manager uses every day — turns Cowork into a live training tool for any staff member learning to break down ambiguous work into executable pieces.

    The Difference Between Chat and Cowork

    When you work with Claude in chat, you hand it a prompt and you get an answer. It is fast, it is useful, and most of the work happens invisibly — somewhere between your question and the response. You do not see the thinking. You do not see the breakdown. You just see the output.

    Cowork is different. When you give Cowork a task, you watch it work. Anthropic’s own documentation confirms this: Cowork shows progress indicators at each step, surfaces its reasoning, and lets you steer mid-task to course-correct or add direction. For complex work, it coordinates multiple sub-agents running in parallel.

    That transparency is the feature. And it is the feature that makes it a training tool.

    The Conductor and the Section Players

    Here is what is actually happening under the hood — and this is the part I had to confirm because I had been assuming it.

    Cowork uses the same agentic architecture as Claude Code. A lead agent (the orchestrator) takes the overall task, decomposes it into subtasks, and delegates those subtasks to specialized sub-agents. The lead maintains oversight, handles dependencies, sequences work when one piece depends on another, and synthesizes the final result. Sub-agents work independently in their own context windows and can flag dependencies back to the lead.

    It is a conductor with a section of players. The conductor does not play the violin. The conductor decides when the violins come in, how loud, and for how long.

    This is exactly how a competent project manager operates.

    Why This Matters for Training Your Staff

    Most people — including most project managers I have worked with — struggle with one specific skill: taking a messy, ambiguous goal and breaking it into a sequence of manageable, dependency-aware tasks. It is the difference between “we need to launch the new site” and a project plan with seventeen sequenced items, three parallel workstreams, and clear handoff points.

    Cowork does this decomposition in front of you, in plain English, every time you give it a task. You can literally watch a lead agent think through: what does this goal actually require, what order do the pieces need to go in, what can happen in parallel, what is the dependency chain, and how do I know when we are done?

    For a PM in training, that is a live demonstration of planning. For a staff member who has never had to structure work before, it is a mental model they can borrow.

    The “Oh Yeah, I Forgot About This” Superpower

    The part I love most: you can interrupt Cowork while it is running. You can ask a question. You can add a requirement. You can redirect a visual task. And because there is a lead agent holding the plan, it does not panic — it queues your input and addresses it when appropriate.

    That is exactly how you should be working with human teams. You should not be afraid to say “oh wait, I forgot we also need X” to a project manager. A good PM takes the new input, figures out where it fits in the plan, and slots it in without derailing everything else.

    Watching Cowork do this gracefully is a training moment. It shows people that mid-flight course corrections are normal, that good planning systems absorb new information rather than break from it, and that the conductor’s job is to keep the music going even when the score changes.

    How to Actually Use Cowork to Train a Team

    A few things I would try with a team:

    Run a Cowork narration session. Have a new project manager watch Cowork tackle a real task end-to-end and narrate what it is doing and why. Then ask them to plan a real project the same way — out loud, decomposed, with dependencies called out.

    Use Cowork as a planning artifact generator. When someone on your staff hands you a vague goal, run it through Cowork first. Not because Cowork will do the work, but because the plan Cowork produces is a teaching artifact. You can review it together: here is how the task should be broken down, here is the order, here is what runs in parallel.

    Teach delegation by example. When you are training someone to delegate, have them watch how the lead agent assigns work to sub-agents. Narrow scope, clear instructions, defined handoff. That is delegation 101, executed live.

    The Bigger Point

    Tools that hide their thinking make you dependent on them. Tools that show their thinking make you better.

    Chat hides the thinking. Cowork shows the thinking. And the thinking it shows happens to be the exact cognitive skill — structured task decomposition — that separates people who manage projects well from people who drown in them.

    If you are running an agency, a team, or any operation that depends on people learning to break down ambiguous work into executable pieces, Cowork is not just a productivity tool. It is a classroom.

    Frequently Asked Questions

    What is Claude Cowork?

    Claude Cowork is Anthropic’s agentic desktop application that takes on multi-step knowledge work tasks autonomously. Unlike chat, where you exchange single messages, Cowork accepts a goal, builds a plan, and executes it across files and applications on your computer using the same agentic architecture as Claude Code.

    How is Cowork different from Claude chat?

    Chat responds to one prompt at a time and hides its reasoning between your message and its reply. Cowork takes on full tasks, shows you its plan and progress in real time, and lets you steer mid-task. It also coordinates multiple sub-agents in parallel for complex work.

    Does Claude Cowork actually use multiple agents?

    Yes. For complex tasks, Cowork uses a lead/orchestrator agent that decomposes the work and delegates sub-tasks to specialized sub-agents that run in parallel. The lead handles dependency ordering and synthesizes results when work is complete. This is the same supervisor pattern used in Claude Code’s agent teams feature.

    Can I interrupt Cowork while it is running?

    Yes. You can jump in mid-task to ask questions, add requirements, redirect work, or course-correct. The lead agent queues your input and addresses it at the appropriate point in the plan rather than abandoning what is already in motion.

    How can a manager use Cowork to train staff?

    Use Cowork as a live demonstration of structured task decomposition. Have new project managers narrate what Cowork is doing and why, then plan their own projects the same way. Use the plans Cowork generates as teaching artifacts to discuss task breakdown, dependency mapping, and parallel workstreams. Watch the lead agent’s delegation patterns — narrow scope, clear instructions, defined handoffs — as a model for how humans should delegate.

    Who is Claude Cowork designed for?

    Cowork was built for non-technical knowledge workers — researchers, analysts, operations teams, legal and finance professionals — who work with documents, data, and files daily and want to spend more time on judgment calls and less time on assembly. It is available on Pro, Max, Team, and Enterprise plans through the Claude desktop app.

    Does Cowork work alongside Claude in chat?

    Yes. Chat remains useful for quick questions, single-step tasks, and conversational work. Cowork takes over when the work requires planning, multi-step execution, or coordination across files and applications. The same Claude account uses both modes.


  • Relational Debt: The Hidden Ledger of Async Work

    Relational Debt: The Hidden Ledger of Async Work

    I have one developer. His name is Pinto. He lives in India. I live in Tacoma. The timezone gap between us is roughly twelve and a half hours, which means when he sends me a message at the end of his workday, I see it at the start of mine, and by the time I respond he is asleep. This is the entire physical substrate of our working relationship. Async text, offset by half a planet.

    Every message I send him either closes a loop or widens a gap. There is no third option. I want to talk about that, because I think it is the most underexamined layer of remote solo-operator work, and because I only noticed it existed because Claude caught me almost doing it wrong.

    The moment I noticed

    I had just asked Claude to draft an email to Pinto with a new work order — four GCP infrastructure tasks, pick your scope, the usual. Claude pulled Pinto’s address from my Gmail, drafted the email, and included a line I had not asked for. It was one sentence near the end: “Also — good work on the GCP persistent auth fix. Saw your email earlier. That unblocks a lot.”

    I had not told Claude to thank him. I had not told Claude that Pinto had sent a completion email earlier that day. I had not even read Pinto’s email yet — it was sitting in my unread folder. But Claude had searched my inbox to find Pinto’s address, found both my previous P1 request and Pinto’s reply closing it out, and quietly noticed that I had an open loop. Then it closed it inside the next outbound message.

    When I read the draft, I felt something click. Not because the line was clever. Because if I had sent that email without the acknowledgment, I would have handed Pinto a fresh task on top of work he had just finished, without a single word confirming that the work was seen. He would have processed the new task. He would not have said anything about the missing thank-you. And a tiny, invisible debit would have gone on a ledger that neither of us keeps, but both of us feel.

    What relational debt actually is

    Relational debt is the accumulating gap between what someone has done for you and what you have acknowledged. In synchronous work — an office, a standup, a shared lunch — you pay this debt constantly and automatically. Someone ships a thing, you see them, you say “nice work,” the debit clears. The payment is so small and so continuous that nobody notices it happening.

    Take that synchronous channel away. Put twelve time zones between the two people. The only payment mechanism left is the next outbound text message. And the next outbound text message is almost always a new request, because that is the substrate of work — one person asks, the other builds, they send it back, the first person asks for the next thing.

    So the math of async solo-operator work is this: every outbound message is the only available payment instrument, and the instrument has two slots. You can use it to close the last loop, or you can use it to open a new one. If you only ever use it to open new ones, the debt compounds. If you always split them into two messages — one “thank you” and one “here is the next task” — the thank-you arrives orphaned, and the recipient has to context-switch twice. The elegant move is to put both into one message. Two birds, one outbound. The debit clears on the same envelope as the new debit arrives.

    The ledger nobody keeps

    I have a Notion workspace with six core databases. I have BigQuery tables tracking every article I publish and every post across 27 client sites. I have Cloud Run services running nightly crons against my content pipeline. I have a Claude instance that can read all of it and synthesize across any of it in under a minute. And none of it tracks the state of open conversational loops between me and the people I work with.

    Think about that. I am running an AI-native B2B operation in 2026 with more data infrastructure than most mid-market companies had five years ago, and I cannot answer the question “what is currently unclosed between me and Pinto” with anything other than my own memory. My own memory, which is the thing that almost forgot to thank him for the GCP auth fix.

    That is a real gap in my stack. I am not sure yet whether I should fill it. Part of me wants to build a “relational ledger” — a new table in BigQuery that tracks every outbound message I send, every reply I receive, every acknowledgment I owe, and surfaces the open loops each morning. Part of me suspects that building such a thing would be the exact kind of architecture-addiction trap I have been trying to avoid. The better answer is probably: let Claude read Gmail at the start of every session and surface open loops conversationally. No new database. No new UI. Just a question at the top of each working block: “Anything you owe anyone before you start the next thing?”

    Why this matters more than it sounds like it does

    People underestimate relational debt because it looks like politeness. It is not politeness. Politeness is a style choice. Relational debt is a structural property of the communication medium. In sync work the medium pays the debt for you. In async work nothing does, and you have to bake the payment into the one instrument you have left.

    I have watched relationships between founders and remote contractors deteriorate over months in ways that neither side could articulate. I have felt that deterioration myself, on both sides. Nobody ever says “I am leaving because you stopped acknowledging my completed work.” What they say is “I feel undervalued” or “I do not think this is working out” or — more often — nothing, they just slowly stop caring, and the quality of the work drifts until the relationship ends without a clear cause.

    The cause is the ledger. The debt compounded. Nobody was tracking it and nobody was paying it down.

    The piggyback pattern

    Here is the tactic I am going to make a rule. When I owe someone acknowledgment and I need to send them a new task, I never split it into two messages. I bake the acknowledgment into the first two lines of the task email. The debt clears, the task delivers, the person feels seen, and I have used my one payment instrument for both purposes.

    Claude did this to me on the Pinto email without being asked. It had access to the context — Pinto’s completion email was in the same Gmail search that pulled his address — and it closed the loop inside the next outbound message. That is the correct default behavior for any async-first collaboration, and I had not formalized it as a rule until the moment I saw it happen.

    When this goes wrong

    The failure mode of this pattern is performative gratitude. If every outbound message starts with a thank-you, the thank-you stops meaning anything. Pinto would learn to skim past the first two lines because he knows they are ritual. The acknowledgment has to be specific, based on actual work, and only present when there is actual debt to close. “Thanks for the GCP auth fix, that unblocks a lot” is specific, grounded, and load-bearing. “Hope you are well, thanks for everything” is noise and it corrodes the signal.

    The second failure mode is weaponization. You can use acknowledgment as a sweetener to slip in hard asks. “Great work on X, also can you please rebuild Y from scratch this weekend.” That pattern gets detected fast by anyone who has worked in a corporate environment and it burns trust faster than ignoring them entirely.

    The third failure mode is forgetting that the ledger runs in both directions. Pinto also owes me acknowledgment sometimes. If I am tracking my debts to him without also noticing when he pays his, I drift toward resentment. The ledger has two columns.

    The principle

    In async-first solo operations, every outbound message is a payment instrument for relational debt. Use it to close loops on the same envelope you use to open new ones. Make the acknowledgment specific. Do not split the payment from the request unless the payment itself needs a full message of its own. And let your AI notice when you are about to miss one, because your AI can read your inbox faster than you can remember what you owe.

    This is one of five knowledge nodes I am publishing on how solo AI-native work actually operates underneath the tooling. The tools are the easy part. The ledger is the hard part, and almost nobody is paying attention to it.

    The Five-Node Series

    This piece is part of a five-article knowledge node series on async AI-native solo operations. The full set: