What Claude Is Actually Capable of. Most People Have No Idea.

At some point this year Claude stopped being a tool you talk to and became a system that does things on your behalf.

It happened across a dozen separate launches - Fable 5, Opus 5, scheduled tasks, Claude Code, a context window that can now hold thirty novels at once. Each one got covered, discussed, then scrolled past.

Along the way, your timeline filled up with terms you half-learned. Agents. Loops. Graphs. You saw them explained, nodded along, and moved on. Most people using Claude today could not tell you what any of them actually mean in practice.

**By the end of this article you will know what actually changed, what all those terms mean, and what Claude can do today: **agents, loops, graphs, and everything else your timeline mentioned once and never explained properly

The models changed

1. Fable 5

Released in June, briefly pulled due to export restrictions, back in July. If you missed the window when it launched you probably just heard “new Claude model” and moved on. That was a mistake.

Fable 5 is not a better version of the Claude you already knew. The models before it, Sonnet, Opus - responded to instructions. Fable 5 reasons through problems before responding. It plans. It runs tasks for hours without checking in. It catches its own mistakes mid-run. Give it a destination and it figures out the route. Give it a route and you slow it down.

The habits that worked on older Claude, breaking tasks into steps, asking it to show reasoning, checking in every few messages, actively get in the way with Fable 5. The model is built to hold the thread. Interrupting it is like stopping someone mid-sentence to ask how they’re thinking.

There are four models in the lineup now and most people use whichever is default:

ModelUse it forSkip it whenFable 5Complex reasoning, long agentic runs, creative work that needs to be exceptionalSimple tasks - overkill and costs moreOpus 5Deep analysis, research synthesis, sustained judgment across long documentsSpeed matters - it’s slower by designSonnetMost daily tasks - drafting, editing, coding, researchYou genuinely need Fable 5 level outputHaikuFast, cheap, simple outputs - summaries, formatting, quick editsThe task requires real thinking

Using the wrong model costs more and produces less

2. Opus 5

Fable 5 gets most of the attention. Opus 5 is the one that deserves more of it.

Where Fable 5 is built for reasoning speed and agentic runs, Opus 5 is built for depth. It reads slower, thinks longer, and does not reach for the first plausible answer. Give it a complex document, a hard research question, a decision with twenty variables, Opus 5 is the model that will find the thing buried on page fourteen that changes the whole picture.

Most people never reach for it because they do not know what it does differently. The gap is not obvious on simple tasks. It shows up when the work is genuinely hard.

Same prompt, two models:

❌ Sonnet - “Analyze this acquisition target and flag any risks.”

Returns a clean summary. Market position, revenue trends, integration complexity. Everything you already suspected. Nothing you did not.

✅ Opus 5 — Same prompt, same document.

Flags the deferred revenue recognition on page fourteen. Notes that the customer concentration is higher than the headline number suggests — three clients account for 61% of revenue, none of them under contract beyond next year. Points out that the integration timeline assumes a tech stack migration that has never been completed on schedule in any comparable deal.

It found what you needed to find. Not what you already knew.

Opus 5 is slower and costs more than Sonnet. That is worth it exactly once, when the stakes of getting it wrong are higher than the cost of thinking longer.

3. The context window

Every time you summarize a document before pasting it into Claude, you are solving a problem that no longer exists.

Most people learned to ration what they give Claude. Paste the relevant section, not the whole document. Summarize the email thread, do not dump the whole thing. Pull the key parts of the codebase, not every file. Those habits made sense in 2023. The context window was small and hitting the limit was a real problem.

The context window is 1,000,000 tokens now. In practical terms:

• A 400-page book fits inside it with room to spare

• Your entire email history for a year fits inside it

• A full software codebase fits inside it

• Every meeting transcript from the past six months fits inside it

The instinct to edit down, summarize, and select the “relevant parts” before handing something to Claude is the single most common way people leave value on the table. Claude does not get confused by more information. It gets more accurate. The thing you cut out because it seemed tangential is often exactly the thing Claude needed to give you a useful answer.

Stop editing down. Paste the whole thing. Let Claude find what matters.

The way you work with Claude changed

4. Agents

4.1 What an agent actually is

A chat is a single exchange. You ask something. Claude answers. The conversation ends or you ask again. You are always in the loop, the engine moving things forward is you.

An agent is different. You give Claude a goal and it runs toward it. It plans the steps, executes them one by one, uses tools, checks its own work, and keeps going until the task is done or it hits something genuinely ambiguous. You are not in the loop. You are waiting for the result.

The difference is not a feature you turn on. It is a shift in how you frame the request. “Write me a summary of this document” is a chat. “Research the top five competitors in this space, pull their pricing, find the gaps, and give me a report I can send to my team” is an agent task. Same Claude. Different relationship.

4.2 What it looks like in practice

You brief Claude the way you would brief a capable person you trust to figure out the rest.

❌ **Chat approach: **“Search for information about Notion’s pricing.”

Claude returns what it found. You read it. You ask a follow-up. You read that. You piece it together yourself.

