Anthropic is making Claude Code’s auto mode the default for its paid and enterprise users, allowing the coding agent to execute more actions without requiring developers to approve each one.

“Starting August 14, 2026, auto mode becomes the default permission mode for new sessions on Pro, Max, and Team plans,” the company wrote in the coding agent’s documentation, adding that the same change is planned for Claude Enterprise, API, and cloud platform users within the next month.

That essentially means developers using those plans will no longer have to manually approve every tool call or action Claude Code wants to make while executing a task.

Instead, each tool call is evaluated by an automated classifier designed to determine whether the action is safe to execute. Actions considered irreversible, destructive, or outside the agent’s environment can still be blocked, with Claude Code either attempting a safer approach or asking the developer for approval, the company wrote in a blog post.

“If it can’t make progress — three blocks in a row, or twenty across a session — Claude Code falls back to manual approvals,” it explained.

This reduction in manual intervention, Anthropic further added, is intended to make the coding agent more suitable for long-running tasks as well as cut down on “permission fatigue” that it says has been threatening to reduce its security posture.

According to its internal data, Claude Code users typically approve 97% of permission prompts, while only 3% are rejected. It also found that 49.5% of active CLI users had created a Bash allow-rule by June, while 62% had used “bypassPermissions” or selected “don’t ask again” for Bash.

In contrast, the default auto mode, in an Anthropic-controlled study involving 1,053 paid professional testers, caught 89% of deliberate dangerous commands compared to just 13.6% being detected by human reviewers.

More productivity but with tradeoffs

Analysts too see auto mode as a step toward making coding agents more autonomous, but with tradeoffs.

“Developers should see fewer permission pop-ups and spend less time watching Claude, meaning they can give it larger tasks and let it edit files, run tests, and execute routine commands with fewer interruptions. That way, developers can finish and ship more work using this mode because they aren’t constantly interrupted by approval windows,” said Pareekh Jain, principal analyst at Pareekh Consulting.

However, that same classifier in auto mode that reduces permission pop-ups could also result in more latency for routine or quick tasks, as trusted workflows also pass through it, adding an extra execution step, noted Manoj Chandra Jha, principal analyst at Nord-IQ Research.

Another tradeoff of reducing real-time approvals, according to Amit Kumar Jena, AI development manager at IT consulting firm Kanerika, is that it could make it harder for enterprises to maintain effective human oversight as agents take on longer-running tasks. “Reviewing four hours of unattended agent output is a harder skill, and most teams haven’t built it,” Jena said.

Better governance for CIOs

For CIOs, though, auto mode can strengthen governance in software development.

Rather than policing individual developer actions, CIOs can define permission boundaries centrally and have the classifier enforce them across agent sessions, said Jha.

That makes the current opt-in period for Enterprise and API users particularly important, as CIOs can establish permission policies before auto mode becomes the default, Jha added.

At the same time, however, CIOs also need to understand the limits of those policies, Jena pointed out.

“Auto mode has three levels of restrictions, with hard-deny rules blocking actions unconditionally, while soft-deny rules can be overridden by a developer’s allow rule. As a result, CIOs should use hard-deny or managed-settings rules for actions that must never be permitted,” he said.

Auto mode changes the security risk profile

Those centralized policy controls, which Anthropic claims should make Claude Code more secure, according to analysts, change the security risk profile of the coding agent rather than eliminate risk.

While the classifier and the policy controls reduce the risk of human failures or everyday risks, it also creates a single point of failure, Jain said.

That means if that single point has a blind spot or an attack manages to bypass it, the agent could still execute harmful actions without human approval or recognition, Jha echoed.

That said, Anthropic is not removing developers’ ability to control how Claude Code operates.

Users who have already set a different default may receive a one-time prompt asking whether they want to move to auto mode, while those who have pinned their existing preference will see no change. The company is also making the transition easier by absorbing the small amount of additional token usage generated by the classifier for Pro, Max, and Team users, with the change effective immediately.

