Cloudflare has announced an open source tool that takes an API definition and automatically produces the SDKs, command-line tools, documentation, and other interfaces used to interact with it.

Forge, as it’s called, is available under an Apache 2.0 license, and can be run and modified privately without paying Cloudflare a dime. In a blog post published on Monday by Dimitri Mitropoulos, Matt Taylor, and Samuel MacLeod, Cloudflare notes that the project is still early: it already generates the output required for Cloudflare’s cf CLI, its unified command-line interface for working across the Cloudflare platform, with the company’s API documentation and SDKs due to move over in the coming months.

“We believe that building tools for APIs is a core part of the Internet, and you should be able to do that without needing a SaaS product.”

“We believe that building tools for APIs is a core part of the Internet, and you should be able to do that without needing a SaaS product,” the authors write.

When your SDK generator disappears

Cloudflare’s announcement comes just 11 days after Google made a somewhat similar move, revealing it had partnered with API tooling company Speakeasy to open-source the latter’s OpenAPI code-generation suite under an AGPLv3 license.

In a blog post published September 17, Google said its decision was prompted by the sudden loss of its SDK-generation service, after the provider was acquired and “abruptly announced its shutdown.” This happened just as Google was preparing to launch a new API.

“This sudden disruption highlighted that proprietary, closed-source generators create unacceptable platform risk.”

“This sudden disruption highlighted that proprietary, closed-source generators create unacceptable platform risk,” the company wrote. “If the industry relies on OpenAPI to define interfaces, the tooling to compile those interfaces into client libraries, CLIs, and agent tools should be open infrastructure.”

The provider Google was referring to was Stainless. Anthropic acquired the SDK and MCP tooling company on May 18, after which Stainless said it would wind down its products, including the SDK generator used to keep client libraries updated as APIs changed.

As The New Stack reported at the time, the closure affected a swathe of customers including OpenAI, Google and Cloudflare. While those companies retained the SDKs Stainless had already generated for them, they lost the shared service they had relied on to regenerate and update those SDKs as their APIs evolved.

Cloudflare, for its part, had already begun building some of the machinery that would become Forge. In April, the company released a technical preview of cf, a new unified command-line interface intended to eventually expose Cloudflare’s products through a consistent set of commands for developers and AI agents. At the time, Cloudflare said it had created a new TypeScript-based schema and generation system to keep CLI commands, configuration, bindings and other interfaces in sync with its API.

That earlier preview was limited — cf initially covered only a small subset of Cloudflare products — although the company said it was already testing a version spanning its entire API surface. Forge is the code-generation system that has emerged from that work and now generates the output required by cf.

Tools such as Forge save API providers from having to maintain each SDK, CLI command set and documentation surface separately by hand. When the underlying API changes, the same definition can be used to produce updated SDKs, CLI commands and documentation for the developers — or agents — consuming it.

Why Cloudflare built its own generator

While Stainless was one of the hosted generation products Cloudflare had relied on in production, Cloudflare doesn’t name it specifically, instead spelling out why Cloudflare had become dissatisfied with the broader category of hosted generators.

Part of the problem is sheer volume: Cloudflare says it now has more than 3,500 API operations, backed by hundreds of services maintained by different engineering teams. A generator therefore has to keep changes across that sprawling API estate accurately reflected in the tools customers use, without turning every update into a coordination exercise across the company.

Cloudflare also wanted engineers to see what an API change would do to the resulting SDK, CLI and documentation before the underlying code was merged. Moreover, it wanted the same system to reach beyond conventional SDKs into things such as MCP servers and Cap’n Web bindings, which allow applications to invoke remote services through Cloudflare’s TypeScript-based RPC system in much the same way they would call local functions.

That had proved difficult with external services. Cloudflare says problems introduced in one part of its API could surface only when another team later tried to release something, leaving engineers to trace the failure back through systems they did not fully control and then coordinate a fix across company and vendor boundaries.

“We’ve tried several hosted products that attempt to solve this, and relied on some in production,” the authors write. “None of them solved this problem for us, and some have shut down entirely.”

The open-source factor

And so the Stainless wind-down goes some way toward explaining why Cloudflare is making Forge open source. Stainless’s generator was proprietary and delivered as a hosted service, leaving customers dependent on the company continuing to operate it. Forge’s permissive Apache 2.0 license means developers can run it on their own infrastructure, modify it, or fork the project and continue using it independently of Cloudflare.

AI agents raise the stakes further, because they increasingly rely on SDKs, CLIs and API bindings to understand what software can do and how to interact with it. If those interfaces lag behind the underlying service, the agent may be working from an incomplete or outdated description of its capabilities.

That is the concern Cloudflare CTO Dane Knecht highlights when explaining why keeping those interfaces current matters more than ever today.