✅ **Agent approach: **“I need a competitive analysis of the five biggest project management tools - Notion, Asana, Linear, Monday, ClickUp. For each one: current pricing tiers, what changed in the last six months, where users complain most in reviews, and the one thing they do better than everyone else. Format it as a table I can drop into a deck.”

Claude plans the research, pulls each one, cross-references, formats the output, and delivers something you can actually use. You gave it a destination. It found the route.

with web search enabled, Claude handles this kind of multi-step task in a single run. For heavier agentic work, tasks that run for hours, write files, execute code - that is Claude Code territory.

4.3 When to use one

Not every task needs an agent. A quick edit, a short summary, a question you need answered fast - these are chat tasks and turning them into agent runs adds friction for no gain.

An agent earns its place when:

• The task has multiple steps that all feed into a final output

• You would normally spend 30 minutes going back and forth to get there

• The result needs to be ready to use, not a starting point for more work

• The steps are clear enough that Claude can make the decisions along the way

The simplest test: if you find yourself asking Claude one thing, reading the answer, then asking the next thing based on what it said, that is an agent task disguised as a conversation. Collapse it into one brief and let Claude run it.

5. Loops

5.1 What a loop is

An agent runs a task and delivers a result. A loop runs a task, checks whether the result is good enough, and if it isn’t - runs it again.

The structure is always the same: do the work, verify it against a goal, iterate if it falls short, stop when it passes. That cycle is the loop. It keeps going until it either succeeds or hits a limit you set.

The reason this matters is that first attempts are rarely the best version of anything. A piece of writing that goes through three rounds of self-critique and revision is better than one that doesn’t, and a loop is just that process made automatic. You define what “good enough” looks like. Claude figures out how many passes it takes to get there.

5.2 The verify step - what makes it actually work

Most people who try loops miss this part and wonder why the output keeps coming back mediocre.

The loop is only as good as the thing doing the checking. If you ask Claude to do a task and then ask the same Claude to check whether it did it well, you get a model grading its own homework. It will find the output acceptable almost every time. The loop spins, the score comes back high, the task exits, and the output is average.

The verify step needs teeth. That means one of three things:

• A hard condition that either passes or fails. Code that compiles or doesn’t. A word count that hits the target or doesn’t. A claim that has a source attached or doesn’t. Something binary that Claude cannot talk its way around.

• A rubric with specific criteria. Not “is this good” but “does this open with a specific example, does it avoid the word ‘leverage’, is every paragraph under four sentences.” Criteria Claude can check one by one and score honestly.

• A separate reviewer. A second Claude instance with a different instruction set, not “check if this is good” but “find everything wrong with this and be specific.” Fresh context, no memory of writing the thing it’s reviewing. That distance is what makes the feedback real.

Without one of these three, you do not have a loop. You have Claude agreeing with itself on a schedule.

5.3 When a loop is worth building

A loop costs more than a single run. Every iteration spends tokens, and the verify step adds another layer on top. For a task you run once and never repeat, the setup cost rarely pays for itself.

A loop earns its place when:

• Quality matters more than speed - you need the best version, not the first version

• The task repeats - the same type of work comes back weekly or daily

• You have a clear definition of done - “good enough” is something you can describe, not just feel

• The first pass is reliably not good enough - there is always something to fix on the first attempt

The most common mistake is building a loop for a one-off task. The second most common is skipping the stop condition. A loop with no exit runs until it runs out of budget or hits an error. Set a maximum number of iterations before you start, three is usually enough, five is almost always too many.

If a task takes you two minutes to review and fix manually, it probably does not need a loop. If it takes you thirty and you do it every week, it does.

6. Graphs

6.1 What a graph is

You have an agent now. You know it can run a task from start to finish without you steering each step. The next question is: what happens when the task is bigger than one agent can handle, or when parts of it could be running at the same time instead of one after another?

That is where graphs come in.

A graph is a map of jobs and dependencies. Two building blocks, nothing else.

A node is one unit of work. One agent, one task, one thing going in and one thing coming out. Research this company. Review this file. Write this section.

An edge is a dependency. It connects two nodes when the second one genuinely needs what the first one produced. Not “these happen in order” - only when the output of one is the actual input of the next.

Nodes do the work. Edges carry what moves between them.

The reason this matters is the word “genuinely.” Most workflows have more edges than they need. Steps wait for other steps not because they depend on each other but because that is the order someone typed them in. A graph forces you to draw out every dependency explicitly, and when you do, you find the ones that were never real.

6.2 The diamond

Once you start drawing graphs, one pattern shows up more than any other. It has a name: the diamond.

One node at the top fans out into several parallel nodes. Those parallel nodes all feed into one final node that pulls their outputs together. Draw it and the shape looks like a diamond.

The reason it matters is time. In a linear workflow, three research tasks run one after another, total time is all three added together. In a diamond, they run at the same time - total time is the slowest one. Same work, different structure, fraction of the wait.

The diamond works because the three research nodes have no dependency on each other. None of them need what the others produced. The only real dependency is the synthesis node at the bottom, which needs all three. So you run everything that can run at once, and you only wait where waiting is unavoidable.

