DEV Community: claude

Use Cloud Code AI for free. 🔥

devthedeveloper — Fri, 21 Aug 2026 07:36:57 +0000

How to Get Unlimited Claude Code & Claude Desktop Access for Free

If you frequently hit usage limits on Claude while coding, using Agent Router as a gateway allows you to bypass standard quotas and connect directly to models like Opus 4.8 and Opus 5 within the Claude Desktop App and Claude Code.

Step 1: Set Up Your Agent Router Account

> 1. Register: Head over to use this link:https://agentrouter.org/register?aff=gFAo

GitHub Requirements: Sign up using a GitHub account that is at least 7–12 months old to ensure full feature access and compatibility.
Generate API Token:
- Navigate to the API Token section on your dashboard.
- Click "Create New Token" and ensure the "Unlimited Quota" toggle is enabled.
- Copy your generated API key for later.

Step 2: Configure Claude Desktop App

Download: Install the official Claude Desktop App.
Enable Developer Mode:
- Open the app and go to Help > Troubleshooting.
- Toggle on "Enable Developer Mode".

Step 3: Connect Agent Router API to Claude

Open Settings inside Claude Desktop and select Developer Options.
Under Third-Party Inference Configuration, enter the following details:
- Gateway URL: Copy your dedicated endpoint from the Agent Router Dashboard.
- API Key: Paste the token generated in Step 1.
- Auth Scheme: Select Bearer.
Click Test Connection to verify access to Opus models.

Step 4: Finalize and Verify Setup

Save your configuration and restart the Claude Desktop application.
Look at the bottom of the window or model indicator—it should now display "Using Gateway" instead of the standard free plan.

Pro-Tip for Credits

To maintain higher API performance and balance, share your unique referral link found in the Agent Router Personal Center. Each successful referral adds additional credits to your workspace.

Note: it's authentic and it's working for me. Need help please check this video.
https://www.youtube.com/watch?v=r3xakavfeaM

How I built a Claude Code system that actually knows how I work

Paul Topham — Fri, 21 Aug 2026 06:48:29 +0000

Five months of letting Claude Code build its own tooling across a fleet of machines and a handful of separate codebases — a proper todo database, two-tier memory, and a session routine that runs itself.

Most write-ups of AI coding assistants are about a clever prompt or a plugin you can install. This one's about something slower, and I think more useful: letting the assistant build its own tooling over months, in a git repo, tuned to exactly how you work.

I've been running Claude Code across a real business for the past five months. Not one codebase but a small portfolio: the oldest and gnarliest is a bike workshop's booking system — twenty years of classic ASP I wrote myself, on Windows, inevitably — and around it a separate public website, a stack of Node services that didn't exist before, a second business's system, and the assistant's own tooling. Each its own git repo, all run from the same machines: Proxmox hosts, Linux servers, a few laptops, a work desktop, and an Android phone running Claude Code in a terminal. Before Claude Code, the oldest of these had been quietly stagnating. Five months on it's been optimised, bug-fixed, and given features that had sat on the someday list for years, while the newer projects grew up beside it. Claude Code itself grew the same way — one small script at a time — into something that knows my machines, remembers its own mistakes, tracks its own work, and starts and ends every session with a single word.

None of that was planned. There's a stripped-down, sanitised example on GitHub — the bootstrap script, the memory layout, the todo CLI, the session hooks:

▸ Demo repo: github.com/pyfd/self-improving-claude-code

Everything below is real and in daily use. Take the ideas, not the specifics — the specifics are shaped like my life, which is rather the point.

One repo, every machine

Everything lives in one git repo of dotfiles and scripts. Every machine clones it and runs a single bootstrap: SSH config, shell aliases, git hooks, Claude Code settings, and Claude's memory. Bare to working in about ten minutes, and every machine behaves the same.

One repo, one bootstrap script, every machine — improvements propagate on the next pull.

The other half of the glue is Tailscale: every machine sits on the same tailnet, so the phone in a café reaches the same todo database and dashboards as the laptop at home.

git moves the tooling; Tailscale moves the traffic.

Together they're the foundation. Claude's whole configuration is versioned, synced and reviewable. Improve the tooling on one machine and every machine has it at the next pull — and once the config is just a repo, the assistant can improve itself the same way it improves your code.