“APIs have always been how software connects, but AI agents make the quality of SDKs, CLIs, and API bindings even more important,” Knecht tells The New Stack over email. “If that layer is stale or incomplete, an agent doesn’t just have a worse developer experience, it can misunderstand what a service can do.”

Ultimately, Cloudflare created Forge because SDK and CLI generation has “become too important” to sit outside its internal development process.

“Cloudflare needed a pipeline our teams could run, test, and extend themselves, and we think other developers should have access to that same kind of open, vendor independent foundation,” Knecht says.

Forge still has plenty to prove, of course. The project is early, cf is its first production output, and Cloudflare says its API documentation and existing SDKs will move over during the coming months. Several of the input formats and generated targets it discusses are also future work.

But the timing is quite revealing. Within 11 days, Google and Cloudflare — both former Stainless customers — have publicly thrown their heft behind open source SDK-generation infrastructure after the disappearance of the proprietary service they had relied on. Google describes that dependency as an “unacceptable platform risk.” Cloudflare, with Forge, is now trying to remove the same risk from its own stack.

The post Anthropic bought Stainless and shuttered its SDK generator. Cloudflare open-sourced Forge instead. appeared first on The New Stack.

Amazon started blocking Meta’s Muse from browsing and buying on Amazon.com on Sunday, roughly two weeks after the personal agent launched on September 8. Shoppers who ask Muse to buy something there now get a pop-up telling them that continued access by an unauthorized AI agent violates Amazon’s Conditions of Use.

Amazon’s objections have little to do with shopping itself. Meta never told Amazon that Muse would visit the store, the agent does not identify itself while it browses, and it appears to capture and store customer credentials. Those three properties describe almost every personal agent shipping this year. Grok Bot from xAI also drives signed-in browser sessions, and so does the open-source OpenClaw project that Muse is modeled on. The block is a category design problem rather than a disagreement between two companies.

What Amazon actually blocked

Muse runs on a dedicated virtual machine that Meta calls Muse Secure VM, and it reaches services in two ways: It uses built-in connectors for partners such as Gmail and OpenTable, and it drives an ordinary browser session for everything else. Shopping on Amazon.com used the second path.

That second path is what Amazon objects to. From the server’s side, a browser-driving agent looks like a signed-in customer with unusually fast reflexes, moving through search, product pages, account history, and checkout without ever declaring what it is. Amazon told GeekWire it asked Meta to exclude the store voluntarily, but Meta did not agree before the block went live.

The credential dispute is harder to settle from outside. Meta says Muse has no visibility into passwords or payment methods and that credentials sit in secure storage, while Amazon says the agent appears to capture and retain them. Both statements may be sincere, and the merchant can verify neither, since an unannounced session provides no evidence of which software holds the password.

The legal ground shifted seven weeks ago

Amazon reached for its Conditions of Use rather than the Computer Fraud and Abuse Act. Those terms, updated August 14, now require agents to identify themselves in user-agent strings and stop when asked. The likely reason sits in a ruling from early August. The Ninth Circuit vacated the preliminary injunction Amazon had won against Perplexity, and the panel held that a user directing the Comet assistant is the party accessing Amazon’s computers. Writing for the court, Judge Milan Smith described the assistant as a tool, not a person, for statutory purposes.

If you’re operating a public API or storefront, the ruling makes lawsuits a weaker tool for keeping agents out. Blocking them in your own infrastructure is now the more reliable option. A site cannot easily argue that an agent trespassed, so it has to decide for itself which automated clients it admits, publish that decision, and enforce it in its own infrastructure. Amazon’s pop-up is that enforcement, written in product rather than in a filing.

The identity layer already exists

Platform teams have solved a version of this problem before. Inside a service mesh, no workload is trusted by default because it looks like a normal client, and every call carries a verifiable identity that the receiving service checks before applying policy. Agent traffic on the public web faces the same requirement, and the specification is further along than most teams realize.

An IETF draft called Web Bot Auth builds on HTTP Message Signatures (RFC 9421). An agent signs its requests with a private key and publishes the matching public key at a well-known directory on its own domain. The verifier reads the Signature-Agent header, fetches the key set, and learns which operator is calling. Cloudflare validates these signatures at its edge for verified bots and agents. AWS WAF Bot Control added the same support for CloudFront distributions in November 2025.

The limits matter as much as the mechanism. A signature identifies the operator behind the agent, not the person it is acting for. The merchant learns that a request came from a named vendor, without learning whose account is in use or what the shopper approved. Amazon’s complaint about stored credentials sits in that gap. Signed identity settles the disclosure question and leaves authorization open.

Shopify took the other route within a day