Once you see it, you find it everywhere. Any time a workflow has a “gather from multiple places, then combine” shape - that is a diamond. Research pipelines, code reviews, market analyses. The gathering is parallel. The combining is the convergence point.

6.3 The fake-edge test

Not every arrow in your workflow is real. Some steps appear sequential only because that is the order you wrote them down. The fake-edge test finds those arrows and removes them.

At each connection in your workflow, ask one question: does this step actually need the result of the one before it? Not “does it come after it” - does it genuinely use what the previous step produced?

If yes, the edge is real. If no, there is no edge. Those two jobs can run at the same time.

The classic example: “review file A for bugs, then review file B for bugs.” It reads like a sequence. But the review of file B never looks at what file A returned. They only run one after the other because that is the order you typed them. Run them at the same time and the whole thing finishes in the time of the slower one, not the two added together.

Run this on any workflow in five minutes:

• Write out every step as a box

• Draw an arrow between each consecutive pair

• For each arrow: does data actually cross here?

• If yes - keep it. Real dependency

• If no - delete it. Fake edge

• Everything with no incoming arrow can start immediately

You will find two or three fake edges in almost any workflow you draw. Each one is time you are giving away for free.

Claude left the chat window

Everything so far has assumed you are in the conversation. You open Claude, you give it work, you wait for the result. That assumption stopped being true a while ago.

7. Scheduled tasks

Claude can run without you. You set a task once - what to do, when to do it, how often, and Claude executes it on schedule. No tab open. No trigger from you. It runs, produces the output, and saves it to your folder.

Most people do not know this exists. The ones who do tend to use it once and then build five more within a week.

The most common use is a morning briefing. Claude checks the news on whatever topics you care about, pulls what is relevant, strips the noise, and has a clean summary waiting for you before you open your laptop. You did not ask for it that morning. You set it up once and it just arrives.

Here is one you can paste directly:

Every weekday at 7:30am, do the following:

1. Search for the top AI and tech news from the last 24 hours
2. Pick the 5 most important stories - focus on things that are surprising, have real implications, or most people missed
3. For each story: headline, 2-sentence summary, why it matters
4. Save the result as “brief-[date].md” in my /briefs folder

Keep the tone direct. No filler. Readable in under 3 minutes.

Set it once. It runs every weekday morning. You never think about it again.

8. Claude Code

Most people think of Claude as something that lives in a browser tab. Claude Code lives in your terminal. It reads your actual files, writes code, runs it, reads the errors, fixes them, and keeps going until the task is done, without you copying anything into a chat window.

The thing that makes it different from asking Claude to write code in a regular conversation is access. In a chat, Claude can see only what you paste. In Claude Code, Claude sees your entire project. It knows how the files connect, what the existing patterns are, what you already built. It writes code that fits what is actually there, not a generic version of what you described.

You do not need to know how to code to use it. You describe what you want in plain English. Claude Code figures out the implementation.

You can try with simple:

pythonBuild me a Python script that:

• Watches my /downloads folder for new PDF files
• When a new PDF appears, extracts the text
• Sends a summary to my email
• Logs every file it processes with a timestamp

Use existing libraries where possible. Add error handling so it doesn’t crash on corrupted files.

9. Claude in Chrome

Every time you copy something from a webpage, paste it into Claude, read the response, and then go back to the page to do something with it, you are doing the slow version of something that does not have to be slow.

Claude in Chrome is a browser extension that gives Claude full visibility into whatever tab you have open. It reads the page. It clicks links. It fills forms. It navigates. You describe the task in plain language and Claude does it on the page directly, without you touching anything.

❌ **Without it: **

You find a list of 50 job postings. You open each one, copy the details, paste them into Claude, ask for a summary, copy the summary somewhere. Repeat 50 times.

✅ **With Claude in Chrome: **

“Go through every job listing on this page. Extract the job title, company, salary if listed, and the top three requirements. Build me a table sorted by salary. If there are multiple pages, keep going until you’ve covered all of them.”

Claude reads the page, navigates through it, extracts everything, and returns a formatted table. You described the outcome. Claude handled the clicking.

The shift is the same as the agent shift, you stop doing the steps and start describing the destination. The difference is Claude can now see and act on the web directly, not just the text you chose to paste.

What to do with all of this

At the start of this article I said most people using Claude in 2026 are still using 2023 Claude. You now know why that gap exists and exactly what sits on the other side of it.

Nine things. Three models that changed what is possible. Three workflow patterns that changed how you give Claude work. Three tools that took Claude out of the chat window and put it into your browser, your terminal, and your schedule.

You do not need to implement all of it. Most of it you will not touch for months. That is fine.

But pick one thing - scheduled tasks, Claude Code, or Claude in Chrome, and try it this week. Not because it is the most important thing in this article. Because it is the one that will make the rest of it feel real.

The moment Claude does something useful while you were not watching, the mental model shifts. You stop thinking of it as a tool you operate and start thinking of it as something that works.

That shift is harder to explain than anything else in this article. But once it happens, you will not go back to opening a chat and typing a question and waiting for an answer and asking the next thing.