Be careful what you wish for. That’s what Microsoft found out recently when it discovered that AI — rather than making Windows more secure by helping the company close security holes — could help hackers find flaws faster than Microsoft can fix them.

It’s put Microsoft in a serious bind. Should the company devote a potentially massive amount of resources to fix every AI-unearthed security issue as fast as it can? Or should it rush to close the most important ones, and clean up the minor ones later at much less cost?

What the company decides could have tremendous implications. For years, Microsoft has faced criticism from many in the US government because of how often its technologies have been hacked, potentially putting the nation’s security at risk. Some members of Congress have suggested the government curtail contracts with Microsoft until the company proves it can provide more safety. Billions of dollars in federal contracts could be pulled.

To get a better insight into what could happen, let’s look at AI’s newfound prodigious ability to find security holes and bugs.

AI-fueled security mavens Mythos and Project Glasswing

Microsoft’s AI-related security problems are an outgrowth of the launch of Anthropic’s Mythos AI model, designed to handle cybersecurity and biology research. One of its goals is to uncover security vulnerabilities as quickly as possible, so that software companies and cybersecurity companies can fix them before hackers find the holes.

Anthropic’s early tests found that Mythos was spectacularly successful in finding Windows security flaws. “Within 31 minutes, Mythos generated its first proof-of-concept exploit for a Windows kernel vulnerability,” Axios reported in June.

Anthropic noted that its testing of Mythos “reveals a stark fact: AI models have reached a level of coding capability where they can surpass all but the most skilled humans at finding and exploiting software vulnerabilities.

“Mythos Preview has already found thousands of high-severity vulnerabilities, including some in every major operating system and web browser. Given the rate of AI progress, it will not be long before such capabilities proliferate, potentially beyond actors who are committed to deploying them safely. The fallout — for economies, public safety, and national security — could be severe.”

As a result, Anthropic decided to launch a security project it calls Project Glasswing, which it describes as “an urgent attempt to put these capabilities to work for defensive purposes.”

Many companies beyond Anthropic are part of the effort, including Microsoft, Google, Amazon, Nvidia, Apple and others. In theory, it’s a great idea. Find and fix vulnerabilities before hackers can, and everyone is safer. What could go wrong? 

Plenty, as it turns out. Access to Mythos is available to anyone, and Mythos has been finding security holes and bugs far faster than companies — particularly Microsoft — can patch them. As Pro Publica reported in late July, ‘Microsoft is struggling to fix them fast enough.” 

Too little, too late?

For now, Microsoft is only patching the most dangerous bugs and holes. And, according to Pro Public, “internal records indicate that Microsoft plans to eventually address ‘moderate’-severity flaws uncovered by Mythos. The documents made no mention of ‘low’-severity bugs.”

That’s fairly typical of the triage many companies use when deciding how much effort to put into plugging holes. But some experts believe that in the Age of AI, that’s a dangerous way to handle security. 

Vinh Nguyen, former chief AI officer and chief data scientist at the US National Security Agency and now a senior technical adviser to Anthropic and senior fellow for AI at the Council on Foreign Relations, is particularly concerned that the approach is outdated. He told Pro Publica: “The problem now is that you can chain four low-level flaws, and that can equal a high severity. If you’re Microsoft, the current triage strategy may be underpricing risks.” 

It’s already proving difficult for Microsoft to keep up with patching bugs and security holes since Mythos’ launch. July’s Patch Tuesday release fixed the most bugs in Microsoft’s history – 622 of them. Things will only get harder from here. 

The dangers for Microsoft

Microsoft is already in the doghouse for how it’s handled security. A year ago, in one of the worst attacks on Microsoft technologies, Sharepoint was hacked. Tens of thousands of servers were hit, including not just thousands of businesses, but many important government agencies as well.    

The National Institutes of Health (NIH) and the National Nuclear Security Administration (NNSA), which is in charge of the nation’s nuclear security, were among the victims. So were the Department of Homeland Security (DHS), the Cybersecurity and Infrastructure Security Agency, the Transportation Security Administration, Customs and Border Protection, and the Federal Emergency Management Agency, among many others. 