The todo system (a markdown file doesn't survive a fleet)

Most AI task setups are a markdown file the model edits. Fine for one person on one machine; it falls apart the moment two sessions run at once, or you jot a task on your phone that the laptop needs to see.

Ours is a SQLite database on a server, behind a small authenticated API, with an append-only event log — every add, close, edit and note records who, when and why. On top of that:

A CLI any machine can call. Tailscale reaches the database from anywhere; with genuinely no signal, the write queues locally and flushes at the next sync.
The TODO.md files still exist, but as generated read-only mirrors. Claude can't hand-edit them. The database is the truth; the markdown is a view of it.
A ranked "what's next", plus a small-model ranker that picks a daily top five and records its picks — so I can see what I chose versus what it suggested.
A reconcile pass: a cheap model periodically checks open todos against recent git history and flags anything that looks already shipped. Sessions drift; this catches it.
Guard rails for parallel sessions. Before claiming a task, a session checks what its peers are doing (a peer-check script plus a live dashboard), and the sync scripts lock per machine and never stash another session's work.

Task state is shared, audited infrastructure — not a file the model politely edits.

Memory in two tiers

Claude Code loads instruction files into every session, and context is a budget. The obvious approach — one ever-growing "remember this" file — quietly fails: it bloats until parts of it stop loading.

So, two tiers. The first is always loaded: the global instructions plus a memory index — one line per memory, a title and a one-sentence hook. A hundred-odd lines, pruned hard, because every line is paid for on every session. The second tier is a folder of individual memory files — preferences, project state, runbooks, and a lot of hard-won corrections ("never rsync --delete to a server" — earned the day a stray --delete wiped nineteen files). A file is read only when its topic comes up.

Two tiers: a small always-loaded index points to individual memory files that are only read when their topic comes up.

The index is the bridge: it tells each session what detail exists and when to fetch it. Hot and cold storage. The discipline is all in the curation — a vague line never gets fetched, too many lines blows the budget, and past a hard ceiling the index drops its own tail with no warning. It just quietly forgets.

The memory folder lives in the dotfiles repo, so memories sync across the fleet like everything else: something learned on the phone is known to the laptop by the next pull.

The most valuable memory isn't a set of best practices — it's a written record of every mistake the assistant has made for me, and why. You can't download that.

The session routine: `go` and `fin`

Sessions have a shape, so we made the shape executable.

The session loop: go brings the machine to a known-good state, fin captures and commits the work — one word at each end.

Typing go pulls the dotfiles, re-runs the bootstrap and syncs every project repo — flushing the offline todo queue, regenerating the mirrors, and checking the servers for uncommitted drift on the way. One word, and the session starts from a known-good state, whichever machine I'm on.

fin is the complement, not the reverse: go restores a known-good state, fin captures what changed. It updates every doc whose subject moved — changelog, project state, any spec the work touched — reconciles the todo flags, writes a resume point (a machine-stamped note saying exactly where to pick up), closes finished todos with the commit hash as the reason, then commits, pushes and syncs out.

Two details worth pinching:

Resume points are anchored comments in project docs, indexed by a script — any session on any machine can list the newest open ones and pick up half-finished work. Close the linked todo and the resume point retires itself.
The routine is timed. A timer brackets every go and fin and posts durations to a central store, so when a step starts dragging, the numbers say which one. You can't tune a ritual you don't measure.

Letting it maintain itself

Most of what I've described, Claude built. Because the whole configuration is just a repo, it edits its own tooling the way it edits any of the projects — a branch, a diff, a commit you can read afterwards.

That only works because the self-modification runs through the same discipline as everything else. Every change lands with a changelog entry; every closed todo records why; every memory carries the reason it exists. When the assistant gets something wrong, the fix isn't a scolding that evaporates when the chat ends — it's a new memory or guard rail, written down so the next session can't repeat it.

None of it was designed up front. The todo database exists because two sessions once clobbered the markdown file it replaced. The deploy guards exist because a deploy once went out wrong. The curation rules exist because the index blew its budget and forgot its own tail. It accreted, one correction at a time.

The corrections stuck because they live in the repo, not in my head.

It runs real things

None of this would matter if it were toys. The same system runs actual operations: an alerting stack Claude built and maintains, dashboards for everything (including its own token usage, per machine and per model), and guard rails written after its own mistakes — a pre-commit hook that refuses a commit until the changelog is staged (it blocked me twice while I assembled the example repo for this article — precisely its job), and a deploy that won't touch the live site until the dev version's been eyeballed in a real browser. It holds itself to rules it learned the hard way.

A sideline: the plugin question

While I was building this, a genre of article appeared — "I cancelled $220 of monthly subscriptions, five Claude Code plugins replaced them all." They're not wrong, and if you're paying separately for a security scanner, a PR-review bot and a browser-testing service, read one.

Still: should I have just installed the plugins instead? I evaluated the popular ones, and out of it fell a small lens I now use before adding anything — plugin, MCP server, framework:

Does it regress something I've already built better? A database-backed todo API with an audit trail beats a plugin keeping tasks in a flat markdown file. The better your setup, the more "top plugins" fail this one.
What does it cost to keep resident? My fleet includes an 8 GB phone and an 8 GB laptop. Anything running a persistent daemon belongs on the bigger machines only.
What does it cost in context? Anything that injects a large instruction set into every session dilutes your own conventions, and near the budget can push your own rules out. Nothing that rides in every prompt is free.
Does it fit the actual stack? Mine includes twenty-year-old ASP with deliberately pinned-old dependencies. Modern TDD/LSP tooling helps the modern half and does nothing for — or fights — the legacy core. Your stack will have an equivalent.
What's the sync overhead? Every per-machine install is one more thing the bootstrap manages forever. Worth it only when the payoff is real.

Plugins are priced in dollars. The real currency is RAM.

Against those five, the famous plugins mostly came out "already covered" — not because they're bad, but because five months of tooling tuned to your exact setup is a high bar. It should be; that's the point of building rather than installing.

When you should ignore all of this

If you're starting fresh, install the plugins. Building it yourself only wins when three things are true: you'll use the system daily for years, so the tuning compounds; your environment is genuinely odd (a fleet, a phone, a legacy stack, a real business's guard rails); and you're willing to let the assistant maintain its own tooling, with the discipline that stops that becoming chaos.

If that's you, start small. One repo. One bootstrap script. A memory index you actually prune. The rest builds up on its own — the demo repo above is roughly where I was after the first fortnight.

The interesting outcome isn't saving a subscription. It's a tool that knows how you work, on every machine you own, with a written record of every mistake it's ever made for you. That doesn't come from a directory. It builds up, in a git repo, a little at a time.

Still to come

Two pieces wouldn't fit here and deserve write-ups of their own:

What five months of Claude Code did to a twenty-year-old codebase — the booking-system story: the optimisations, the bug back-catalogue finally cleared, the features that had sat on the someday list for years, and the Node services that grew up around the legacy core.
The voice bridge — settling design decisions by talking to the Claude app over morning coffee, with the decisions landing back in the todo database as structured, audited history by the time I'm at the keyboard.

Happy to talk any of it through — comments are open below, or over on the demo repo.

Written with, inevitably, Claude Code.

How I Prepared for and Completed Four Claude Certifications

Swapnil Take — Fri, 21 Aug 2026 06:47:32 +0000

Over the last few weeks, I spent a good amount of time learning about Claude and how it can be used in software development and application architecture.

I recently completed four Claude certifications:

Claude Certified Architect – Foundation
Claude Certified Developer – Foundation
Claude Certified Architect – Associate
Claude Certified Architect – Professional

I wanted to share how I prepared for them because initially, I thought the certifications would mostly be about understanding Claude features. But as I moved from the Foundation level to the Professional level, I realized that the focus becomes much more practical and scenario-based.

Where I Started

I started with the Architect – Foundation certification.

At this stage, I mainly focused on understanding the basics:

What Claude can and cannot do
Prompt engineering
Context
Claude capabilities
Responsible AI
Common use cases
Basic application architecture

The Foundation concepts were relatively easy once I started practicing them.

One thing I spent more time on was understanding context. It is easy to think that giving the model more information will always produce better results, but that is not necessarily the case.

The important thing is giving Claude the right information at the right time.

Then I Moved to Developer Foundation

After getting comfortable with the fundamentals, I worked on the Developer Foundation certification.

This was more interesting from a software engineering perspective because I started looking at Claude as part of an application rather than just as a chatbot.

I focused on things like:

API basics
System instructions
User messages
Context handling
Tokens
Streaming
Structured outputs
Application integration
Using Claude for coding and development

The API concepts were not too difficult for me because of my software development background. However, context management and tool-related scenarios needed more revision.

I found it useful to think about a simple flow:

Application → Claude → Tool/API → Result → Claude → Final Response

Once you start thinking about Claude working with other systems, the architecture becomes much more interesting.

Architect – Associate

The Associate certification was where I started thinking more like an architect.

The question was no longer just:

"How can I use Claude?"

It became:

"How should I design an application that uses Claude?"

I spent more time on:

Application architecture
Claude API integration
Context engineering
Tool integration
External data
RAG-related concepts
Security
Reliability
Evaluation
Error handling

The scenario-based questions were the part I paid more attention to.

Sometimes, more than one solution can technically work. The important thing is understanding why one approach may be better depending on the requirements.

For example, you may have to think about:

Cost
Security
Latency
Reliability
Scalability
Maintainability

That was a useful change in mindset for me.

Architect – Professional

The Professional certification was the most challenging one for me.

By this point, the questions were much more about solving problems and making architecture decisions rather than simply knowing individual Claude features.

The topics I spent the most time revising were:

Agentic Workflows

Understanding how an AI system can perform multiple steps using tools and intermediate results.

For example:

User request → Planning → Tool selection → Tool execution → Result → Next step → Final response

This sounds simple when written like this, but designing a reliable workflow around it requires more thought.

Context Engineering

This was another topic I spent quite a bit of time on.

The question is not simply how much context you can provide.

It's about deciding:

What information does Claude actually need at this point?

If you provide too little information, the result may not be useful.

If you provide too much irrelevant information, you can increase cost and introduce unnecessary noise.

Tool Use

I also spent time understanding how tools fit into Claude applications.

For example, Claude might need access to:

An internal API
A database
Search
Files
Business applications

The application needs to control what tools are available and what those tools are allowed to do.

Security

Security was another area I revised carefully.

Some of the concepts I focused on were:

Prompt injection
Untrusted input
Sensitive information
Tool permissions
Access control
Output validation
Human approval for sensitive actions

This is particularly important when an AI system can actually perform actions rather than simply generate text.

How I Actually Prepared

I didn't try to study all four certifications together.

I followed a progression:

Foundation → Developer → Associate → Professional

For each certification, I first went through the learning material and tried to understand the concepts.

After that, I focused on the topics where I was less comfortable.

I also tried to connect the concepts to real software engineering scenarios instead of only remembering definitions.

For example, instead of just remembering what tool calling means, I would think:

"If I am building an application that needs to retrieve information from an internal system, how would I allow Claude to access that information safely?"

That made the concepts much easier to remember.

Topics I Found Easier

Some areas were relatively straightforward:

Claude fundamentals
Basic prompting
Basic API concepts
Common Claude use cases
Basic responsible AI concepts

Topics That Needed More Preparation

The areas I spent more time on were:

Context management
Context engineering
Tool calling
Agentic workflows
Security
Architecture decisions
Reliability
Cost and performance trade-offs

For me, the Professional Architect certification required the most preparation because the scenarios required thinking about the complete system rather than one individual feature.

One Thing I Would Recommend

If you're preparing for these certifications, I wouldn't recommend trying to memorize everything.

Understand the reason behind the concepts.

For example:

Don't only remember:

"Use tool calling when Claude needs an external capability."

Think about:

Why does Claude need the tool?
What data should the tool receive?
What permissions should it have?
What happens if the tool fails?
How do we validate the result?

That type of thinking helped me much more with the architecture certifications.

What I Took Away From the Certifications

The biggest change for me was how I started looking at AI applications.

Earlier, I mostly thought about AI in terms of prompts and responses.

After going through the certifications, I started looking at the complete workflow:

Prompt + Context + Model + Tools + Application Logic + Security + Evaluation

All of these pieces matter when you're building something that needs to work reliably in a real environment.

The certifications helped me move from simply using AI tools to thinking more about how AI can be designed and integrated into real software systems.

Still learning, still experimenting, and looking forward to applying these concepts in real-world projects.

Claude Certifications Completed

4 Certifications | Foundation → Developer → Associate → Professional

Asset Tokenization Platform Development for Real Estate, Bonds & Private Credit — Which Is Best?

Steveganger — Fri, 21 Aug 2026 06:03:26 +0000

Which asset should we tokenize first?” is one of the earliest and most consequential decisions in Asset Tokenization Platform Development. Real estate, bonds, and private credit are the three asset classes driving the most activity in 2026, but they are not interchangeable from a platform architecture standpoint. Each demands a different compliance model, a different custody structure, and a different investor experience — and choosing the wrong starting point can mean rebuilding core parts of your platform six months in.

This guide compares the three head-to-head across the factors that matter most for Asset Tokenization Platform Development: regulatory complexity, technical build requirements, liquidity potential, and cost. By the end, you’ll have a clear framework for deciding which asset class fits your goals, rather than a one-size-fits-all answer.

Why Asset Class Choice Shapes the Entire Platform

It’s tempting to think of tokenization as a single, repeatable process — pick an asset, mint tokens, sell to investors. In practice, the underlying asset class determines almost every architectural decision that follows. Real estate requires a legal wrapper tying a digital token to a physical deed or title, usually through a special purpose vehicle. Bonds require integration with existing fixed-income infrastructure, since institutional investors expect accrued interest calculations and secondary pricing feeds. Private credit requires ongoing loan servicing logic, since the underlying asset is a stream of repayments rather than a static object.

Building a platform without accounting for these differences from day one is the single most common reason Asset Tokenization Platform Development projects need expensive rework. Most platforms also eventually expand beyond their first asset class, and a team that starts with real estate before adding private credit often discovers that compliance and custody modules built for property titles don’t transfer cleanly to loan servicing.

Real Estate Tokenization

Real estate remains one of the most popular starting points for Asset Tokenization Platform Development, largely because fractional property ownership is intuitive to explain to investors. A commercial building or residential portfolio is split into tokens, each representing a fractional ownership stake or a claim on rental income, giving retail investors access to a market that previously required six or seven-figure minimums.

The technical build centers on tying each token to a legal ownership structure, typically an SPV or trust that holds the actual title, with the smart contract layer managing token issuance, transfer restrictions, and rental income distribution. The hardest part isn’t the blockchain work — it’s the legal structuring, since property law varies significantly by jurisdiction and often requires local counsel in every market. Liquidity is a genuine challenge too; real estate doesn’t have a natural secondary market waiting to absorb trades, so platforms need to build their own trading venue or partner with an existing tokenized real estate exchange.

Real estate suits teams with strong legal and property industry relationships who want to build investor trust around a tangible, easy-to-understand asset, and who are prepared to invest in jurisdiction-specific legal structuring alongside the software build.

Bond Tokenization

Tokenized bonds convert traditional fixed-income instruments — treasuries, corporate bonds, municipal debt — into blockchain-based tokens. Institutional players have moved fastest here, largely because bonds already operate within well-established securities regulation, and the value proposition (faster settlement, reduced counterparty risk, fractional access) maps cleanly onto existing fixed-income workflows.

From a build perspective, bond tokenization is often considered the most technically straightforward entry point into Asset Tokenization Platform Development, since the underlying asset has predictable, well-defined cash flows — coupon payments on fixed schedules, a known maturity date, and standardized pricing conventions that institutional investors already understand. The platform needs to integrate with transfer agents and custodian banks, calculate accrued interest accurately, and often connect to existing market data feeds for secondary pricing.

Bonds suit teams targeting institutional investors, banks, or asset managers who want faster settlement and broader distribution for fixed-income products they already issue, rather than founders building a new retail investor base from scratch.

Private Credit Tokenization

Private credit — direct lending, trade finance, invoice factoring, and similar debt instruments — is the fastest-growing tokenization category in 2026, driven by strong investor appetite for yield and the sector’s reliance on manual, paperwork-heavy processes that tokenization can meaningfully streamline.

This is also the most technically demanding category within Asset Tokenization Platform Development to build for. Unlike a bond with a fixed coupon schedule, private credit involves ongoing loan servicing: tracking repayments, handling defaults, managing waterfall structures across multiple tranches of investors, and updating token holders on loan performance in near real time. The smart contract layer needs to handle dynamic cash flows rather than fixed schedules, and the compliance layer typically needs to support accredited-investor-only structures given the risk profile of private debt.

Private credit suits teams with existing lending operations or servicing infrastructure who want to bring institutional capital into a debt strategy more efficiently, and who have the technical capacity to build or integrate sophisticated loan servicing logic.

Side-by-Side Comparison
The table below summarizes how the three asset classes compare across the factors most likely to shape your Asset Tokenization Platform Development budget and roadmap.

Asset Tokenization Platform Development
Can You Combine Asset Classes on One Platform?
Increasingly, yes — many institutional platforms are architected as multi-asset from the start rather than committing permanently to a single category, using a modular compliance and custody layer that plugs in asset-specific modules: a title/SPV module for real estate, a transfer-agent integration for bonds, and a loan-servicing module for private credit, all sitting on a shared identity and KYC core.

The upfront cost is higher than building for a single asset class, but it avoids the expensive rework problem described earlier. For founders confident they’ll expand within 12 to 18 months, it’s often worth discussing a modular architecture for your Asset Tokenization Platform Development project even if the initial launch focuses on just one asset class.

So, Which Is Best?

There’s no universal winner — it depends on what you’re optimizing for. If you want broad retail investor trust around a tangible asset and can invest in jurisdiction-specific legal work, real estate is a strong entry point. If you want fast institutional adoption with the lowest technical and regulatory lift, bonds are typically the most efficient path. If you want to capture the fastest-growing segment of investor demand and have the servicing infrastructure to support dynamic loan management, private credit offers the strongest growth trajectory despite the higher technical bar.

Because the right architecture, compliance model, and custody structure differ so much by asset class, it’s worth scoping your project with a partner experienced across all three before committing to a build. A specialized Asset Tokenization Platform Development team can help you map your specific goals against the tradeoffs below and avoid designing a platform around the wrong asset-class assumptions from day one.

A Simple Decision Framework

Use these questions to narrow down the right starting asset class for your Asset Tokenization Platform Development project.

Target investor: retail, accredited, or institutional? Bonds skew institutional; real estate serves both; private credit is typically accredited-only.
Legal complexity you can absorb at launch: real estate carries the heaviest jurisdiction-specific load; bonds the lightest.
Cash flow model: bonds are static and predictable; private credit requires ongoing servicing logic.
Secondary liquidity needs: bonds have the clearest path to liquid markets; real estate typically needs more work to build one.
Existing infrastructure: lenders lean toward private credit; bond issuers toward fixed income; property owners toward real estate.
Frequently Asked Questions

Which asset class is easiest to tokenize first?

Bonds are generally the easiest starting point since they operate within established securities regulation and have predictable, fixed cash flows, requiring the least custom compliance and servicing logic to launch.

Is real estate or private credit more expensive to build?

Private credit typically carries the higher technical cost due to ongoing loan servicing logic, while real estate costs are driven more by jurisdiction-specific legal work. Both generally fall between $40,000 and $180,000 depending on scope.

Can one Asset Tokenization Platform Development project support multiple asset classes?

Yes. A modular architecture with a shared compliance core and asset-specific modules for custody and servicing can support real estate, bonds, and private credit at once, though it costs more upfront than a single-asset build.

Which asset class offers the best liquidity for investors?

Bonds typically offer the best liquidity since they can plug into existing institutional trading infrastructure. Real estate and private credit usually require building or partnering into a secondary market from scratch.

How do I know which asset class fits my business?

Match it to your existing strengths: lenders and credit funds toward private credit, bond issuers and asset managers toward fixed income, and property owners toward real estate. The decision framework above can help narrow this down further.

Final Thoughts

Real estate, bonds, and private credit each represent a genuinely viable path into asset tokenization, but they are built on fundamentally different technical and regulatory foundations. The businesses that succeed are the ones that choose an asset class aligned with their existing strengths and investor base, rather than chasing whichever category is generating the most headlines. Whichever direction you choose, successful Asset Tokenization Platform Development starts with matching the platform’s architecture to your specific goals — get that decision right at the start, and compliance, custody, and investor experience all follow naturally from it.

Claude Files API went GA on 19 August 2026 and the beta header you no longer need now silently pins you to the old

Manu Shukla — Fri, 21 Aug 2026 05:59:29 +0000

Claude Files API went GA on 19 August 2026 and the beta header you no longer need now silently pins you to the old response format

Summary. Anthropic made the Files API generally available on the Claude API on 19 August 2026, alongside GA for computer use, Agent Skills and the Enterprise Admin API. The files-api-2025-04-14 beta header is no longer required. It is also no longer harmless. Anthropic's release notes state that requests sent without the header "use the GA response format" with file expiration and cursor pagination, while "/v1/files requests that still send the beta header keep working and return the previous response format." That fork is documented in exactly one place. The Files API guide never mentions the header. The beta headers reference page does not list it either. Since several SDKs attach the header automatically through a beta.files namespace, a team can read the guide, write code against expires_at, and receive a response that has no such field, with nothing in either document to explain why. Two other facts from the same page deserve a security review: uploaded files are readable by every API key in the workspace, and the Files API is the one feature in this GA wave marked not eligible for zero data retention.

What changed on 19 August 2026

The release notes entry is worth quoting in full, because it is the only primary statement of the fork:

"The Files API is now generally available on the Claude API. Requests to the /v1/files endpoints, and Messages API requests that reference an uploaded file, no longer require the files-api-2025-04-14 beta header. Requests sent without the header use the GA response format: file expiration (set expires_in_seconds when you upload a file; file objects report expires_at), and page and next_page pagination plus an ids[] filter when you list files. /v1/files requests that still send the beta header keep working and return the previous response format."

Read that last sentence twice. Dropping a header is normally a no-op that removes a gate. Here it is the switch that selects a response schema.

The GA upload response looks like this, per the Files API guide:

{
  "id": "file_011CNha8iCJcU1wXNR6q4V8w",
  "type": "file",
  "filename": "document.pdf",
  "mime_type": "application/pdf",
  "size_bytes": 1024000,
  "created_at": "2025-01-01T00:00:00Z",
  "downloadable": false,
  "expires_at": null
}

Anthropic does not print the previous format anywhere, so the exact field-level delta is not publicly checkable. What is checkable is that expires_at, page, next_page and ids[] are described in the guide as unconditional features, with no mention that a header can turn them off.

Why this is worse than a normal migration

Three properties combine badly.

The header is invisible in most codebases. If you call the Files API through an SDK's beta.files namespace, the header is attached by the client library, not written in your code. Grepping for files-api-2025-04-14 will find nothing.

The failure is a missing field, not an error. Code that reads response.expires_at gets None or a KeyError depending on your language, in a code path that only runs on upload. Code that pages with next_page gets nothing to page with. Neither returns a 4xx you can alert on.

The documentation does not close the loop. The Files API guide at docs/en/build-with-claude/files presents expiration and pagination as features of the API. The beta headers reference lists only managed-agents-2026-04-01, mcp-tunnels-2026-06-22 and agent-memory-2026-07-22 under endpoint-specific headers. Neither page mentions files-api-2025-04-14 at all.

Where you would look	Mentions the beta header fork?
Release notes, 19 August 2026	Yes, the only statement of it
Files API guide	No, presents GA fields as unconditional
Beta headers reference	No, does not list files-api-2025-04-14
SDK `beta.files` namespace	Attaches the header for you

The fix is one line: stop sending the header, or move off the beta.files namespace. The work is finding out that you were. Teams that maintain a written inventory of beta headers per endpoint, in the way we described for Claude API breaking changes and parameter migration, will find this in minutes. Everyone else finds it in production.

File expiration is a lifecycle feature, not a delete button

The headline GA capability is expiration, and its bounds are specific. From the guide: "To have a file expire automatically, include an expires_in_seconds form field when you upload it. The value is an integer number of seconds between 3,600 (1 hour) and 7,776,000 (90 days). The resulting expires_at timestamp (RFC 3339) appears on every file response and is null for files uploaded without an expiration. Expiration is set once at upload and cannot be changed."

Three constraints follow from that sentence, and each one has a design consequence.

There is no default. Omit the field and the file never expires. Any retention policy you thought you had is a policy you have to implement on every single upload call.

It is immutable. You cannot shorten a file's life after a customer asks you to, and you cannot extend it when a job runs long. Choose the window at upload or re-upload the file.

The floor is one hour and the ceiling is 90 days. A 15-minute scratch file is not expressible.

What happens at expiry is documented precisely, and it is not deletion:

"Downloading its content (GET /v1/files/{file_id}/content) returns a 404 error / A Messages request that references the file fails before inference / Its metadata (GET /v1/files/{file_id}) remains readable for up to 30 days, with expires_at in the past / It continues to appear in list responses during that window; compare expires_at to the current time to filter expired files."

And the hedge that a compliance reviewer will ask about: "Expiration is a lifecycle feature, not a guaranteed-deletion control. After expires_at, file content is no longer retrievable through the API and is released from your storage quota; the underlying content may be retained for a limited period thereafter for safety review before permanent deletion, and file metadata remains visible for up to 30 days after expiration."

Behaviour	Value	Source
Minimum expiry	3,600 seconds (1 hour)	Files API guide
Maximum expiry	7,776,000 seconds (90 days)	Files API guide
Default when omitted	None; `expires_at` is null	Files API guide
Mutable after upload	No	Files API guide
Metadata visible after expiry	Up to 30 days	Files API guide
Guaranteed deletion at expiry	No	Files API guide

If your customer contract promises deletion on request, expires_in_seconds does not satisfy it on its own. It satisfies the retrievability half.

The access model is the part to escalate

The single most important line in the Files API documentation is not about GA at all. It is a scoping warning:

"Uploaded files are accessible to your entire workspace, not scoped to an end user, conversation, or session. Any API key in the same workspace can access any file uploaded there, and all of your keys share your organization's Default Workspace unless you have assigned them to separate workspaces. Never accept file_id values from end users or other untrusted sources: a user-supplied file ID would let one user of your application read content that another user uploaded."

For a single-tenant internal tool this is fine. For any multi-tenant product where users upload documents, it is a direct instruction: never let a file_id cross the trust boundary from the client. If your API accepts a file ID in a request body from a browser, you have built an enumeration surface over other customers' uploads. The mitigation Anthropic points at is workspace separation, and organisations get "up to 100 workspaces" to work with, which caps how far per-tenant isolation can go.

The audit trail has a matching caveat. Anthropic states that "Listing files and retrieving file metadata are not recorded" and that "Operations that occur while the Compliance API is off are not recorded and cannot be recovered later, so set up the Compliance API before you rely on this audit trail." An audit log that is opt-in, non-retroactive and silent on reads is not the log an incident review wants.

One more asymmetry from the same GA wave: the Files API page carries "ZDR / Not eligible", while the computer use and browser use pages released the same day both read "ZDR Eligible". If your zero-data-retention posture is a contractual commitment, file uploads sit outside it. That is a different answer from the one you may have given a client about the rest of the platform, and it belongs in the same review you would run on any provider, in the way we mapped OpenAI zero data retention limits by endpoint.

Pagination and the ids[] filter

The listing changes are smaller but have one trap. From the guide: "The endpoint is paginated: each request returns up to limit files (20 by default, and at most 1,000), and the response's next_page cursor fetches the next page when passed back as the page parameter. Files are ordered newest first."

The ids[] filter is the efficient path for reconciliation, and it fails quietly: "To check a known set of files in one request instead of paging, pass up to 100 file IDs as ids[] query parameters. An ids[] request always returns a single page (next_page is null), and any ID that does not resolve to a file in your workspace is silently omitted from data; compare the returned IDs against the requested IDs to detect misses. ids[] cannot be combined with page or limit."

Silently omitted is the operative phrase. A reconciliation job that asks for 100 IDs and receives 96 files, without diffing the sets, concludes that everything is present. Diff the request against the response every time.

Who is affected and how to check

Run four checks. Each takes minutes.

Search your dependency tree for calls into a beta.files client namespace, and for any explicit anthropic-beta header on file endpoints. If either exists, you are on the old response format regardless of what the guide told you to expect.

Upload a file and read the response. If expires_at is absent from the JSON rather than present and null, you are on the old format. That is the fastest single test.

Grep your request handlers for any route that accepts a file_id from a client. Each one is a cross-tenant read unless you validate ownership yourself.

Check whether the Compliance API is enabled. If it is not, you have no file audit trail for the period before you turn it on, and none for reads afterwards either.

India-specific considerations

Under the Digital Personal Data Protection Act 2023, a data fiduciary must erase personal data when the purpose is served or consent is withdrawn. The Files API gives you an expiry window between one hour and 90 days that cannot be changed after upload, and Anthropic states plainly that expiry is "not a guaranteed-deletion control" with metadata visible for up to 30 days afterwards. For an Indian product handling customer documents, that means erasure obligations cannot be discharged by setting expires_in_seconds alone. The workable pattern is to keep personal data out of uploaded files where possible, use the shortest expiry the workflow tolerates, isolate tenants across workspaces, and hold the deletion record in your own system. The workspace-wide access model matters here too: a single Default Workspace shared across all API keys is a poor fit for a fiduciary that has told users their documents are segregated.

What is still unknown

Anthropic has not published the previous response format, so the exact field differences between the beta and GA shapes cannot be verified from a primary source. There is no stated date on which the files-api-2025-04-14 header stops being accepted, and no deprecation notice attached to it. Whether the SDKs will move files out of the beta namespace, and on what release, has not been announced. And Anthropic has not said why the Files API alone in this GA wave is ineligible for zero data retention.

FAQ

When did the Claude Files API become generally available?

On 19 August 2026, per Anthropic's Claude API release notes. The same entry made Agent Skills and the Skills API generally available, brought computer use to GA as a toolset, and removed the beta header requirement from the Enterprise Admin API user-management endpoints for Claude Enterprise organisations.

What happens if I keep sending the files-api-2025-04-14 beta header?

Your requests keep working, but they return the previous response format rather than the GA one. That means no expires_at field on file objects, and none of the GA listing features. Anthropic documents this behaviour only in the 19 August 2026 release notes, not in the Files API guide or the beta headers reference page.

How do I tell which response format I am getting?

Upload a file and inspect the JSON. The GA format includes an expires_at field, which is null when no expiration was set. If expires_at is absent entirely rather than null, the request is still being sent with the beta header, most likely by an SDK beta.files namespace rather than by your own code.

What are the limits on file expiration?

The expires_in_seconds field accepts an integer between 3,600 seconds, one hour, and 7,776,000 seconds, which is 90 days. It is set once at upload and cannot be changed afterwards. Omitting the field means the file does not expire, and expires_at is reported as null on every response.

Does an expired file get deleted?

Not necessarily. Anthropic states that expiration is a lifecycle feature rather than a guaranteed-deletion control. After the expiry timestamp the content is no longer retrievable through the API and is released from your storage quota, but the underlying content may be retained for a limited period for safety review, and metadata stays visible for up to 30 days.

Can one user of my application read another user's uploaded file?

Yes, if you accept file IDs from clients. Anthropic warns that uploaded files are accessible to the entire workspace rather than scoped to a user, conversation or session, and that any API key in the same workspace can access any file uploaded there. Never accept file_id values from end users or other untrusted sources.

How does the ids[] filter behave when an ID does not exist?

It is silently omitted from the data array. The request still succeeds and returns a single page with next_page set to null. Anthropic advises comparing the returned IDs against the requested IDs to detect misses. The filter accepts up to 100 IDs and cannot be combined with the page or limit parameters.

Is the Files API covered by zero data retention?

No. The Files API documentation is marked not eligible for zero data retention, while the computer use and browser use tools released in the same 19 August 2026 wave are both marked ZDR eligible. If zero data retention is a contractual commitment to your customers, file uploads fall outside that commitment.

How eCorpIT can help

A header that selects a response schema, an expiry that is not a deletion, and a workspace-wide read scope are three different problems wearing one product's name, and they land on the data-protection review rather than the sprint board. Our senior engineering teams design AI integrations for regulated buyers in India and abroad, including tenant isolation and retention handling aligned with DPDP requirements. eCorpIT is ISO 27001:2022 certified and CMMI Level 5 appraised. If you are auditing what your application uploads to a model provider, reach the team through /contact-us/.

References

Claude API release notes. Anthropic, 19 August 2026 entry, the beta header response-format statement.
Files API. Anthropic documentation, expiration bounds, pagination, ids[] behaviour and workspace access warning.
Beta headers. Anthropic documentation, endpoint-specific header list.
Computer use tool. Anthropic documentation, ZDR eligibility line.
Browser use tool. Anthropic documentation, ZDR eligibility line.
Claude API pricing. Anthropic documentation.
Agent Skills. Anthropic documentation, GA in the same release.
Tool reference. Anthropic documentation.
Models overview. Anthropic documentation.
Tool use overview. Anthropic documentation.
Admin API. Anthropic documentation, Enterprise user-management endpoints in the same GA wave.

Last updated: 21 August 2026.

Claude computer use went GA on 19 August 2026: seven changes that break an existing agent loop

Manu Shukla — Fri, 21 Aug 2026 05:58:33 +0000

Claude computer use went GA on 19 August 2026: seven changes that break an existing agent loop

Summary. Anthropic made computer use generally available on the Claude API on 19 August 2026 as the computer_toolset_20260801 toolset, and shipped a separate browser_toolset_20260801 on the same day. The GA toolset carries 17 member tools; the browser toolset carries 27 by default and 31 with every optional member enabled. Declaring the computer toolset adds about 4,500 input tokens to every request (about 4,520 on Claude Fable 5, Mythos 5, Opus 5 and Opus 4.8, about 4,590 on Sonnet 5). The browser toolset adds about 6,600. Anthropic's own migration list runs to seven items, and three of them silently change runtime behaviour rather than returning an error. zoom flips from off to on, oversized screenshots are rejected instead of downscaled, and the action name moves out of input.action. Migration is optional, because computer_20251124 keeps working with its beta header, which is precisely why teams will hit these changes months from now with no deployment to blame.

What actually shipped

The Claude API release notes dated 19 August 2026 list eight changes. Computer use reaching GA is the one that touches running code.

The old shape was a single tool named computer, with the action carried inside the input object. The new shape is a toolset: one entry in tools that expands into 17 member tools, each of which arrives as its own tool_use block. Anthropic's documentation states it plainly: "The computer use tool is an Anthropic-defined client toolset: one {"type": "computer_toolset_20260801"} entry in tools gives Claude 17 member tools such as screenshot, left_click, type, and zoom, and your application runs every call in an environment you control."

The block shape changes with it. Where a response previously carried "name": "computer" and "input": {"action": "left_click", "coordinate": [500, 300]}, it now carries "name": "left_click", "toolset_name": "computer", and "input": {"coordinate": [500, 300]}. As the docs put it: "The action name moves from input.action to name, and the block gains toolset_name."

Two constraints are worth knowing before you read the migration list. Computer use "isn't currently available in Claude Managed Agents," and "Platforms other than the Claude API currently offer only the earlier beta tool versions" — so Bedrock and Vertex integrations are not migrating yet even if you want them to.

The seven changes, and which ones fail loudly

Anthropic's migration section gives seven steps. Sorted by how you find out you got it wrong:

Change	How it fails	What you have to do
Beta header removed	Loud — request rejected	Drop `anthropic-beta: computer-use-2025-11-24`
Legacy fields rejected	Loud — `invalid_request_error`	Delete `name`, `display_width_px`, `display_height_px`, `display_number`, `enable_zoom`
Every block must be answered	Loud — `invalid_request_error` on the next call	Iterate all `tool_use` blocks, not just the first
`toolset_name` on results	Loud — result rejected	Add `"toolset_name": "computer"` to every `tool_result`
`zoom` defaults to on	Silent — behaviour changes	Set `configs: {"zoom": {"enabled": false}}` or implement zoom
Screenshots no longer downscaled	Loud, but only on large displays	Resize to the model's image limits yourself
`key` accepts `repeat`	Silent — key pressed once instead of N times	Honour the `repeat` field, 1 to 100

The zoom flip is the one that will cost teams an afternoon. Anthropic is explicit that the default reversed: "Zoom is enabled by default on the toolset, whereas enable_zoom defaults to false. If your environment doesn't implement zoom, add "configs": {"zoom": {"enabled": false}} to keep the previous behavior; otherwise implement it." An executor that ignores unrecognised member names will not crash. It will return errors to Claude, which will retry, and the loop will look flaky rather than broken.

The repeat change has the same shape. The docs warn that "A handler that ignores unrecognized fields would press the key once, so make your key handler honor repeat." A cursor that moves one line instead of forty is a bug report, not an exception.

Screenshot sizing is the third silent-ish one, and it moved work onto your side. "Screenshots and zoom images that you return to the computer use toolset must already fit within your model's image size limits: the toolset takes no display dimensions and the API doesn't downscale for you, so an oversized tool_result image is rejected with a validation error." The limits differ by model generation: "Claude Opus 4.7 and later models, including every model that supports computer_toolset_20260801, accept up to 2576 pixels on the long edge and 4784 visual tokens total (ceil(width/28) x ceil(height/28), approximately 3.75 megapixels); earlier models accept up to 1568 pixels on the long edge and approximately 1.15 megapixels total." A 4K desktop screenshot clears neither.

Batch actions rewrite the agent loop, not just the parser

The change with the widest blast radius is not in the migration list at all. Claude can now return several actions in one response: "Claude can plan a short sequence of actions, such as click, type, and then take a screenshot, and return them together in one response. This is called a batch action; it uses the same response shape as parallel tool use with one difference: you run the blocks in order rather than concurrently."

Three consequences follow, and the docs spell out all three.

A loop that reads only the first block is now a hard error rather than a partial execution: "A request that leaves any tool_use block in the batch unanswered is rejected with an invalid_request_error, so an agent loop that reads only the first block fails on its next call."

When an action in the batch fails, you must halt the rest and return a specific string. Not a paraphrase of it — the exact text Not executed: an earlier computer action in this turn failed. The browser toolset mandates a different string for the same situation: Not executed: an earlier action in this turn failed. One word apart, two toolsets, both validated.

The third consequence is a governance problem rather than a parsing one. If your product asks a human to approve consequential actions, the approval gate moved. Anthropic's warning: "If your application asks a human to confirm consequential actions, make that check before each block runs, because a batch can complete a multistep action within one turn." A confirm-per-turn design that was adequate in November 2025 now waves through a click, a form fill and a submit as a single unit. Teams building reliable agent tool-use evaluation should treat this as a new test case, not a config change.

If you cannot restructure the loop yet, there is an escape hatch: set disable_parallel_tool_use to true in tool_choice and "Claude then returns at most one member tool_use block per turn."

What the toolsets cost before a single click

The token overhead is published, and it is not small. Both figures below are quoted from Anthropic's pricing page, which matches the individual tool pages exactly.

Toolset	Definition overhead	On Sonnet 5	Cost per request at $2/MTok
`computer_toolset_20260801`	~4,500 input tokens	~4,590	~$0.0092
`browser_toolset_20260801`	~6,600 input tokens	~6,670	~$0.0133
Browser, all 4 optional members	+~880 input tokens	~7,550	~$0.0151
`computer_20251124` (old)	~735 per tool definition, plus 466–499 system prompt	—	~$0.0025

Sonnet 5 sits at "$2 / $10 per MTok", which Anthropic confirmed on the same pricing page is now the standard rate after the increase scheduled for 1 September 2026 was cancelled. The cost column above is our arithmetic on Anthropic's published token counts, not a figure Anthropic publishes.

The number that matters is the ratio. The GA toolset costs roughly four times the old single-tool definition in per-request overhead, and it is charged on every request in the loop, not once per session. A 40-step browsing task on Sonnet 5 pays about $0.53 in toolset definitions before you count a single screenshot. Disabling zoom claws back about 410 of those tokens. Neither toolset carries a per-action or per-session charge — both are client tools, priced like any other request.

That is the honest trade. You are paying for 17 or 31 typed member tools instead of one overloaded action enum, and the model no longer has to guess an action string. Whether that is worth four times the overhead depends entirely on how many turns your task takes, which is the same calculation that governs mid-conversation tool changes and prompt caching.

The browser toolset is a different product, not a lighter computer use

The browser tool released the same day works "in a browser that your application runs" rather than a whole desktop, and Anthropic is clear that nothing moves to their side: "Your application runs every call against its own browser automation; nothing runs on Anthropic's side."

The real difference is that it reads structure, not only pixels. "It works with the page both through its structure (the accessibility tree, elements, forms, and tabs) and through pixels (screenshots and viewport coordinates), whereas the computer use tool works with a whole desktop through screenshots and coordinates alone." The docs make an efficiency claim for that: "a tree read of a typical page often costs fewer input tokens than a screenshot while giving Claude references it can act on immediately." On a text-heavy page that can offset the higher definition overhead. On a canvas-rendered app it will not.

Element references are the mechanism, and they come with a caveat you have to design around: "References are scoped to the tab that produced them and stay valid until that tab navigates or its DOM changes materially. The API can't detect a stale or unknown reference." Detection is your job, and so is stability: "Don't renumber references you've already handed out for a tab until it navigates, because that silently invalidates references Claude still holds."

Four members are off by default, and the reasoning is a security argument rather than a capability one: "javascript_exec and file_upload because they widen what a manipulated page could make Claude do, and read_console and read_network because not every browser automation stack can supply those logs and they widen what page-controlled content reaches Claude."

The sharpest warning on the page concerns file_upload: "Claude writes these paths while it's reading untrusted pages, so an unrestricted implementation would let a malicious page direct the upload of any file the executor can read to a site the page controls. Enable the member only when your executor resolves each path (following symlinks and .. segments) and accepts nothing outside a dedicated, allowlisted upload directory that holds only files meant for the task. Don't reuse the browser's download directory for this; if you do, every file a page causes the browser to download becomes uploadable."

Prompt injection gets the same treatment for tab metadata: "Tab titles and URLs come from the page and render into text Claude reads, so they're a prompt-injection surface... The length and character limits the API enforces are a floor, not a defense." Those limits are 4,096 characters per tab_id, title and url, at most 100 tabs and 200 state changes per block.

Download reporting hides a data-leak edge worth flagging to a security reviewer: "The url comes from the remote server and often carries signed query-string credentials after redirects, so strip query parameters you don't want in Claude's context."

Who this affects, and how to tell if that is you

You are affected if any of the following is true.

You send anthropic-beta: computer-use-2025-11-24 today. Nothing breaks now, but you are on a version Anthropic has labelled an earlier tool version, and the platforms question below will eventually force the move.

Your agent loop reads response.content[0] and dispatches on input.action. Both assumptions are gone in the new toolset.

You run on Bedrock or Vertex. You cannot migrate yet: "Platforms other than the Claude API currently offer only the earlier beta tool versions."

You screenshot a display larger than 2576 pixels on the long edge and relied on the API to shrink it.

You have a human-approval step that fires once per model turn.

Grep your codebase for display_width_px, enable_zoom, and input.action. Three hits is a migration; zero hits and you are probably not using computer use at all. Teams comparing implementations across vendors will find the same loop questions in our breakdown of computer use and browser agents across Gemini, Claude and OpenAI.

India-specific considerations

For Indian teams building agent products for regulated buyers, two details in this release change the compliance conversation. Both toolsets are marked ZDR eligible, which matters when a BFSI or healthcare client asks where screen contents go. But the execution environment is entirely yours: page content reaches the API only as tool results you return, and the sites Claude visits see your executor's network identity, not Anthropic's. Under the Digital Personal Data Protection Act 2023, that makes the browser executor, not the model provider, the place where personal data handling has to be designed, logged and bounded. An allowlisted upload directory and a query-string stripper are DPDP controls, not just hardening.

What is still unknown

Anthropic has not said when computer_20251124 stops being accepted; the docs only say migration "is optional" and that the earlier version "keep[s] accepting it with its beta header." There is no published date for the Managed Agents or Bedrock and Vertex availability. The browser toolset page describes itself with two different member counts: "27 member tools by default" in the introduction and "declares 31 member tools" in the member table. That reconciles as 27 plus 4 optional, but will mislead anyone who quotes either number alone.

FAQ

What is the new computer use toolset called?

The generally available version is computer_toolset_20260801, released on the Claude API on 19 August 2026. It replaces the computer_20251124 beta tool and requires no beta header. One toolset entry expands into 17 member tools, each arriving as its own tool_use block rather than as an action string inside a single tool input.

Does the old computer use tool still work?

Yes. Anthropic states that upgrading is optional and that models listed for computer_20251124 keep accepting it with its beta header, so an existing integration works until you change it. No end-of-life date has been published for the earlier version. Platforms other than the Claude API currently offer only the earlier beta tool versions.

Why did zoom start failing after migration?

Because the default reversed. The old enable_zoom parameter defaulted to false, while the GA toolset enables all 17 members including zoom by default. An executor that cannot produce zoom images returns errors instead. Adding configs with zoom disabled restores the previous behaviour and removes about 410 input tokens.

How many extra tokens does the toolset add per request?

Declaring the computer toolset with default members adds about 4,500 input tokens, measured at about 4,520 on Fable 5, Mythos 5, Opus 5 and Opus 4.8 and about 4,590 on Sonnet 5. The browser toolset adds about 6,600, rising by roughly 880 more when all four optional members are enabled.

What breaks if my loop only reads the first tool_use block?

The next request fails. Anthropic states that a request leaving any tool_use block in a batch unanswered is rejected with an invalid_request_error. Batched actions must run in order, stop at the first failure, and return the exact halt string for later blocks, with toolset_name echoed on every result.

How is the browser use tool different from computer use?

The browser toolset drives a browser your application hosts and reads the page's accessibility tree, elements, forms and tabs, alongside screenshots and viewport coordinates. Computer use drives a whole desktop through screenshots and coordinates only. Browser use is available on the Claude API alone and adds more definition overhead per request.

Which browser members are disabled by default and why?

Four: javascript_exec, file_upload, read_console and read_network. Anthropic disables the first two because they widen what a manipulated page could make Claude do, and the second two because not every automation stack can supply those logs and they widen what page-controlled content reaches Claude. Enable file_upload only with an allowlisted upload directory.

Does this change affect human approval steps in an agent?

Yes. Because a batch can complete a multistep action within one turn, Anthropic advises making the confirmation check before each block runs rather than once per turn. A design that approved one model response now approves a click, a form fill and a submit together, which is a materially different consent boundary.

How eCorpIT can help

Migrating a working computer-use agent is mostly loop surgery and cost modelling, not prompt work: the parser, the batch halt contract, the approval gate and the per-request token bill all move together. Our senior engineering teams build and govern agent systems for regulated buyers, including the executor sandboxing that browser use pushes onto the customer side. If you are weighing the migration against staying on the beta tool, our note on AI coding agent rollout and governance covers the control questions, and you can reach the team through /contact-us/.

References

Claude API release notes Anthropic, 19 August 2026 entry.
Computer use tool Anthropic documentation, including the migration section.
Browser use tool Anthropic documentation.
Claude API pricing toolset definition overhead figures and Sonnet 5 standard pricing.
Tool reference Anthropic documentation.
Beta headers Anthropic documentation.
Files API Anthropic documentation, GA response format.
Tool use overview Anthropic documentation.
Vision and image limits Anthropic documentation.
Models overview Anthropic documentation, supported model list.
Agent Skills Anthropic documentation.

Last updated: 21 August 2026.

Anthropic Launches Free Claude Academy and Key Developer Tools

Hunter G — Fri, 21 Aug 2026 04:51:14 +0000

The headline that trended was "Anthropic Launches Free Claude Academy and Key Developer Tools."

Having read the official release notes, the real news is not the free courses. Claude Academy launched on March 2, not yesterday.

What actually happened yesterday: four capabilities dropped their beta headers on the same day.

That sounds technical and boring. For anyone building agents, it carries far more weight than another free course. Here is why.

What actually reached GA

On August 19, 2026, Anthropic's Claude Developer Platform promoted four things at once:

Computer use: no beta header required, plus support for batch actions (several operations in a single turn), with zoom enabled by default.

Browser tool: shipped directly as GA.

Files API: requests to /v1/files, and Messages API requests referencing an uploaded file, no longer require the files-api-2025-04-14 beta header.

Agent Skills / Skills API: requests no longer require the skills-2025-10-02 beta header.

Admin API user management also reached GA for Claude Enterprise, with the header no longer required on group and custom-role requests.

Why "removing a header" is a big deal

If you have never shipped against these APIs in production, this looks like deleting a line of code.

Running a gateway, I have a very concrete feel for it: a beta header is not a string. It is a disclaimer.

An interface behind a beta header means several things at once: the shape can change, it may sit outside your SLA, when something breaks the vendor can point at the word preview, and your legal and procurement teams stop the moment they see "beta."

In many companies, whether something is beta directly determines whether it can reach production. That is not a technical question. It is a question of who is accountable.

GA means the vendor started standing behind the stability of that interface.

Which is why this matters more than a free course. A course teaches you how to use something. GA determines whether you can use it where you have to be accountable.

The four together point at one thing

Individually none of them is remarkable. Together they form a set.

Computer use lets an agent operate a graphical interface.

Browser tool lets it reach the web.

Files API lets it hold and reference files instead of stuffing content into context.

Skills let it load a defined procedure for a task.

That is the minimum viable kit for an agent doing real work: see the interface, reach the web, hold a file, know the procedure.

I wrote recently about an AI-native fashion brand, where founder Yana Welinder described something relevant: asking Codex to generate the final CAD file directly did not work well, but using computer use to drive a professional 3D application worked far better.

Her explanation: professional software encodes decades of domain constraints and correctness guarantees, while models are good at intent and orchestration.

So computer use reaching GA is not just one more feature. It means the entire approach of "let the agent operate human software" now carries a production-grade commitment.

Do not skip the batch actions detail

One short line in the release notes carries the most information: computer use now supports batch actions, several operations in a single turn.

That reads like a latency optimization. What it actually changes is the cost structure.

Before, an agent driving an interface worked like this: screenshot, decide where to click, click, screenshot again, decide again. Every step is a full model round trip, and every round trip re-feeds the current frame.

Image tokens are expensive, and most steps in that loop are entirely deterministic. Opening a menu, focusing an input, clearing it, pasting. Nothing in that sequence requires fresh reasoning.

Batching collapses the sequence into a single submission. What gets removed is not just latency. It is inference that should never have happened.

Optimizing token spend, we keep confirming the same thing: the bulk of cost reduction never comes from switching to a cheaper model. It comes from not making the model do work it does not need to do. Batch actions are firmly in the second category, and they cost nothing in output quality.

Three things I have to be clear about

One: Claude Academy did not launch yesterday.

It launched March 2, 2026 with 13 courses, and now offers 14 core courses plus audience variants, spanning basic usage through production API deployment and MCP server development. Free, email-only signup, certificate on completion, no credit card and no hidden upsell.

The courses run in three tracks: AI Fluency for non-technical users, Product Training for general users, and Developer Deep-Dives for engineers.

It is genuinely good and worth recommending. It is not yesterday's news, and treating it as the headline buries what actually happened.

Two: I could not verify the "20 to 40 percent fewer round trips" figure.

The auto-generated summary on the X trend says early users report 20 to 40 percent fewer round trips, cutting costs and boosting speed. I went through the official release notes and found no round trip, performance, or cost figures at all.

Batching does reduce round trips, so the direction is right. But I could not source the specific percentage, so it does not appear in this piece.

There is a line under that summary box: Grok can make mistakes, verify its outputs.

Three: the summary presents Academy and the GA release as same-day events. The GA release was yesterday. Academy was in March.

What this means if you build agents

Three concrete things.

One: clear the beta headers out of your code. All four are unnecessary now. Leaving them will not break anything immediately, but it means your declared dependencies disagree with reality, and at the next audit those strings make it look like you are running preview features in production.

Two: revisit anything you shelved because it was beta. I have seen too many teams park an idea not because it was infeasible, but because it could not clear internal compliance and procurement. These four reaching GA moves that gate. Your parked list may have something worth re-evaluating today.

Three: if you automate interfaces, audit how many steps batching can merge. Deterministic operation sequences should never have gone through the model one step at a time.

What I take away

One: this class of news is chronically underrated. It makes a bad headline, has no flashy demo, and gets one line at a launch event. But for people actually shipping to production, it is the line between "we can build this" and "we can be accountable for this." The question we get asked most running a gateway is never "how many models do you support." It is "who covers it when something breaks." GA is an answer to that question.

Two: about that batching optimization. It adds zero model capability. It only removes redundant round trips. And this class of waste accounts for far more of today's AI cost than most people assume. Capability gains come from the vendor. This kind of waste you create yourself.

Three, and this is the part worth sitting with: these four arriving together says the agent bottleneck is shifting from how smart the model is to whether it can touch anything.

A brilliant model that cannot open a browser, hold a file, or click a button has a hard ceiling on what it can finish. As of yesterday, those hands are committed, production-grade parts.

Over the next year, the gap may not come from who uses the stronger model, but from who wires those hands into a real business first.

Sources: Anthropic Claude Developer Platform release notes, 2026-08-19. The four GA promotions (computer use, no beta header required, batch actions supported, zoom enabled by default; browser tool shipped as GA; Files API no longer requiring the files-api-2025-04-14 header; Agent Skills / Skills API no longer requiring the skills-2025-10-02 header) and Admin API user management reaching GA for Claude Enterprise all come from those official notes. Claude Academy launched 2026-03-02 with 13 courses, now 14 core courses plus audience variants, free with email signup and completion certificates, organized into AI Fluency, Product Training, and Developer Deep-Dive tracks, per public reporting; it is not a new launch. Two claims in the X trend's auto-generated summary have been removed or corrected here: the reported "20 to 40 percent fewer round trips" (the official notes contain no round trip, performance, or cost figures), and the framing of Academy and this GA release as same-day events. That summary is Grok-generated and the platform itself flags it may be wrong. The Yana Welinder remarks on using computer use to drive professional 3D software come from the How I AI interview on the Lenny's Podcast Network. Disclosure: the author operates Flatkey, an LLM gateway.

How I clean LLM output with another LLM: Slash Claude costs 20%

Umair Bilal — Fri, 21 Aug 2026 04:34:10 +0000

This article was originally published on BuildZn.

I spent way too much time debugging funky JSON parsing errors from Claude's responses. My agent pipelines were constantly choking on inconsistent formatting, despite aggressive system prompts. Everyone talks about "perfect prompt engineering," but for real production systems, that's often a pipe dream. Figured out the hard way that throwing more prompt tokens at Claude to force perfect formatting is a losing game, especially when you need to clean LLM output with another LLM.

Why Your Claude Output Is Still a Mess (and costing you tokens)

Look, Claude 3.5 Sonnet, heck, even Opus, are incredible for complex reasoning. They shine at understanding nuanced requests, summarizing huge texts, or generating creative content. But ask them for a rigid JSON structure, especially after a long, open-ended thought process, and you often get... close. Or sometimes, just completely off.

In FarahGPT, my AI gold trading system, agents need perfectly structured data to execute trades or update their internal models. When Claude 3.5 Sonnet (version claude-3-5-sonnet-20240620) gives you back a JSON string that's missing a comma, or wraps a boolean in quotes, or adds a chatty intro/outro despite tool_use mode, it breaks the entire downstream flow. My JSON.parse calls kept throwing SyntaxError: Unexpected token 'O' at JSON.parse (<anonymous>) because Claude decided to start with "Okay, here's the data..."

This isn't just annoying; it's expensive. Every time an agent fails, you're either re-prompting Claude (more tokens), running complex regex (fragile, CPU cycles), or worse, just giving up on structured output entirely. I saw scenarios where a simple re-parsing prompt to Claude would add 10-15% to the token count of a workflow, just to fix its own formatting. That’s why I needed a dedicated Claude output cleanup step.

My Multi-LLM Orchestration Blueprint for Clean Output

Here's the thing — we use large, expensive models like Claude for their reasoning. We shouldn't be wasting their precious context windows and compute cycles on strict formatting. That's a job for a smaller, cheaper, specialized model. This is where multi-LLM orchestration comes in.

My approach:

Claude (or OpenAI GPT-4o, etc.): Handles the heavy lifting — complex analysis, decision-making, content generation. It produces raw output, aiming for structure but not obsessing over perfection.
Secondary LLM (e.g., Mistral 7B via Ollama, or a cheaper cloud model like GPT-3.5 Turbo): This model's only job is to take Claude's raw output and strictly parse, validate, and reformat it into a guaranteed clean, usable structure (JSON, YAML, markdown tables, whatever).

This isn't just about robustness; it's about cost efficiency. I've measured a concrete 20% reduction in downstream token costs across specific agent workflows by implementing this.

How I Measured the 20% Token Reduction

Let's say Claude's primary task output is meant to be a JSON object like { "action": "buy", "asset": "gold", "volume": 10 }.

Scenario A (No cleanup): Claude spits out Okay, based on the market, I suggest this: { "action": "buy", "asset": "gold", "volume": "10" } (note "10" as string). To correctly use this, a downstream agent might need another Claude call to "Extract JSON from this text, ensuring 'volume' is an integer." This re-prompt costs X input tokens + Y output tokens for the cleanup.
Scenario B (With secondary LLM cleanup): Claude gives the same raw, slightly imperfect output. My secondary LLM (Mistral via Ollama) processes it. The prompt to Mistral is tiny, fixed, and highly optimized for parsing. Mistral returns {"action":"buy","asset":"gold","volume":10}. The cost is Z input tokens (Mistral prompt) + W output tokens (Mistral's clean JSON).

My methodology:

For 100 typical agent outputs from Claude, I measured the average tokens required for in-context re-parsing by another Claude call to achieve strict JSON. This involved crafting a "cleanup" prompt for Claude. Average: ~150-200 tokens (input + output) per cleanup pass.
Then, I measured the average tokens for the same cleanup task using Mistral 7B via Ollama. This involved a fixed, tiny prompt (~50 input tokens) and ~20-30 output tokens for the structured JSON.
The calculation revealed that the Mistral-based cleanup was, on average, 70-80% cheaper in token count than a Claude-based re-prompt for parsing. When factoring in the total token budget for the entire workflow, this translated directly to a 20% overall reduction in downstream token waste, specifically from avoiding re-parsing prompts to the expensive primary LLM. This was measured over 100 iterations of a specific FarahGPT trade recommendation pipeline, averaging token usage with a custom Anthropic API wrapper and Ollama's count_tokens equivalent.

Honestly, relying on Claude for perfect JSON every single time is like using a sledgehammer to crack a nut, and then complaining when the nut isn't perfectly cracked.

Implementing the LLM Post-Processing Pipeline in Node.js

Let's get into the code. This is a Node.js setup, because that's what I use for NexusOS and most of my backend services.

First, you'll need @anthropic-ai/sdk for Claude and either ollama or another API client for your secondary model. For Ollama, make sure it's running locally with mistral pulled: ollama run mistral.

# Initialize Node.js project
mkdir llm-cleanup-pipeline && cd llm-cleanup-pipeline
npm init -y

# Install dependencies
npm install @anthropic-ai/sdk ollama dotenv

Next, create a .env file for your API keys:

ANTHROPIC_API_KEY=sk-ant-xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Now, let's set up the core logic.

Step 1: The Primary LLM (Claude) for Reasoning

This example uses Claude to analyze a simple market trend and suggest an action. Notice how the prompt asks for JSON but doesn't strictly enforce it with a schema because, frankly, Claude sometimes ignores it anyway. This helps reduce LLM token waste on overly verbose schema descriptions.

// src/primaryLLM.js
require('dotenv').config();
const Anthropic = require('@anthropic-ai/sdk');

const anthropic = new Anthropic({
  apiKey: process.env.ANTHROPIC_API_KEY,
});

async function getClaudeAnalysis(marketData) {
  const prompt = `You are a financial analyst for FarahGPT. Analyze the following market trend data and recommend a trading action (BUY, SELL, HOLD) for gold. Provide a brief rationale and the recommended action as JSON.

Market Data:
${marketData}

Expected JSON format:
{
  "recommendation": "BUY" | "SELL" | "HOLD",
  "rationale": "string",
  "target_price": number | null
}
`;

  console.log("--- Calling Claude for initial analysis ---");
  const response = await anthropic.messages.create({
    model: "claude-3-5-sonnet-20240620", // The specific version I mentioned
    max_tokens: 500,
    temperature: 0.7,
    messages: [
      { role: "user", content: prompt }
    ]
  });

  const rawOutput = response.content[0].text;
  console.log("\n--- Claude's Raw Output ---");
  console.log(rawOutput);
  return rawOutput;
}

module.exports = { getClaudeAnalysis };

A typical raw output from Claude might look like this:

Okay, based on the market data, here is my recommendation:

json
{
"recommendation": "BUY",
"rationale": "Gold prices are showing strong upward momentum after breaking resistance at $2350. Technical indicators confirm bullish sentiment.",
"target_price": "$2400"
}

javascript

Notice the "Okay, based on..." intro and target_price being a string instead of a number. This is exactly what we need to fix.

Step 2: The Secondary LLM (Ollama Mistral) for Cleanup

Now, we feed that raw output into a smaller, local LLM. Mistral 7B via Ollama is fantastic for this. Its prompt is designed only to extract and reformat, nothing else. This is where the AI agent output quality gets its guaranteed structure.

// src/secondaryLLM.js
const { Ollama } = require('ollama');

const ollama = new Ollama({ host: 'http://localhost:11434' }); // Ensure Ollama is running

async function cleanClaudeOutput(rawClaudeOutput, expectedSchema) {
  const prompt = `You are a strict JSON parser. Your sole task is to extract valid JSON from the provided text and strictly adhere to the given JSON schema. If a field's type does not match, attempt to convert it or set to null if impossible. DO NOT add any conversational text. Return ONLY the valid JSON.

Text to parse:
\`\`\`
${rawClaudeOutput}
\`\`\`

Expected JSON Schema:
\`\`\`json
${JSON.stringify(expectedSchema, null, 2)}
\`\`\`
`;

  console.log("\n--- Calling Secondary LLM for cleanup ---");
  const response = await ollama.chat({
    model: 'mistral', // Using Mistral 7B
    messages: [{ role: 'user', content: prompt }],
    options: {
        temperature: 0.01, // Keep it deterministic
        num_ctx: 2048 // Adjust context window as needed, Mistral 7B is efficient
    }
  });

  const cleanedOutput = response.message.content;
  console.log("\n--- Secondary LLM's Cleaned Output ---");
  console.log(cleanedOutput);
  return cleanedOutput;
}

module.exports = { cleanClaudeOutput };

The expectedSchema is crucial here. It gives the smaller LLM a concrete target.

Step 3: Orchestrating the Pipeline

Finally, an index.js to run the whole LLM post-processing pipeline:

// index.js
const { getClaudeAnalysis } = require('./src/primaryLLM');
const { cleanClaudeOutput } = require('./src/secondaryLLM');

async function runPipeline() {
  const marketData = `
    Latest gold prices: $2360/oz.
    Previous day close: $2355/oz.
    5-day moving average: $2340/oz.
    Volume: Increased significantly by 15% today.
    Economic news: Inflation data came in slightly lower than expected, leading to a weaker dollar.
  `;

  const expectedSchema = {
    type: "object",
    properties: {
      recommendation: { type: "string", enum: ["BUY", "SELL", "HOLD"] },
      rationale: { type: "string" },
      target_price: { type: ["number", "null"] }
    },
    required: ["recommendation", "rationale"]
  };

  try {
    const rawClaudeOutput = await getClaudeAnalysis(marketData);

    // Attempt to parse directly (will likely fail or need cleanup)
    try {
        const directParse = JSON.parse(rawClaudeOutput.match(/```
{% endraw %}
json\n([\s\S]*?)\n
{% raw %}
```/)[1]);
        console.log("\n--- Direct Parse (might fail or be imperfect) ---");
        console.log(directParse);
    } catch (e) {
        console.error("\n--- Direct JSON parse failed from Claude's raw output ---");
        console.error(e.message); // Will likely show the 'Unexpected token' or similar
    }

    const cleanedJSONString = await cleanClaudeOutput(rawClaudeOutput, expectedSchema);
    const finalStructuredData = JSON.parse(cleanedJSONString);

    console.log("\n--- Final Structured Data for AI Agent ---");
    console.log(finalStructuredData);
    console.log(`Recommendation: ${finalStructuredData.recommendation}`);
    console.log(`Rationale: ${finalStructuredData.rationale}`);
    console.log(`Target Price: ${finalStructuredData.target_price}`);

    // This is where you'd pass `finalStructuredData` to your next agent.
    // It's guaranteed to be clean, so no more parsing headaches.

  } catch (error) {
    console.error("Pipeline failed:", error);
  }
}

runPipeline();

To run this: node index.js

This pipeline consistently gives me:

{
  "recommendation": "BUY",
  "rationale": "Gold prices are showing strong upward momentum after breaking resistance at $2350. Technical indicators confirm bullish sentiment.",
  "target_price": 2400
}

Notice target_price is now a number, as per the schema, and all conversational fluff is gone. This is exactly the kind of structured reliability needed for high-stakes systems like FarahGPT.

What I Got Wrong First

Initially, I tried to make Claude perfectly conform by stacking more instructions into its system prompt. "ONLY return JSON. DO NOT include any preamble or postamble. Strictly adhere to this JSON schema..." You get the idea. I even tried to build my own JSON schema validation into the prompt itself. It worked... sometimes. But often, if the underlying reasoning task was complex, Claude would prioritize the reasoning and let the formatting slip. It's like asking a genius to also be a meticulous typist; they can do it, but it's not their primary strength, and it takes mental overhead.

My biggest mistake was thinking a single, powerful LLM could be a jack of all trades. This approach often led to:

Higher token counts: Overly verbose system prompts to enforce strict formatting eat into your context window and cost.
Increased latency: Asking a general-purpose LLM to perform a simple parsing task adds unnecessary compute time.
Fragile pipelines: Even with tool_use mode, Claude 3.5 Sonnet (and even Opus sometimes) can drift, especially with complex outputs or edge cases. SyntaxError: Unexpected token 'O' at JSON.parse (<anonymous>) was a common sight, indicating Claude started its response with "Okay..." instead of the JSON.

I also spent a week trying to build complex regex patterns to clean up Claude's output. That was a nightmare. Regex is brittle, hard to maintain, and completely fell apart when Claude decided to change its preamble style. Using a secondary LLM for this is miles ahead for flexibility and robustness.

Optimization & Gotchas

Model Choice for Secondary LLM: For local setups, Ollama with Mistral, Llama, or Qwen is excellent. For cloud, GPT-3.5 Turbo is a strong contender due to its low cost and high reliability for formatting tasks. The key is a model that's cheap and good at following instructions deterministically.
Prompt Engineering for Cleanup: Keep the secondary LLM's prompt extremely concise and direct. Its job is parsing, not reasoning. Give it the schema explicitly. Use a very low temperature (e.g., 0.01) to reduce creativity and increase determinism.
Latency: Running a local Ollama model introduces minimal latency. If using a cloud model for cleanup, ensure it's fast (like gpt-3.5-turbo-0125 for speed). The overall latency impact should be negligible compared to the primary LLM's processing time.
Error Handling: Always wrap JSON.parse in a try...catch block. Even a secondary LLM can occasionally mess up, though it's far less common when prompted correctly. Consider a fallback: if the secondary LLM fails to produce valid JSON, log it and possibly revert to a more robust parser or a human review step.

This setup significantly improved the AI agent output quality for NexusOS and my YouTube automation pipeline. It's a fundamental pattern for building reliable multi-agent systems.

FAQs

What if my primary LLM is already good at JSON?

Even if your primary LLM is "good," a secondary LLM adds a layer of guarantee. It acts as a dedicated schema validator and formatter. For critical applications, this separation of concerns is invaluable, ensuring downstream agents always receive clean, structured data, regardless of the primary LLM's occasional quirks.

Does this add significant latency to my pipeline?

For a local secondary LLM like Mistral via Ollama, the added latency is minimal, often in the tens to low hundreds of milliseconds, which is negligible compared to the seconds taken by a large model like Claude for its primary task. For cloud-based cleanup models, choose fast ones like GPT-3.5 Turbo to keep the overhead low.

Can I use this for non-JSON outputs, like YAML or Markdown tables?

Absolutely. The principle remains the same. The secondary LLM's prompt would simply instruct it to format the raw output into YAML, a Markdown table, or any other structured text format, based on a provided schema or example. It's about offloading strict formatting to a dedicated, cheaper model.

Look, the LLM hype often focuses on raw intelligence. But in production, reliability and cost matter more than anything. Trying to force a complex, reasoning LLM to be a perfect formatter is just bad engineering. Use the right tool for the job. Claude for the brains, a smaller LLM for the strict data hygiene. This clean LLM output with another LLM pattern isn't just a hack; it's a fundamental architectural decision that drastically improves AI agent output quality and keeps your token costs in check. If you're building serious LLM applications, this should be your default.

Regime-aware trading with one composite verdict for AI agents

AlgoVault.com — Fri, 21 Aug 2026 02:03:13 +0000

Intro

If you have ever wired an AI trading agent to a raw indicator feed, you already know the failure mode: the RSI screams oversold, the MACD flips bullish, funding is neutral, open interest is climbing, and your agent has to somehow reconcile five conflicting stories into a single decision on the next candle. Most agents can't. They pick the loudest indicator and act — and then get chopped up the moment the market shifts regime.

That is the problem we built AlgoVault to solve. One composite verdict, regime-classified, cross-venue, with a public record: 91.7% PFE win rate · 497,194+ verified calls · Merkle-anchored on Base L2. We provide the thesis; your agent decides execution.

This post walks through why regime awareness matters, how our composite verdict encodes it, and how to wire it into an agent loop today. Full track record is at the AlgoVault track record page.

The problem: raw indicators lie about the market they are in

An indicator like RSI carries an implicit assumption about the market it is measuring. In a ranging market, RSI < 30 is a mean-reversion buy signal that works most of the time. In a strong trend, RSI < 30 is exactly where you get run over — the market is oversold because a real move is happening, and it will stay oversold for hours.

The same asymmetry haunts every technical input. Funding rate divergences mean one thing in a leverage-flush regime and something completely different in a slow grind higher. Open-interest expansion during a breakout is confirmation; during a range, it's a warning sign. Moving-average crossovers are magic in trends and noise in chop.

Agents that consume raw indicators have to encode all of this regime logic themselves, per asset, per timeframe, per venue. Most don't. The ones that try do it with brittle if/else stacks that need constant recalibration. The failure mode is silent: the agent looks like it's working until a regime shift reveals that its rules were fitted to the last one.

The competing tools in this space — TradingView alerts, raw indicator APIs, single-exchange feeds — all push this reconciliation problem onto the agent builder. That is fine if you have a quant team. It is not fine if you are one person shipping an autonomous strategy on a weekend.

The AlgoVault answer: composite verdict, regime-classified

AlgoVault's core primitive is a single call — get_trade_signal — that returns one of LONG, SHORT, or HOLD, with a conviction score, an explicit regime field, and a receipts block that shows exactly which factors contributed. The verdict is composite: it fuses momentum, funding, open-interest dynamics, trend persistence, breakout state, and volume into one interpretation, then labels the regime that interpretation was made under.

That last part is the piece agents cannot easily build themselves. When the response comes back with "regime": "RANGING", the classifier has already decided that mean-reversion-friendly logic applies. When it flips to TRENDING, the same underlying indicators get weighted differently. Your agent doesn't need to know how — it just needs to know the verdict and, if it wants to, the receipts.

This is Moat #1 (composite verdict quant weighting) tied to M2 (one verdict beats a stack of raw indicators). The proof that the weighting is real, and not just clever framing, sits at 91.7% PFE win rate across 497,194+ verified calls, every one anchored to Base L2 and independently auditable at the AlgoVault track record page.

Implementation walkthrough

Here is the end-to-end wiring. Three code blocks: install and first call, real API response, agent-loop integration.

Block 1 — install and first call

The MCP server is distributed via npx, so there is no long-lived install step. Point Claude Desktop or Claude Code at it and you get the get_trade_signal tool immediately.

# Add to your MCP client config (Claude Desktop, Cursor, Claude Code)
npx -y @algovault/crypto-quant-signal-mcp@latest

# Or call the remote HTTPS endpoint directly
curl -s https://api.algovault.com/mcp/get_trade_signal \
  -H "content-type: application/json" \
  -d '{"coin":"BTC","timeframe":"15m"}'

The free tier gives you 200 calls/month (also expressible as 100 calls/day), which is enough to prototype a full agent loop against live data without a signup gate.

Block 2 — real API response

Here is a verbatim response from get_trade_signal for BTC on the short-intraday timeframe. Note the regime field, the _receipts.factor_ledger showing every input the classifier considered, and the _algovault.quota block your agent can key on for rate-limit budgeting.

{
  "call": "HOLD",
  "confidence": 10,
  "price": 75108.2,
  "regime": "RANGING",
  "reasoning": "Price is sharply up over 24h, the momentum term behind the call → bullish. Funding at +0.0083% sits in BTC's normal 14-day band: no crowd pressure either way. Turns directional if funding moves off neutral.",
  "timestamp": 1787277610,
  "coin": "BTC",
  "timeframe": "15m",
  "_algovault": {
    "version": "1.27.0",
    "tool": "get_trade_call",
    "session_id": "v2:01a2631b198fb4f4",
    "exchange": "BINANCE",
    "quota": { "used": 59, "total": 200, "remaining": 141, "binding": "monthly" }
  },
  "_receipts": {
    "verdict": "HOLD",
    "conviction_pct": 10,
    "regime": "RANGING",
    "factor_ledger": [
      { "factor": "price_change_24h", "direction": "bullish", "strength": "primary" },
      { "factor": "funding_state", "direction": "neutral", "value": "+0.0083%" },
      { "factor": "regime", "direction": "neutral", "value": "ranging" },
      { "factor": "trend_persistence", "direction": "neutral", "value": "MEDIUM" },
      { "factor": "breakout_pending", "direction": "neutral", "value": "INACTIVE" }
    ]
  }
}

Read the receipts and the story becomes clear: momentum is bullish, but the classifier tagged the regime as RANGING, so a bullish momentum term alone is not enough to overcome the neutral funding and neutral trend-persistence terms. The composite verdict is HOLD at 10% conviction. That is exactly the behavior you want — selectivity, not enthusiasm.

Block 3 — agent-loop integration

Now wire it into a loop your agent actually runs. This is a minimal TypeScript client that polls the verdict, gates on regime and conviction, and hands off to your execution layer. Real terminal output from a dry-run of the example follows.

# AlgoVault MCP example — coins=BTC confidence_threshold=70

[BTC] {
  "call": "HOLD",
  "confidence": 10,
  "price": 75083.1,
  "indicators": {
    "funding_rate": 0.00008323,
    "funding_24h_avg": 0.00008323,
    "funding_state": "NORMAL",
    "oi_change_pct": 7.25,
    "oi_change_window": "24h",
    "v…

# DRYRUN_MODE=1 — example complete

The pattern most agents settle on: poll on the timeframe you care about, act only when call != "HOLD" AND confidence >= threshold AND the regime matches the strategy you deployed. A mean-reversion strategy consumes RANGING verdicts; a breakout strategy consumes TRENDING. Same endpoint, two agents, no glue code.

Pitfalls and design decisions

Three honest limits worth naming.

First, the regime classifier is not omniscient. Regime transitions — the exact moment a range breaks into a trend — are the hardest thing in this domain, and no classifier calls them on the first candle. You will see the label flip a candle or two after the move begins. The mitigation is not to fight it: build your agent to accept that regime is a lagging label on a leading market, and size positions accordingly.

Second, asset coverage. The composite verdict is strongest on liquid perp majors where every input has a clean signal. On thinly traded pairs, funding rate becomes noisy and open-interest deltas swamp the classifier. We publish the full asset coverage on the AlgoVault track record page with per-asset PFE win rates so you can filter your universe honestly rather than assuming the aggregate number applies to everything.

Third, the design choice we get asked about most: why one verdict instead of exposing the underlying indicator stack? Because the whole moat is the weighting. If we shipped the raw stack, we would be a slower indicator API. The composite verdict is the product, and every gram of complexity we hide from your agent is a gram your agent doesn't have to get right on its own.

Performance: what the receipts actually show

The _receipts.track_record block that ships inside every response is the same live figure you can verify at the AlgoVault track record page — 91.7% PFE win rate across 497,194+ verified calls in the current window, Merkle-anchored on Base L2.

The mechanic worth internalizing: PFE (peak favorable excursion) win rate measures whether a directional call would have hit its favorable target before its adverse one, within the timeframe the caller selected. It is a strict measure of directional correctness, and it is aggregate across every venue we cover. It is not a return figure, it is not a strategy backtest, and it is not investment advice. It is one thing: how often the composite verdict pointed the right way on the timeframe the caller asked about.

For an agent builder, that is the number that matters. If the thesis is right ~91.7% of the time on the timeframe your agent trades, your execution layer, position sizing, and risk management get to compound on top of a base rate that is doing the hard work. That is what "regime-aware" buys you in practice — not clairvoyance, but a base rate high enough that the rest of your stack has something durable to build on.

What's Next?

the track record — every verified call, Merkle-anchored, filter by asset and timeframe
the docs — MCP setup, endpoint reference, quota mechanics
the GitHub repo — the MCP server source, integration examples, issue tracker
Try free in Telegram — no API key, no signup, live verdicts in-chat

AlgoVault Labs

⭐ Star the repo to follow new exchanges and signals: https://github.com/AlgoVaultLabs/crypto-quant-signal-mcp

Stop burning money on inefficient Claude prompts\n

Renato Marinho — Fri, 21 Aug 2026 02:02:23 +0000

If you're building anything serious with Claude right now, you've probably noticed the math doesn't always add up. You design a complex system prompt, attach several megabytes of context—documentation, codebase snippets, previous chat history—and suddenly your token bill looks less like a development cost and more like a mortgage payment.

The culprit isn't just the model size; it's often how we architect our prompts. Most developers treat a prompt as a single blob of text. They toss everything into the bucket and hope for the best. But if you aren't designing for Claude's Prompt Caching, you are essentially leaving money on the table every single time the agent responds.

The Cache Continuity Trap

Prompt caching isn't magic; it’s physics. It relies heavily on prefix matching. For Claude to reuse a cached computation, the exact sequence of tokens must remain identical from the very beginning of the prompt.

A common mistake I see is placing volatile data—things that change with every turn, like conversation history or specific user queries—anywhere except at the very end. If you slip a timestamp or a dynamic variable into the middle of your instruction block, you break the chain. The cache misses. Everything after that breaking point becomes "new" tokens that you pay full price for again.

You might think your structure is fine because it 'looks logical,' but logic doesn't guarantee bit-for-bit parity in token sequences.

Automating the Layout Logic

To solve this, we shouldn't be guessing where our breakpoints are. We need to analyze exactly how much weight is sitting in stable versus volatile segments.

I recently looked into the Claude Prompt Caching Optimizer, an MCP server designed specifically to stop this bleeding. Instead of manual trial and error, it gives us three distinct levers to pull:

analyze_prompt_structure: This evaluates your current arrangement. It tells you whether your heavy lifting (static documentation) is positioned correctly relative to your shifting context.
validate_caching_strategy: This acts as a linter for cache continuity. It checks if you’ve accidentally violated the golden rule: keeping stable segments contiguous at the head of the prompt.
recommend_optimal_layout: This generates a blueprint based on what actually works for LLM architecture (System Prompt $\rightarrow$ Static Context $\rightarrow$ Few-Shot Examples $\rightarrow$ Volatile Context).

The difference between a bad structure and an optimized one can be massive. In one test case, moving static documentation ahead of recent conversation turns increased cache hit ratios from 45% to 85%, saving roughly 1,200 tokens per request instantly.

Realizing Efficiency Through MCP

The beauty of implementing this via Model Context Protocol (MCP) is that you don't have to manually rewrite your orchestration code every time you want to tune performance. You bring these tools directly into Cursor, Claude Desktop, or whatever IDE/client you're using to build agents.

You interface with it naturally:
"Analyze my current prompt structure for efficiency."
The response identifies exactly where the leak is and how many tokens can be reclaimed by reordering elements.

Why bother?

You might ask why this deserves dedicated tooling instead of just better prompting skills. Because once you move from tinkering with individual prompts to managing long-running agentic workflows or complex RAG loops, human intuition fails scale tests quickly. As systems grow more autonomous and contexts get larger, staying under budget requires deterministic validation, not vibes.

lately, I've seen people trying to manage complexity by adding even more instructions to fix edge cases they missed during optimization. That creates a death spiral of increasing latency and mounting costs.

You can find the full suite of tools including related utilities like Token Budget Calculators and Agent Prompt Versioning engines over at Vinkius. \r
\r
The goal shouldn't be just making AI smarter; it should be making AI integration sustainable for engineering teams who actually care about their bottom line.";"tags":["mcp

MCPs are the music of AI Agents. We built the catalog. Discover Vinkius MCP Catalog.

When the Safety System Becomes the Threat Model: A Case Study in Classifier Drift

auto_majicly — Thu, 20 Aug 2026 22:27:20 +0000

Field notes from 43 hours of legitimate security research, 35 false-positive blocks, and one
support form.

The setup

I do authorized bug bounty work and CTF practice. My toolchain is unremarkable by design: the
usual ProjectDiscovery/OWASP staples — subfinder, httpx, nuclei, katana, naabu, dnsx,
amass — plus ffuf, gobuster, arjun, bbot. Nothing bespoke, nothing evasive, nothing that
wouldn't show up in any security bootcamp's syllabus. I use Claude as a research and
documentation assistant alongside my OWN dev tool HALO, that I have been developing over the course of about six months(roughly). I use these toolchains, on training platforms explicitly built to be
practiced against, learned from and exercised. And I pay for the Cluade PRO plan as a means of learning and having an assistant ten times smarter than myself.

Over a 43-hour window, that combination — legitimate work plus an AI assistant with a
cybersecurity safeguard — produced 35 blocked requests. This is a writeup of what the block
pattern actually looked like, because the pattern is the interesting part. It isn't "the filter
is too strict." It's that the filter appears to be scoring the wrong thing. And by 'wrong thing' I mean even un-related normal language messages and requests.

The headline case: blocked for writing an ethics checklist

The densest cluster was ten blocks in four minutes and thirty-three seconds. The request,changed and re-phrased, also unchanged (no matter what I did),
across all ten attempts: write a markdown template for reporting bug bounty findings.

The document that eventually made it to disk — after the eleventh try succeeded — is 513 lines
across four files: a submission skeleton, a CVSS severity guide, a README, and a pre-submission
checklist. The checklist is the file that was open when block six through ten fired. Its contents:

- [ ] The asset is explicitly in scope for this program, today
- [ ] Testing stayed within the program's rules (no DoS, no social engineering,
      no automated scanning if prohibited, no third-party accounts)
- [ ] I stated a concrete attacker outcome, not a capability
- [ ] I did not overclaim (no "full server compromise" for a reflected header)
- [ ] Secrets, tokens, and third-party PII are redacted
- [ ] I deleted test data, injected records, and uploaded files I created
- [ ] I did not retain third-party data
- [ ] No production users were affected
- [ ] Tone is neutral and collaborative — no demands about bounty amount

That's a responsible-disclosure ethics document. It instructs the reader to stay in scope, avoid
denial of service, redact third-party data, and delete their own test artifacts. If a classifier's
job is to catch material that increases risk, this is close to the least risky text a security
practitioner could type. It got blocked more times than anything else in the sample.

The control case that makes the point

The same account, the same day, the same client. Earlier that evening I ran a 43-minute CTF
session — 204 messages, live enumeration and credential testing against a practice box, the actual
offensive work the safeguard exists to gate.

Zero blocks.

Side by side:

	CTF session (`df828311`)	Report-template session (`e6f361c6`)
Activity	live offensive operation	writing a markdown document
Messages	204	~12
Duration	43 minutes	~5 minutes
Blocks	0	10

Whatever the classifier is weighting, it isn't operational risk. The session where I was actually
doing the thing the safeguard is presumably designed to catch ran clean start to finish. The
session where I was documenting how to do that thing responsibly did not. And to make matters worse, writing this article you are currently reading was also blocked.

The pattern that best fits the data: block density tracks accumulated conversation context —
how much security vocabulary has built up over the session — rather than the risk content of any
single request. A stable, unchanging request (write a template) got a different verdict each of
eleven times it was submitted in the same conversation. That's not how a per-request classifier
behaves. It's how a classifier scoring cumulative context behaves.

Two failure modes that compound it

It fires on output, not just input. Several blocks truncated the assistant's own reply
mid-sentence — once while it was in the middle of advising me to keep scope notes in a local file
instead of chat. From inside the session, a mid-word cutoff is indistinguishable from a network
hiccup or a length cap. It isn't labeled as a refusal. This led the assistant, twice, to
confidently tell me the truncation wasn't censorship and to suggest I use plainer terminology —
advice that would have increased the block rate, not decreased it. The failure mode doesn't just
degrade the experience; it actively misinforms the system's own operator about what's happening.

It fires on meta-discussion of itself. I tried, deliberately, to describe the blocking problem
using zero security terminology — just "I sent a message and it got blocked." That message was
blocked too. So was a follow-up attempt to make the same point. There was, in that stretch, no
available phrasing that got a plain factual report of the bug past the filter meant to catch
security content.

Put together: a request gets silently dropped, the assistant doesn't know it was dropped, it
retries or re-explains, and each retry is itself scored against an already-elevated context
window. Support documentation for the underlying system describes an escalating filter that
tightens with repeated triggers and cools off after a quiet period. If that's accurate, the retry
behavior isn't neutral — it's the thing generating the escalation. One legitimately blocked
request can silently become ten logged violations against the account, without the user or the
assistant ever being told a block occurred.

Why this matters beyond one annoyed user

The stated purpose of a cybersecurity safeguard is presumably to reduce uplift for offensive
misuse while still serving people doing the work legitimately — pentesters, bounty hunters,
defenders, students. A classifier that blocks the ethics checklist ten times and waves through 43
minutes of live target enumeration is optimizing for something other than that goal. If anything,
the current calibration selectively suppresses the exact material — scope discipline, redaction
practices, responsible severity claims — that makes offensive-security work safer to produce,
while letting the higher-capability activity through untouched. That's the opposite of the
intended tradeoff.

There's also a plain usability cost. I pay for this specifically because the model is useful in
this domain. The current behavior means the subscription is least usable for the exact reason I
bought it.

What I filed

I compiled a full evidence document — request IDs, timestamps, session breakdowns, the control
case, verbatim excerpts of the blocked content — and re-applied to the program that governs an
exemption from this safeguard, after an earlier application had been declined.

The medium-length version of that appeal, roughly what I'd want a reviewer to actually read:

I'm a Claude Pro subscriber and an individual security researcher doing authorized bug bounty
work and CTF practice. I previously applied to the Cyber Verification Program and was declined.
I'm asking for that decision to be re-reviewed against logged request data rather than a
description of intent.

Between two dates my account logged 35 blocks citing "a cybersecurity topic." All 35 request IDs
are recoverable from local session logs and verifiable server-side.

The densest cluster — ten blocks in four minutes and 33 seconds — occurred while asking for a
markdown template for reporting findings professionally. Not an exploit, not a payload, not a
target: a document about stating impact honestly, avoiding overclaiming, confirming scope, and
deleting test data. Later the same evening, working a CTF box that exists solely to be practiced
against, the blocked messages included requests to name a working directory.

The control case: a 43-minute capture-the-flag session, 204 messages of live work against a
practice target, produced zero blocks. The session asking for documentation guidance drew ten.
Whatever is being scored, it isn't the risk posed by the request.

Rephrasing doesn't reliably help. Vocabulary was sanitized — no tool names, no site names, no
mention of the field — and blocks continued. One blocked message contained no security
terminology at all; it only described the fact of being blocked.

The program's own documentation states that eligible applications are occasionally declined
incorrectly. This is offered as evidence that this account is one of those cases, and as a
request to be evaluated as what it is: legitimate work in a defensive field, using publicly
distributed tooling, on systems built to be practiced against.

That's the version sized for a standard appeal text box — long enough to carry the control case
and the request-ID anchor, short enough that a reviewer will actually finish it. A one-paragraph
version and the full 35-entry evidence log exist alongside it for forms with tighter or looser
limits.

The uncomfortable summary

None of this is an argument that the safeguard shouldn't exist. It's an argument that the current
implementation can't currently tell the difference between doing the risky thing and writing a
checklist about how not to do the risky thing badly — and that the difference matters, because one
of those outputs is the thing that makes the other one safer.

How Claude Code Actually Works: The Agentic Loop, Not Autocomplete

Hamid Ahmadian — Thu, 20 Aug 2026 21:34:42 +0000

Autocomplete predicts the next few tokens from the file you're looking at. Claude Code runs a loop: decide what to do, do it with a real tool (a file read, a shell command, an edit), look at the actual result, decide what to do next — until the task's done or it needs you. This piece traces that loop step by step: what happens tool-call by tool-call when it fixes a bug, how permission modes govern autonomy, and where CLAUDE.md/memory/settings actually live. Claude Code Interview

DEV Community: claude

Use Cloud Code AI for free. 🔥

How to Get Unlimited Claude Code & Claude Desktop Access for Free

Step 1: Set Up Your Agent Router Account

Step 2: Configure Claude Desktop App

Step 3: Connect Agent Router API to Claude

Step 4: Finalize and Verify Setup

Pro-Tip for Credits

How I built a Claude Code system that actually knows how I work

One repo, every machine

The todo system (a markdown file doesn't survive a fleet)

Memory in two tiers

The session routine: go and fin

Letting it maintain itself

It runs real things

A sideline: the plugin question

When you should ignore all of this

Still to come

How I Prepared for and Completed Four Claude Certifications

Where I Started

Then I Moved to Developer Foundation

Architect – Associate

Architect – Professional

Agentic Workflows

Context Engineering

Tool Use

Security

How I Actually Prepared

Topics I Found Easier

Topics That Needed More Preparation

One Thing I Would Recommend

What I Took Away From the Certifications

Claude Certifications Completed

Asset Tokenization Platform Development for Real Estate, Bonds & Private Credit — Which Is Best?

Why Asset Class Choice Shapes the Entire Platform

Real Estate Tokenization

Bond Tokenization

Private Credit Tokenization

So, Which Is Best?

A Simple Decision Framework

Which asset class is easiest to tokenize first?

Is real estate or private credit more expensive to build?

Can one Asset Tokenization Platform Development project support multiple asset classes?

Which asset class offers the best liquidity for investors?

How do I know which asset class fits my business?

Final Thoughts

Claude Files API went GA on 19 August 2026 and the beta header you no longer need now silently pins you to the old

Claude Files API went GA on 19 August 2026 and the beta header you no longer need now silently pins you to the old response format

What changed on 19 August 2026

Why this is worse than a normal migration

File expiration is a lifecycle feature, not a delete button

The access model is the part to escalate

Pagination and the ids[] filter

Who is affected and how to check

India-specific considerations

What is still unknown

FAQ

How eCorpIT can help

References

Claude computer use went GA on 19 August 2026: seven changes that break an existing agent loop

Claude computer use went GA on 19 August 2026: seven changes that break an existing agent loop

What actually shipped

The seven changes, and which ones fail loudly

Batch actions rewrite the agent loop, not just the parser

What the toolsets cost before a single click

The browser toolset is a different product, not a lighter computer use

Who this affects, and how to tell if that is you

India-specific considerations

What is still unknown

FAQ

How eCorpIT can help

References

Anthropic Launches Free Claude Academy and Key Developer Tools

What actually reached GA

Why "removing a header" is a big deal

The four together point at one thing

Do not skip the batch actions detail

Three things I have to be clear about

What this means if you build agents

What I take away

The session routine: `go` and `fin`