While Amazon was blocking Muse, Shopify was wiring it in. On September 21, the two companies announced agentic checkout with Shop Pay across Shopify stores, extending the arrangement that made Meta an AI channel in Shopify Catalog on the day Muse launched. Muse reads structured product data and completes payment through a declared path, so the merchant knows an agent is transacting, and each purchase draws a single-use credential, so the card number never reaches Muse.

The plumbing for that path is public. Google and Shopify’s Universal Commerce Protocol covers discovery, cart, and checkout. The Agentic Commerce Protocol from OpenAI and Stripe covers checkout execution while the merchant stays the system of record. Google’s Agent Payments Protocol, donated to the FIDO Alliance in April, includes proof of the shopper’s authorization. A merchant that adopts it gets identity, scope, and an audit trail in the same transaction, which is what Amazon says it wanted and did not get.

Both routes follow from the business underneath them. Amazon runs its own storefront, recommendations, and assistant, so an outside agent that hides its identity takes the customer relationship and gives nothing measurable in return. Shopify sells infrastructure to merchants, so every new agent channel that reads its catalog and settles through Shop Pay reinforces the rails underneath. The key difference is who owns the demand surface, which explains why the same agent got a block from one company and a partnership from the other in the same 24 hours.

Choosing how to handle agent traffic

Most teams exposing an API or a storefront now have to make this call deliberately rather than by default. The decision depends on how much the business relies on the customer relationship at the point of contact and whether an agent can be identified when the customer arrives.

Scenario	Recommended option	Rationale
Public content and catalog data, no account access	Verify signatures at the edge and allow named agents	Web Bot Auth is checked by default on Cloudflare and AWS WAF, so the cost is policy configuration rather than engineering, though it tells you the operator and not the shopper
Agent transactions where you want the revenue	Publish a declared channel using ACP, UCP, or an MCP server	Structured access gives scope and an audit trail, at the cost of building and maintaining a second interface alongside the site
Account access with stored credentials	Require a scoped token, never a replayed password	Delegated tokens can be revoked per agent, though few consumer agents support them yet, which pushes the burden back onto your login flow
Competitive surfaces you intend to keep	State the rule in terms of service and enforce it at the edge	Legally durable after the Ninth Circuit ruling, though it invites the same public standoff Amazon is now in

Most real deployments will combine these rows rather than pick one. A retailer can verify signed agents on product pages, route purchases through a declared checkout, and still refuse an unannounced browser session inside a logged-in account. That combination is closer to Amazon’s position than its pop-up suggests.

What platform teams should do this quarter

Enterprise buyers and the teams running these systems face the same three questions, in a specific order.

Decide what an unidentified agent may do

The first question to settle is admission, and most sites have not settled it. They treat agent traffic as either a scraper to block or a browser to serve, and neither answer survives contact with a customer who wants an agent to act for them. Write policies for public pages, logged-in pages, and checkout separately, then publish them where an agent vendor can find them.

Give identified agents somewhere better to go

The second question is substitution, and it decides whether the first one holds. Blocking a browser-driving agent without offering a structured path leaves the demand intact and pushes it toward workarounds. Sabre reported that nearly 80 of its customers now pilot or run its MCP server for booking rather than let agents work through a booking screen. A catalog feed, an MCP server, or an ACP endpoint converts hostile traffic into a channel you can meter.

Fix credential handling before agents force it

The third question is authorization, and Amazon raised it loudest. An agent replaying a stored password is indistinguishable from credential stuffing at the network layer, regardless of any goodwill between the two companies. Scoped, revocable tokens tied to a named agent and a spending limit are the only version a risk owner can approve.

Where agent access is headed

Amazon and Meta will settle this commercially, because Amazon has an advertising arrangement that lets Facebook and Instagram users shop its products, and Meta buys compute from AWS, and neither gains from a long standoff over one shopping flow. The precedent is already set regardless of how they settle. Every site that matters to an agent now has to answer whether it admits anonymous automation, and it will enforce that answer through bot management rules and protocol endpoints rather than cease-and-desist letters.

Agent builders should read the block as an argument for declaring themselves. An agent that signs its requests, identifies its operator, and transacts via a published protocol can be allowed, rate-limited, and billed, while one that arrives disguised as a browser will keep encountering pop-ups. For developers building the services these agents reach, the signed identity layer arriving through Cloudflare, AWS, and the commerce protocols is the most useful infrastructure the open web has gained in years. It is worth adopting before the next agent shows up unannounced.

The post Amazon blocked Meta’s Muse. Then Shopify wired it into every store. appeared first on The New Stack.

Anthropic moved the Files API and computer-use toolset out of beta on August 19 and launched a browser-use toolset. It lets developers upload a document once and reference it by ID in subsequent requests, rather than sending its contents each time. The common alternative is what most developers do today: pasting the reference material into every prompt.