Even before then, some members in Congress were threatening to pull Microsoft contracts if it didn’t improve security. At one point Sens. Eric Schmitt (R-MO) and Ron Wyden (D-OR) sent a threatening letter to the Pentagon requesting it not increase its use of Microsoft products.

“We write with serious concern that the Department of Defense (DoD) is doubling down on a failed strategy of increasing its dependence on Microsoft at a time when Congress and the administration are reviewing concerning cybersecurity lapses that led to a massive hack of senior US officials’ communications,” the letter said, in part.

Nothing happened as a result of the hack or the letter. But that could change in a heartbeat if there’s another big attach. It seems inevitable that hackers will start taking advantage of how quickly Mythos discovers security holes and bugs, especially if Microsoft doesn’t fix them all. 

The next big hack, powered by AI, could prove very dangerous — not just for businesses and governments, but for Microsoft as well.

My current model-selection strategy is embarrassingly simple… and wrong: I choose the most capable (expensive) model because I’m worried the cheaper one might get something wrong. That makes me spend too much, of course, which is why I (like you, perhaps?) continue to struggle with one of the most fundamental challenges in AI: How can I know when a cheaper model is sufficient for a task? Or, really, which model should I use at all?

I asked a friend, Leo Zheng, who leads marketing for Fireworks AI, an AI infrastructure company that runs and improves open-weight models. Surely it was his job to know? His answer surprised me. I thought the answer would come down to models, but it doesn’t. Fireworks, he said, wants to “enable every company to own the continual learning loop within their four walls.” The idea is to abstract away model updates while companies feed the system new signals as customer behavior changes.

That’s when it clicked. I was asking how to automate model choice, but the harder problem is building a feedback loop that tells a company what worked. Model choice then becomes simply one important action the system can take, not the be-all and end-all decision a developer must get right in advance. Arguably, the more important component is integrating enterprise data into that continual learning loop that Zheng describes.

I’ve made that argument before, and I was right. Sort of. Proprietary data doesn’t automatically guarantee AI success. Neither does dumping that data into a retrieval-augmented generation (RAG) system. Your competitors can do the same. The more durable advantage comes from outcome data: traces that connect what the system saw, what it did, and whether the business result was acceptable. Those traces become valuable when a company uses them to improve the system and carry the learning to the next model.

Make the data earn its keep

Public benchmarks are useful, but they only tell you how a model performed on someone else’s test. They can’t tell a bank whether a fraud alert was correct, inform a retailer whether an AI agent resolved a return, or tell a software company whether AI-generated code survived review. Enterprises already have pieces of those answers buried in support transcripts, accepted patches, abandoned carts, etc. The trick is turning that mess into something a system can learn from.

Think about a software company. It already collects product analytics to improve its product. AI can extend that flywheel. Application signals can improve the system powering the product. How? By capturing user intent, engagement, and preferences.

This isn’t foolproof, however. A fast learning loop built on a weak proxy is simply a fast way to make the system worse. For example, suppose Toni in customer support accepts a suggested response. Was it good? Maybe. But what if Toni was rushing (as she is prone to do) and the customer reopened the ticket the next day? It’s not enough to act on inputs alone; a company needs to connect the suggestion to the eventual outcome or risk rewarding the wrong behavior.

Acceptable or ideal outcomes must be defined by the enterprise. A platform like Fireworks can optimize through learning loops, but only if desired outcomes are defined. This changes the cost calculation. After all, the cheapest model by token can be the most expensive model by outcome if people must review, retry, and repair its work. A company can be hemorrhaging money on AI failures while congratulating itself for lowering inference costs.

Open weights get useful

None of this requires open weights, of course. A company can own its evaluations, improve prompts and retrieval, and route among closed APIs and open models without changing a single parameter. For many workloads, that will be enough.

This generally won’t start with reinforcement learning, either. It starts by picking one workflow with an observable outcome and logging the request, model, cost, answer, and what happened next. Do that for a quarter and patterns should emerge. A cheaper model will be good enough for some work, while a proprietary frontier model will earn its price elsewhere. However, in a third category, every model may fail in the same repeatable way, and it’s this last category that makes the serious case for changing the weights.

