Claude's Thinking Lever: Who Controls AI Effort?

There's a moment in Alexander Bricken's Anthropic Developer Conference session where he gestures toward a future that should give any policy-minded observer pause. "Over time," he says, "we might see Claude eventually go from seconds, minutes or hours of work to even days, weeks or months of work." He delivers this as an engineering horizon, not a warning. The room receives it that way. I find myself thinking about liability frameworks.

Bricken, who leads applied AI research at Anthropic, was presenting what he calls the "thinking lever"—a set of controls that let developers tune how much cognitive effort Claude puts into any given task. The technical substance is worth understanding on its own terms before we get to the harder questions it raises.

The Architecture of Effort

The underlying mechanism is test time compute: the idea that a model's performance improves not just by making it larger at training time, but by giving it more tokens to reason through at inference time. This has been the defining insight behind reasoning models over the past couple of years, and Bricken's presentation shows it playing out across benchmarks from DARPA's QA reasoning suite to Humanity's Last Exam—a rigorous evaluation developed by Scale AI and the Center for AI Safety that tests expert-level knowledge across domains—to Anthropic's own internal agentic coding benchmarks. More tokens spent thinking, better outcomes. The relationship holds across knowledge domains.

What Anthropic has built on top of that foundation is a tiered effort system—low, medium, high, extra high, max—that lets developers explicitly set how hard Claude works on a problem. Bricken demonstrated this live with a single prompt: build a traffic simulation. At low effort, Claude produced something functional in about 50 seconds. At high effort, double the time, double the tokens, materially better simulation—different vehicle types, more realistic traffic light placement, vehicles that respond to each other's movement. At max effort, roughly 10x the tokens, the simulation was noticeably more sophisticated. The point wasn't that max is always right. Bricken was explicit that diminishing marginal returns kick in, and that max effort "can typically deliver gains on the hardest tasks" but isn't where you should start unless you already know you need it.

The more architecturally interesting piece is adaptive thinking, which Bricken frames as an evolution beyond simply toggling extended thinking on or off. The toggle model was, in his telling, a category error: "You're not expressing how hard you want Claude to think when you turn a thinking toggle on or off. You're actually just turning off a core capability." Adaptive thinking instead gives Claude discretion over when to invoke its reasoning capacity—between tool calls, before responding, or not at all if the task doesn't warrant it. The tennis analogy Bricken uses is genuinely clarifying: you don't think step-by-step through a volley, but you do think through a problem set. Translating that cognitive variability into model behavior is a real design challenge, and the solution here—treating thinking as a tool Claude can choose to invoke, rather than a mode to switch between—is more elegant than it might sound.

The Pokémon Problem (And Why It's More Complicated Than It Looks)

The example Bricken clearly enjoyed most was Claude playing Pokémon Red at low effort. Constrained from extended reasoning, Claude developed what he describes as a resource-conservation strategy: using repels to avoid wild Pokémon encounters, escape ropes to exit caves quickly, running from battles it couldn't afford. "When you put it on low effort, Claude actually came up with this unique solution to navigate the game and almost complete it faster than it otherwise would."

I want to be careful here, because this example is doing a lot of work in Bricken's narrative—it's his evidence that low-effort settings can produce "unique attractor states," genuinely novel solutions that higher-effort reasoning might overthink past. That's an interesting hypothesis. But a game environment with fixed rules and clear objectives is close to the most favorable possible test case for this claim. Whether constrained reasoning produces creative shortcuts in, say, a legal research task or a financial analysis is a genuinely open empirical question. The Pokémon result is striking, and it's honest about what it is—an eval, not a generalization. But the framing that effort constraints might be "generative" deserves more scrutiny than a single charming demo provides.

The METR Numbers and What They Actually Mean

Bricken cited the METR benchmark—which tracks how long AI models can sustain autonomous task performance at human-equivalent quality—to show Claude handling roughly 16 hours of human work at around 50 percent accuracy. These figures come from Bricken's presentation of the data; readers should treat them as Anthropic's characterization of METR results pending independent verification against the published dataset. But even accepting the figures directionally, the policy implication is significant: we are already past the point where AI agents operate in human-supervised time frames.

Sixteen hours of autonomous operation, even at 50 percent accuracy on complex tasks, means errors compound before any human reviews the work. The token cost dynamics that come with Anthropic's most capable models make this worse: the more you run these systems at high effort on long-horizon tasks, the more expensive it becomes to audit what they did. The economic incentives and the oversight requirements point in opposite directions.

The Accountability Gap Nobody Introduced

Bricken sketched an ideal future state clearly: "I want to be able to say to Claude, 'Hey, I'm only going to spend this amount on whatever you do,' or 'only take this long—a week—to do it,' and then eventually Claude just knows how to allocate that compute appropriately."

That's a clean engineering vision. It also describes a system operating for a week, making resource allocation decisions autonomously, with its constraints set by a developer and its actions reviewed—when?—by whom?—under what legal framework?

This is not a hypothetical governance challenge. The EU AI Act, which entered force in 2024, imposes tiered obligations on AI systems based on their risk classification and degree of autonomy. A system making consequential decisions over a week-long horizon without meaningful human checkpoints almost certainly crosses into territory requiring human oversight mechanisms, conformity assessments, and potentially registration in the EU database. What "oversight mechanism" means legally in that context isn't settled. The Act's provisions are still being interpreted through technical standards that haven't been finalized.

In the U.S., we have substantially less. The Biden-era executive order on AI is partially intact; the FTC has issued guidance but not rulemaking; NIST's AI Risk Management Framework is voluntary. The agentic capabilities that Bricken describes—and that are built into Claude's expanding developer toolkit—are advancing faster than any regulatory structure can currently address.

The effort-level system Bricken describes is, among other things, a compute governance mechanism. Developers are being given explicit control over how many resources an AI system consumes and, implicitly, how much autonomous problem-solving it performs before returning a result. That is exactly the kind of architectural decision that regulators are going to care about—and currently aren't equipped to evaluate, because the technical vocabulary for it barely exists in policy circles yet. "Thinking budget" is not a term that appears in the EU AI Act. Neither is "effort level." Neither is "adaptive thinking."

When a week-long autonomous agent makes a costly error—executes a bad trade, sends an unauthorized communication, deletes the wrong files—the liability question doesn't resolve itself because the developer set a compute budget. The budget constrained the resources; it did not constrain the harm. That distinction matters enormously, and right now there is no regulatory framework anywhere that adequately addresses it. The thinking lever is a real and useful engineering tool. What it becomes at scale, operating for days without human review, inside enterprise systems that may themselves be classified as high-risk under emerging AI law—that's the conversation the developer conference didn't have.

---

Samira Barnes covers technology policy and regulation for Buzzrag.