I wanted to measure how uploading a file once compares to pasting the document into each request, in terms of tokens, accuracy, and setup. I built a test with a verifiable answer key and ran the same workload through both, plus a third approach, prompt caching, that came out of the results.

The test

I wrote a fake API reference for an invoicing company called Ledgerline, about 1,200 words covering authentication, rate limits, idempotency, webhooks, bulk endpoints, and a sandbox. The scenario is a developer support bot that answers questions using only the Ledgerline API reference. Then I wrote five developer questions that the document can answer:

• How to tell apart two different 403 errors, and the fix for each
• How to safely retry payment creation after a timeout
• How to verify webhook signatures and block replay attacks
• The right way to create 2,000 invoices in one night
• What to do after committing a secret API token to a public repo

Each question has a specific correct answer in the reference, including details that are easy to miss. One fix depends on knowing that token scopes can’t be edited after creation. Another requires a separate rate limit for the bulk endpoint.

I ran the same five questions three ways, in Python scripts against the API directly, on claude-sonnet-5 with identical instructions:

• Arm 1 pasted the full reference into every request
• Arm 2 uploaded the reference once through the Files API and referenced its file ID in every request
• Arm 3 pasted the reference once into the system prompt with prompt caching enabled

The API reports token usage on every response, so each arm produced its own count.

Getting it running

Two things broke before the first run. The scripts originally set temperature to zero for reproducibility, and the API rejected it. Temperature is deprecated on claude-sonnet-5. Second, one response led with a thinking block instead of text, which caused my printing code to crash. Both fixes were one-liners.

The Files API upload itself was uneventful. One call, one file ID back, and the ID worked in every following request.

The results

All fifteen answers were correct against the answer key, across all three arms. Every arm caught the subtle details, the uneditable token scopes, the separate bulk rate limit, the constant-time signature comparison, the five-minute replay window. Whatever else changed between arms, answer quality did not.

Whatever else changed between arms, answer quality did not.

While the answer quality remained consistent, the token counts didn’t.

Tests	Regular input tokens	Cache write	Cache read	Output
Arm 1, paste every time	15,246	0	0	1,399
Arm 2, Files API	15,371	0	0	1,434
Arm 3, prompt caching	271	2,990	11,960	1,642

Arm 2 billed slightly more input than Arm 1, which was interesting. The marketing doesn’t say this, but I thought using the files from one API might require slightly fewer tokens. The uploaded file’s contents are still processed into every request, at roughly 3,050 input tokens per question either way, and referencing the file added a small amount of overhead on top, about 25 tokens per request. Across five requests, upload-once cost 125 more input tokens than pasting. There is no volume at which that flips.

Arm 3 is the one that behaved as I assumed the Files API would. The document was billed in full once, as a 2,990-token cache write on the first request. The four requests after that read it from cache, and cache reads bill at about one-tenth the rate of normal input tokens. The questions themselves cost between 48 and 63 regular input tokens each. Cache writes carry a 25 percent premium over normal input, so the first request is the most expensive, and subsequent requests are where the reduction occurs.

Two caveats on the caching numbers. The cache expires after five minutes of inactivity, so the reduction assumes requests keep coming in steadily. And caching required restructuring the request, moving the document into the system prompt with a cache marker.

When to use each approach

The interesting result is that the two features solve different problems. The Files API manages documents. Prompt caching lowers costs.

Files API

Use the Files API when the problem is the file itself. It gives you one uploaded copy referenced by ID instead of the document text living in your code; it handles formats you can’t paste, like PDFs and images; and stored files now support expiration settings. What it doesn’t change is cost. The document is processed for every request, and Anthropic’s announcement never claimed otherwise.

Prompt caching

Use prompt caching when the problem is paying for the same document on every request. In this workload, it cut billed input to roughly a third of pasting across five requests, and the gap keeps widening because every request after the first reads the document at about a tenth of the normal rate. The tradeoffs are the five-minute cache expiry, which assumes steady traffic, and restructuring your request to add the cache marker.

Use the files API and prompt caching together when both problems apply. Files API documents can be cache-marked the same way as pasted text. I tested them separately to isolate what each does on its own.

Paste the documents

Pasting still wins in some cases. Use pasting when prototyping and making one-off calls, where uploading first is just an extra step. This is also the best option for documents that change with every request, where nothing is reused so neither feature helps. Keep in mind that this is short reference text, since documents under 1,024 tokens can’t be cached on most models. Pasting also has the fewest moving parts: no upload step, no file IDs, no stored copies to manage.

I did this test expecting to find out whether the Files API beats pasting in terms of accuracy or cost. It turns out I asked the wrong question. They tie on cost, and the feature that wins on cost was something I tested at the last minute to try to force a different result.

The post Anthropic’s new Files API vs. pasting: It will save you time, but it won’t save you money. appeared first on The New Stack.