A few years ago, I argued that open source succeeds when it makes developers’ lives easier, not when it wins an ideological purity contest. The same applies to open weights. The importance of open weights isn’t that they’re a cheaper facsimile of whatever OpenAI and Anthropic are shipping. Instead, they matter because they shift leverage away from the models and toward users with proprietary outcome data. They let enterprises turn what they learn into something they can shape, keep, and carry forward as models change.

Open weights turn model renters into model owners. That’s a very big deal.

For Cursor’s Composer 2, the company started with the open-weight Kimi K2.5 model, then specialized it through continued pretraining and reinforcement learning in environments built to resemble Cursor itself. The interesting thing isn’t that Cursor picked the “right” model, but rather that Cursor can use what it learns from developers to keep making that model more “right” for them. In this case, Fireworks ran the reinforcement learning inference, while Cursor supplied what only Cursor could: its product environment and definition of good. Cursor subsequently built Composer 2.5 on the same Kimi K2.5 checkpoint and says 85% of its compute went into additional training and reinforcement learning.

The base model was the starting point, not the finished product.

This is why open weights matter. They turn the model from a finished product into raw material. The foundation labs have broad knowledge, far more than any normal company could hope to collect. What they don’t know is whether your patch shipped, your fraud was stopped, your customer stayed, or Toni’s response made matters worse. You do.

RAG lets a model consult your data. A learning loop lets the system learn from it. One helps answer today’s question, but the other helps the company answer tomorrow’s question better.

Control must be convenient

Raw weights alone won’t deliver that control. Open source didn’t take over the enterprise because CIOs wanted tarballs. It won because Red Hat, and especially cloud providers, turned theoretical control into everyday convenience. Open-weight AI needs the same translation.

Enterprises want the convenience of a closed API without surrendering control over the intelligence their data creates. That’s the real Fireworks opportunity. Not faster tokens, but a shorter distance between learning something about your customers and making the product smarter because of it. Fireworks CEO Lin Qiao calls this “application-specific intelligence,” and that’s exactly right. Enterprises don’t need to outbuild OpenAI or Anthropic. Even if they wanted to, they couldn’t. Instead, they need to turn what they know about their customers and workflows into intelligence those labs can’t supply.

Fireworks isn’t alone. Together AI also spans training, evaluation, and serving, while Baseten now talks about connecting production feedback to model training. This is becoming a category, not simply a Fireworks feature. Fireworks’ particular bet is that the entire learning loop should belong to the customer.

So, back to the question I was asking Zheng: How do I pick the right model in advance? By now it’s clear: I can’t. Neither can you, and that’s fine, because it’s not really the right question.

Once the enterprise owns the test, it no longer has to trust a vendor’s benchmark or brand. New models must prove themselves against the work that matters to that company, then be promoted, specialized, or discarded accordingly. Model choice becomes a consequence of learning, not an act of faith. In effect, the models audition for the enterprise, not the other way around.

No one can predict whether OpenAI, Anthropic, Google, or the open-weight community will lead six months from now. The sensible response is to stop making that prediction central to the strategy. The enterprise’s own data should decide which model to pick. That’s the bet I find compelling in Fireworks: Make open-weight models as easy to improve as APIs are to call, so enterprises can stop treating their data as context for somebody else’s model and start using it to build intelligence they control.

Back in 2023 and into 2024, as the hyperscalers announced massive data center expansions and plans for gigawatt-scale facilities, I was in boardrooms explaining why these timelines were unrealistic. The response was often a polite dismissal. The vendors were confident. The press was enthusiastic. And I was, well, the guy asking uncomfortable questions about power grids and infrastructure realities.

Now, in 2026, articles are confirming exactly what I and others who understand infrastructure have been saying all along. These massive data center projects are being delayed or canceled. Power shortages are creating bottlenecks across the industry. The grid simply cannot support the ambitions announced with such fanfare just a few years ago.

It wasn’t a mysterious formula to crack. It was simple math. And the math said the timeline was impossible.

Enterprises left holding the bag

If your AI road map relies on the abundant cloud capacity vendors promised, you’re likely facing tough conversations right now, and your AI growth plans are feeling pain. The promised compute doesn’t exist as advertised, and you’re scrambling to decide next steps. Looking inward is the only option at this point.

The vendors had every incentive to sell their vision with confidence and enthusiasm. When you’re a hyperscaler announcing a 10-billion-dollar data center campus, you’re in the business of capturing mindshare and customer commitment. While this strategy boosts sales, it fosters dangerous assumptions from customers. The enterprises that are struggling right now relied on vendor promises without doing their own analysis. They trusted the vendors to be right or, at least, close enough. They built their plans around the promises. When reality doesn’t match up, they are left holding the bag.

I speak frankly with my clients, and I’ll say it plainly here. You must do your own analysis. Vendors aren’t malicious, but their incentives don’t perfectly align with yours. They want your business, which means painting rosy pictures of capacity and timelines. You need someone to look out for your interests, and that person must be internal or a trusted advisor without a stake in selling you cloud services.

Two years ago, I was warning clients that the promised AI capacity was a fantasy for most organizations within the stated time frames. My advice was to plan for constraints, to build flexibility into infrastructure strategy, and to assume that the needed compute would be harder to get than the vendors suggested. Many clients nodded politely and went back to assuming the vendors would deliver. Some suggested I was too pessimistic.

The enterprises that took my advice seriously are in a much better position today. They planned for constraints. They chose hybrid strategies. They didn’t bet everything on hyperscaler promises that were never realistic. They’re not happy with the situation, but they’re not panicking either. For enterprises still scrambling, the first step is to admit that the old plan is dead. You cannot execute an infrastructure strategy built on vendor promises that never materialized. You need a new plan that accounts for real power constraints, real timeline challenges, and real competition for limited compute resources.

The grid isn’t expanding fast enough. Nearly half of all new US data center builds are being delayed or canceled. Yet AI demand continues to grow. These realities don’t care about your road map or your executive commitments.

Three realities to plan for

So, how should enterprises plan for future infrastructure growth? Let me offer three realities that need to be part of your planning process going forward.

1. First, assume constraints. Every infrastructure plan should assume you won’t get the power, space, or compute you want within the time frame you need. Build your strategies around limitations, not abundance. This isn’t pessimism; it’s realism. If the limitations hit, you’re ahead of the game. If they don’t materialize, you’ve simply over-engineered your solution and you can scale back.
2. Second, build for flexibility. The days of locking into single-vendor strategies based on promised capacity are over. You need infrastructure strategies that can adapt as reality unfolds. That means maintaining options, keeping relationships with multiple providers, and building architectures that can shift workloads as conditions change. The enterprises that will succeed aren’t the ones who picked the right hyperscaler. They’re the ones who didn’t put all their eggs in one basket.
3. Third, do the math yourself. When a vendor shares future capacity plans, analyze whether they’re realistic. Review power infrastructure constraints. Review construction timelines. Review historical patterns of delivery versus promises. Make vendors substantiate their commitments in writing with enforceable accountability clauses. Protect your organization from optimistic sales projections that don’t align with operational realities.

Hype never stops

The AI capacity crisis we’re living through was predictable. Those who predicted it were largely ignored because the message wasn’t what people wanted to hear. But that’s always the way infrastructure reality works. The grid can only expand so fast. Power capacity has real limits. Massive new demands create real bottlenecks.

The vendors will keep selling the vision. The press will keep covering the announcements. And the hype will continue to outpace reality. Your job is to be skeptical. Your job is to build infrastructure strategies that work in the world that actually exists, not the world that vendors are selling.

My warnings two years ago about the data center capacity crisis were right. I expect to continue being right. The question is whether enterprises will finally start listening before the next wave of unrealistic vendor and media promises leads to the next round of painful corrections.

As always, the choice is yours.