DEV Community: Paul Lovelace

Anthropic's FlashProve Wants a Receipt for Every AI Answer — Explained Honestly

Paul Lovelace — Wed, 04 Nov 2026 01:48:00 +0000

When you ask an AI model a question through an API, you are taking something on trust. The provider says the answer came from the model you paid for — the big, capable one, not a cheaper stand-in quietly swapped in behind the scenes. You have no way to check. Anthropic's Frontier Red Team has now published a research prototype that tries to change that: FlashProve, an open-source system for "provable inference" — a cryptographic proof that a reply came from one specific, committed set of model weights, without revealing the weights themselves.

That sentence is worth reading twice, because the idea is genuinely new and the reality is genuinely early. FlashProve is not a product you can switch on today. Anthropic says it has no plans to deploy it, at Anthropic or anywhere else, and calls it intermediate progress, not a completed agenda. This article keeps those two things separate throughout: what the prototype proves in principle, and what it cannot do yet in practice.

What it is

Provable inference answers a narrow but important question: did this exact model produce these exact tokens? FlashProve's answer comes in two phases, using a zkSNARK — a zero-knowledge succinct argument of knowledge, a kind of cryptographic proof that is short to check even when the computation it covers is enormous.

In the offline phase, the provider publishes a short commitment — think of it as a fingerprint — that pins down one exact set of model weights. In the online phase, for a given prompt and output tokens, the provider generates a proof that the committed model produced those exact tokens. Anyone holding the commitment, the prompt and the reply can verify the proof, without ever seeing the weights. The model itself stays secret; only the claim "this model made this reply" becomes checkable.

Anthropic tested this on Meta's Llama 4 Maverick, a 400-billion-parameter mixture-of-experts model, using 4-bit quantized weights with roughly 17 billion active parameters per token. FlashProve works for MoE models only — a structural limit, not a missing feature.

The release is open source under Apache 2.0: the research post, a technical report, a protocol paper, the prover, a fast C++ verifier, a slower formally-verified Lean verifier, Lean proofs of the top-level statements, and an interactive theorem visualizer.

What it actually does today — and what is only research

What it does today, in the prototype: verifiable proofs that a committed MoE model generated a specific reply, for contexts up to 1,024 tokens, under greedy decoding with an integer version of the weights. Verification runs on CPU, with no GPU needed.
What it is not: a production product, a deployed service, or a feature in any AI API you can use today.
What it could catch, in principle: a provider secretly substituting a cheaper model, benchmark cheating, a tampered token stream, or a false claim that an approved model did a job. Those are Anthropic's stated intended uses — real problems, addressed so far only in a laboratory setting.

Anthropic's own performance numbers — labelled as Anthropic's, not independently tested by us — show both the achievement and the cost. Proving runs at roughly 110 tokens per second on a single H100 GPU; a batch of 24 requests takes about 223 seconds. A proof for a 1,024-token request is about 19 MB. The commitment takes about 39 minutes on one H100, but then stays valid for roughly 16 million requests. Verification: a roughly 6.5 MB commitment downloaded once, checked in about 17 seconds on 24 CPU threads (about 21 seconds on one thread), no GPU. The catch: proving costs roughly 70–95x the GPU time of plain vLLM inference. Verification is cheap; generating the proof is very expensive.

Why it matters — if the cost ever comes down

Benchmarks shape buying decisions, yet a benchmark score is only meaningful if the model that earned it is the model you actually get. Regulated work may require that an approved model — and only that model — did a job. And every API customer is trusting that the provider runs what it advertises. A proof you can check yourself, without the provider handing over its weights, is a fundamentally different kind of assurance from a promise in a terms-of-service document.

That is why this release is worth attention even though nothing is deployable yet. It demonstrates, on a real 400-billion-parameter model, that the proof machinery works end to end. Anthropic is explicit that this is intermediate progress toward auditable inference, not the finished thing.

The limits, stated plainly

No hands-on testing was performed for this article. Everything comes from Anthropic's 2 November 2026 research post and the coverage that followed, checked 4 November 2026.

Research prototype only, not a production product; no deployment plans at Anthropic or any other lab.
MoE models only.
Integer weights under greedy decoding — floating-point inference or sampled output may not match the proof.
Context capped at 1,024 tokens.
The model architecture is not hidden; only the weights are.
No side-channel resistance.
Only the slower Lean verifier is formally connected to the soundness theorem; the fast C++ verifier carries no formal guarantee.
Repository version 0.16.0 is labelled an unmaintained research artifact not accepting contributions.
Proving costs roughly 70–95x the GPU time of plain vLLM inference (Anthropic's own numbers).
No price exists to report: free open source under Apache 2.0. The cost that matters is compute.

The bottom line: FlashProve is a real technical achievement — a cryptographic receipt for an AI answer, demonstrated on a 400-billion-parameter model, with cheap CPU verification and a fully open research release. But a receipt that costs 70–95x the inference it certifies, covers only MoE models under greedy decoding up to 1,024 tokens, and has no deployment plan anywhere, is a research result — not a tool you can use. Watch the proving cost and the decoding and context limits: if those move, provable inference stops being a demonstration and starts being infrastructure.

Sources: Anthropic research post, 2 November 2026, "Progress on provable inference for large language models" (https://www.anthropic.com/research/provable-inference); TechCrunch, 3 November 2026 (https://techcrunch.com/2026/11/03/anthropic-is-working-on-a-system-to-prove-ai-models-identity/); Unite.AI (https://www.unite.ai/anthropic-releases-flashprove-for-cryptographic-ai-inference-proofs/); MarkTechPost, 3 November 2026 (https://www.marktechpost.com/2026/11/03/anthropic-flashprove-provable-inference-zksnark/). Performance numbers are Anthropic's own, not independently tested results. No hands-on testing was performed. This breaking article is not the daily buyer-intent post, and it contains no affiliate links.

Appy Pie's Four AI Agents Want to Build Your Whole App — Explained Honestly

Paul Lovelace — Tue, 03 Nov 2026 22:48:32 +0000

Appy Pie has announced an Agentic AI App Builder for iOS and Android, built around four specialised AI agents. This article explains what the vendor says it does, what it does not prove, and what to check before relying on it.

Honesty note: This article is based on the vendor announcement. No hands-on testing was performed for this article, and no price is stated here because no price was announced in that announcement. Claims about what the builder does are vendor claims, not independently verified results.

What was announced

On 3 November 2026, Appy Pie announced a builder that, according to the vendor, brings four specialised agents together to plan, design, build and test apps. The vendor says users describe what they want, approve a development plan, and then refine the app through conversation.

The vendor also says backend services, a database, user accounts and hosting are included, so a user does not need to set up separate infrastructure accounts to start. Teams that already use Firebase or Supabase can, according to the vendor, connect those services instead.

The four agents, as described by the vendor

Planning Agent: Asks clarifying questions and proposes features, screens and data structure. The user approves the plan before building begins.
Design Agent: Creates screens, layouts and colours, using a logo or website as a brand reference where provided.
Build Agent: Generates the app in React Native for iOS and Android and connects it to the built-in backend, database and user accounts.
Testing Agent: Runs automated checks and applies fixes to detected issues before presenting a preview for the user to review.

The vendor says users can begin with a written or spoken request and attach files or screenshots for context. Its example brief is: "Build a CRM for my sales team with customer records, a deal pipeline and individual logins."

What this does not mean

An announcement is not a test result. The vendor's description does not, by itself, show how well the generated code performs, how it handles complex or unusual requirements, how much manual correction is needed, or what it costs over time.

In particular:

No price was announced in the release, so no price is claimed here.
No hands-on testing was performed for this article, so no claim is made about code quality, reliability or ease of use in practice.
App-store publication is subject to Apple and Google review, and users submit apps through their own Apple and Google developer accounts, according to the vendor. App-store developer fees are separate.
Export of the generated app code is supported, according to the vendor — but that is not the same as a guarantee that exported code will be easy to maintain outside the platform.

Who it might suit — and who should be cautious

The vendor pitches this to business owners and teams that want to turn an idea into a working app without first assembling infrastructure. That framing makes sense for simple apps, internal tools, customer portals, admin dashboards, online stores, community apps, media services and 2D games — all project types the vendor lists.

Developers should still ask practical questions before committing: Who owns and maintains the generated code? How are data, authentication and hosting handled at scale? What happens if you leave the platform? How are bugs, security updates and store rejections handled? Those answers matter more than a demo workflow.

The vendor also says the platform supports workflows through Claude and Claude Code, and more than 60 integrations through Model Context Protocol (MCP). Again, those are vendor claims about connectivity, not verified performance in a real project.

Bottom line

Appy Pie's pitch is clear: describe an idea, approve a plan, and let four agents handle design, building and testing, with infrastructure included. Whether that workflow holds up on a real, complex app is not proven by an announcement. Treat it as a promising vendor claim to test on a small, non-critical project first — not as a replacement for engineering judgement.

FAQ

What are Appy Pie's four AI agents?

According to the vendor, they are the Planning, Design, Build and Testing agents, which together take a brief through planning, design, code generation and automated testing.

Which platforms are supported?

According to the vendor, the builder generates apps in React Native for iOS and Android.

How much does it cost?

No price was announced in the vendor announcement, so no price is stated here. The vendor points readers to its pricing page for current plans and billing terms.

Has this been independently tested?

Not in this article. No hands-on testing was performed, and vendor claims are labelled as vendor claims throughout.

Can I export the code?

According to the vendor, export of the generated app code is supported.

Do I need separate backend accounts?

According to the vendor, no — backend, database, authentication and hosting are built in, although Firebase or Supabase can be connected if a team already uses them.

Sources

Appy Pie / Snappy LLC announcement via PR Newswire, "Appy Pie Launches Agentic AI App Builder for iOS and Android", 3 November 2026: https://www.prnewswire.com/news-releases/appy-pie-launches-agentic-ai-app-builder-for-ios-and-android-302927997.html
Appy Pie website: https://www.appypie.com
Appy Pie pricing page (referenced by the vendor for current plans and billing terms): https://www.appypie.com/pricing

No affiliate links are included in this article.

Snowflake's Always-On Bots Want to Work While You're Away — Explained Honestly

Paul Lovelace — Tue, 03 Nov 2026 16:44:54 +0000

Snowflake is pitching a simple idea: instead of you going to the data, always-on bots go to work for you — and keep working while you are away.

That sounds useful. It also sounds like the kind of claim that needs to be read carefully, because not everything in this announcement is available in the same way, at the same time, to everyone.

This is an honest explainer, not a buyer-intent post and not a hands-on review. No hands-on testing was performed for this article, and there are no affiliate links in it.

What is being announced, in plain terms

The central idea is autonomous work inside Snowflake: bots that can carry out ongoing data work, rather than only answering a single question when asked.

Think of it less as a chatbot you prompt once, and more as a worker you set up, give boundaries to, and then check on. The appeal is obvious: routine preparation, monitoring and follow-up that would otherwise wait for a person.

The risk is also obvious: work that continues without a person in the loop needs clear limits, clear ownership, and a clear way to see what it did and why.

The important distinction: what is GA, what is preview, and what is coming

This is where most coverage gets sloppy, so let us be precise:

CoCo Automations is generally available (GA). This is the part described as ready for general use.
Slack, Excel, Google Sheets and Mobile are in public preview. They are available to try in preview, not presented here as finished, generally available products.
The Snowflake CoCo / CoWork Bots are in private preview soon — NOT generally available. Do not treat them as something you can simply switch on today. “Private preview soon” means limited, forthcoming access, not general availability.

If a summary tells you all of this is simply “live now”, it is oversimplifying the announcement.

Why always-on work is different from a normal AI assistant

A normal assistant helps you in the moment. An always-on bot is supposed to help you over time.

That changes the questions you should ask:

What exactly is it allowed to change, and what is it only allowed to read or suggest?
How does it handle a task that is partly finished, ambiguous, or wrong halfway through?
Who is accountable when it acts while no one is watching?
How do you audit its work afterwards?
How do you pause it, roll it back, or stop it cleanly?

Until those answers are clear for your own data and workflows, “always-on” should be treated as a capability to govern, not just a feature to enable.

Adoption: read the claims as claims

Any adoption figures attached to this announcement are Snowflake's claims, not independently verified figures. That does not make them false — it means this article does not independently confirm them, and readers should not treat vendor figures as independent measurement.

The same caution applies to productivity and efficiency claims. They are interesting as signals of what Snowflake believes customers are experiencing, but they are not a substitute for testing in your own environment, with your own data, permissions and costs.

Pricing: none is stated here

No pricing is stated in this article because none was given for it. Do not infer a price, a tier, or a “free” or “included” status from this post. If pricing matters to your decision — and it should — check Snowflake's current pricing and terms directly before planning around it.

What this does not prove

To be clear about the limits of this article:

No hands-on testing was performed.
This is not a review of a product you can use today in its private-preview form.
This is not a recommendation to buy, migrate, or adopt anything.
This does not verify Snowflake's adoption claims independently.
This does not state pricing, because none was given.

What it does do is separate the announcement into its actual availability stages, so you are not misled by a single headline.

A practical way to think about it

If you are evaluating this kind of tool, start with a narrow, reversible use case:

Pick work that is routine, well-defined and easy to check.
Set tight permissions and a clear owner.
Require a readable log of what the bot did.
Review the results before anything affects production data or external communication.
Only widen the scope after the checks have actually passed.

That approach works whether the eventual product is excellent or disappointing — and it protects you while private-preview features are still, by definition, not generally available.

The bottom line

Snowflake's always-on bots are an interesting direction: data work that does not wait for you to ask. But the honest version of the story has stages. CoCo Automations is GA. Slack, Excel, Sheets and Mobile are in public preview. The CoCo / CoWork Bots themselves are private preview soon, not generally available.

Judge the idea on that timeline — not on a headline that flattens it.

FAQ

Are Snowflake's CoCo / CoWork Bots generally available?

No. They are described as private preview soon, not generally available.

What is generally available?

CoCo Automations is GA.

What is in public preview?

Slack, Excel, Google Sheets and Mobile are in public preview.

Are the adoption figures independently verified?

No. Adoption figures in this area are Snowflake's claims, not independently verified figures.

How much does it cost?

No pricing is stated in this article because none was given. Check Snowflake's current pricing directly.

Was this hands-on tested?

No. No hands-on testing was performed for this article.

Is this a buying recommendation or an affiliate post?

No. There are no affiliate links in this article, and it is not a buyer-intent post.

PagerDuty's Paige Wants to Join Your On-Call Team — Explained Honestly

Paul Lovelace — Tue, 03 Nov 2026 15:46:54 +0000

Nothing here is sponsored — no affiliate links on this page. This breaking article is not the daily buyer-intent post. Facts below come from the sources listed at the end, checked 3 November 2026. We have not tested Paige hands-on, and nothing here is a hands-on finding.

If you have ever been woken at 3 a.m. by a page, you know the real shape of the job. It is rarely the fix that takes the time. It is the hunting: which service failed, what changed, who owns it, and whether the alert in front of you is even the real problem. On-call work is mostly triage, and triage is mostly context.

That is a big claim, and it is worth slowing down for, because the interesting thing about Paige is not the hype — it is where it sits. PagerDuty has been talking about agentic AI for a while, but this is the first time the company has packaged it as a named member of the team rather than as a feature inside a dashboard. This article explains what Paige is, what it actually does, where the line is drawn, and what to watch — with the hype separated from the facts.

How we put this together

We verified the story against PagerDuty's 3 November 2026 BusinessWire press release and the TechTarget coverage that reported the launch the same day, and we checked PagerDuty's own Paige product page for how the company positions the tool.

Verdict

Paige is a serious, well-scoped launch: an SRE agent that investigates in parallel, shows its reasoning and hands over cleanly to humans, rather than a magic fixer. The honest limits matter as much as the headline: autonomous resolution is coming soon, not live, and the biggest numbers are PagerDuty's own.

What it is

Paige is an SRE agent that lives on the PD Reliability Platform — the renamed PagerDuty Operations Cloud — and works, in PagerDuty's framing, as a member of the operations, engineering or DevOps team. Its job is to detect, investigate and remediate issues across complex systems, pulling together signal intelligence, incident management and automation rather than treating them as three separate tools.

It does not work alone. Paige orchestrates a set of supporting agents underneath it: Scribe Agent, Shift Agent and Insights Agent are the ones named at launch. Think of it less as a single chatbot with a pager, and more as a lead investigator with a small team behind it — one handling the write-up, one handling the handover, one handling the patterns across incidents.

Alongside Paige, PagerDuty announced two more things on the same day. The first is PD Labs, a new open innovation centre for AI in reliability engineering, built with design partners — the place where future ideas get tried out in the open rather than behind closed doors. The second is SRE Workbench, released concurrently on PD Labs: a shared workspace where humans and Paige investigate from the same data, so the agent's reasoning is visible rather than hidden inside a black box.

What it actually does today

The headline capability is called Deep Investigation, and it is the one that matters most to anyone who has lived through a messy incident. When something goes wrong, Paige tests multiple root-cause hypotheses at the same time instead of chasing them one by one, ranks them by confidence, and narrates its reasoning as it goes. That narration is doing real work: it is the difference between an agent that hands you an answer and an agent you can actually follow, challenge and overrule.

SRE Workbench is the other half of that idea. Humans and Paige look at the same data in the same place, so an engineer joining an incident mid-flight can see what the agent has already ruled out and why, instead of starting the investigation from scratch or blindly trusting a conclusion.

On the connectivity side, Paige ships with more than 750 integrations, including Slack and Jira, plus PagerDuty's own AI-assisted runbook generation. That matters because an agent is only useful if it can actually see your stack: the integrations are the difference between a demo that works on PagerDuty's data and a tool that works on yours.

The line PagerDuty drew

Here is the part to read carefully, because it is easy to miss in the launch headlines. Paige operates within the guardrails set by each organisation — it escalates to humans when needed, and it does not automatically fix production systems without approval. PagerDuty is positioning it as a teammate that prepares the ground: it investigates, it narrows the field, it proposes a remediation path, and then a human approves or overrides.

That restraint is actually reassuring. An agent that silently fixes production systems at 3 a.m. without a human in the loop would be a liability, not a feature. PagerDuty knows this, and the language in the launch materials is careful: Paige is here to reduce the toil, not to replace the judgement.

Vendor claims

PagerDuty says Paige is built on 16 years of operational data. The company also says, via the TechTarget coverage, that PagerDuty manages nearly a billion disruptions a year and that two-thirds of the Fortune 100 use its platform. Those are the numbers PagerDuty is leaning on to argue that Paige is not starting from scratch — it has seen more incidents than any single team ever will.

On pricing, PagerDuty describes a single scale-tiered fee that bundles telemetry ingestion, automation and AI agents into one cost structure, but the press release gives no pricing numbers. We have not added any, because inventing a price for a product that has not published one would be misleading.

Who it matters for

On-call engineers and SRE teams. If your on-call rotation is drowning in triage, Paige is aimed squarely at you. The Deep Investigation capability is the part that could actually change your night: parallel hypotheses, ranked by confidence, with reasoning you can follow.
DevOps and platform teams. The 750+ integrations and the shared Workbench mean Paige is designed to slot into existing tooling rather than replace it. If you already use Slack, Jira and PagerDuty, the barrier to trying it is low.
Engineering leaders weighing agentic tools. Paige is a useful test case for the whole category: a well-scoped agent with visible reasoning and human approval, rather than a black-box autopilot. How PagerDuty handles the guardrails question will set a precedent.
Teams already on PagerDuty. If you are on the PD Reliability Platform, Paige is the natural next step. The question is not whether it integrates — it does — but whether the investigation quality justifies the trust you would need to give it.

Limits and honest gaps

Autonomous resolution without waking a human. PagerDuty has said this is coming soon, not available now, so do not treat Paige as a fully autonomous fixer today.
The scale and experience figures are the vendor's claims, not independent verification. 16 years of data, nearly a billion disruptions a year, two-thirds of the Fortune 100 — PagerDuty's numbers, reported by others, untested by us.
No pricing numbers, revenue impact or customer adoption figures were published in the launch materials we checked. The value case is argued on time saved, not on hard numbers.
PD Labs and SRE Workbench are new. They are interesting, but they are also unproven in the wild. The design-partner model is promising, but it is not the same as broad adoption.
An agent is only as good as the data it can see. If your stack is not well-instrumented, or if your runbooks are out of date, Paige will inherit those gaps. The 750 integrations help, but they do not fix a messy estate.

The bottom line is a measured one. Paige is a serious, well-scoped launch: an SRE agent that investigates in parallel, shows its reasoning and hands over cleanly to humans, rather than a magic fixer. If you are already on PagerDuty and your on-call rotation is drowning in triage, it is worth a close look — with the guardrails question front of mind, and with autonomous resolution understood as coming soon, not live today.

Sources: PagerDuty press release (BusinessWire, 3 November 2026); PagerDuty Paige product page; TechTarget coverage of the PagerDuty Paige launch (November 2026).

Claude API Message Threads: Stop Resending the Whole Conversation — Explained Honestly

Paul Lovelace — Tue, 03 Nov 2026 08:46:18 +0000

If you have ever built a long-running agent on the Claude Messages API, you know the tax. Every turn, your app resends the entire conversation — every earlier message, every tool result, the whole history — just to ask the next question. The longer the session runs, the heavier each request gets, and the longer the user waits for the first token.

Anthropic opened a way around that on 2 November 2026: Message Threads, now in public beta on the Claude Messages API. The idea is simple enough to explain in one sentence — the API keeps the conversation on its side, so later requests send only what is new — but the details matter, because this is a beta with real limits, and one popular misunderstanding needs clearing up straight away: it does not cut your token bill.

What it is

Message Threads lets a Messages API application hand conversation state to Anthropic's servers between turns. The first request — the "create" request — sends the full conversation, including the system prompt and tools, together with the thread parameter, and starts a thread. The API stores the conversation and Claude's reply under that response's ID.

Every later turn — a "continue" request — sends only the messages since the previous response, plus that previous response's ID. The API reconstructs the rest before calling the model. In code terms, you add the thread parameter and the message-threads-2026-08-12 beta header; the official SDKs provide a thread helper that handles the header, keeps the conversation in memory, and replays the full conversation once for certain continuation errors.

Anthropic pitches it at exactly the workloads where resending hurts most: long-running coding agents, computer-use agents whose screenshots stay with the thread, and document- and image-heavy workflows. It is already on by default for most Claude Code users, which is where the headline numbers come from.

What Anthropic claims — and what it does not claim

The vendor numbers, attributed to Anthropic and not presented as our own tests:

On requests of 500,000 to 1 million tokens, median time to first token is about 35% lower with message threads, based on the Claude Code rollout.
In long conversations, median request size fell from about 800 KB to 1.8 KB.

Both are Anthropic's figures from its own rollout. We have not tested Message Threads hands-on, and no independent benchmark is cited here, so treat them as the vendor's claims, not verified results.

And here is the part worth saying plainly, because it is easy to get wrong: Claude still reads the full conversation on every turn. Token usage, token charges and rate limits are unchanged. What you save is upload time and request size — the waiting, not the bill. Prompt caching, for the record, still needs to be requested explicitly; threads do not switch it on for you.

Where it is available

Beta support is on every model, and the feature is available on:

The native Claude Platform
Claude Platform on AWS
Claude in Microsoft Foundry
Claude Models on Google Cloud (Anthropic-managed)

There is no change in pricing for using it — standard Claude token rates apply.

The limits — stated honestly

This is a public beta, and it behaves like one. The limits below come from Anthropic's own documentation and announcement coverage, and they decide whether threads fit your app:

Threads expire fast. A thread expires 5 minutes after its last request. Each response restarts that clock, but an idle session is gone quickly — and when it is gone, you resend the full conversation to start a new one.
They are best-effort. Thread state is held in memory under server-managed encryption and never written to durable storage, and it is deleted no more than one hour after last use. There is no API to list, read or delete threads. If a continuation fails — for example, a continue request sent before the previous response's message_stop streaming event can return a 404 — your app must still be able to replay the full conversation itself. Keep your own copy of the history; threads are a shortcut, not your store of record.
Not eligible for zero data retention (ZDR). If your use case requires ZDR, threads are out — though Anthropic notes the feature does not affect eligibility for other ZDR features.
Not for HIPAA organisations, and not with Message Batches, on-demand compaction, or most context editing. Organisations with Inference hooks enabled are also excluded, and turns written by fallback models are not stored — you need a fresh full-conversation create request before threading can resume.
No token counting via threads. The beta does not support the Token Counting API path, so do not plan around it.

None of that makes threads useless — it makes them a latency feature for active sessions, not a storage feature, not a cost feature, and not a compliance shortcut.

Who it matters for

Developers running long agent sessions. If your agent loops for hours — coding, computer use, long document work — the 5-minute expiry fits an active session, and the upload savings are real in Anthropic's numbers. This is the audience the feature was built for.
Teams watching API latency, not API spend. If your bottleneck is time to first token on huge contexts, threads attack exactly that. If your bottleneck is the token bill, threads change nothing — look elsewhere.
Anyone building on Claude across clouds. Availability on AWS, Foundry and Google Cloud (Anthropic-managed) as well as the native platform means this is not a single-platform experiment.
Developers with strict data rules. Read the limits first: ZDR ineligibility, the 5-minute expiry, no retrieval API and best-effort storage rule threads out for some architectures entirely. Better to learn that from this article than from a failed design review.

The verdict

Message Threads is a small, well-aimed fix to a real annoyance: resending a whole conversation to ask one more question. Anthropic's Claude Code numbers — about 35% lower median time to first token on very large requests, request size down from roughly 800 KB to 1.8 KB in long conversations — are encouraging, but they are the vendor's, and this article has not verified them independently.

The honest way to try it is as a beta for active, long-running sessions where latency matters, with your own full-history replay path kept intact, and with no expectation of a smaller bill. If that matches your app, threads are worth an afternoon of testing. If you need durable conversation storage, lower token costs, or ZDR, this is not that feature — and Anthropic, to its credit, does not pretend otherwise.

Sources: Anthropic announcement, 2 November 2026, via Unite.AI: "Anthropic Launches Message Threads Beta for Long-Running Agents" (https://www.unite.ai/anthropic-launches-message-threads-beta-for-long-running-agents/); Blockchain.News: "Claude Public Beta Message Threads Cut Agent Latency" (https://blockchain.news/news/claude-public-beta-message-threads-cut-agent-latency); Daily AI Brief: "Anthropic Adds Message Threads to Claude API" (https://dailyaibrief.com/news/anthropic-adds-message-threads-claude-api-gLTRP1Oz). Performance figures (about 35% lower median time to first token on 500K–1M token requests; median request size from about 800 KB to 1.8 KB in long conversations) are Anthropic's claims from its Claude Code rollout, not independently tested results. No hands-on testing was performed for this article. Nothing here is sponsored — no affiliate links. This breaking article is not the daily buyer-intent post.

A Robot Brain That Learns From Watching People — AGIBOT's GO-3, Explained Honestly

Paul Lovelace — Tue, 03 Nov 2026 07:46:19 +0000

Nothing here is sponsored — no affiliate links on this page. This breaking article is not the daily buyer-intent post. Facts below come from the source listed at the end, checked 3 November 2026. We have not tested GO-3 hands-on, and nothing here is a hands-on finding.

AGIBOT has unveiled GO-3 Preview, an embodied foundation model — in plain language, a robot brain — and the headline claim is a big one: first place on three embodied AI benchmarks, RoboDojo, RoboTwin and RoboColiseum, plus a promise to fully open-source the model by the end of 2026. If that promise holds, it matters. Most of the robot brains making headlines lately live behind an API or a closed product. A fully open-sourced embodied foundation model, one that other teams can actually download, study and build on, would be a different kind of news. But — and this is the honest part you need before the excitement — GO-3 Preview is a preview announcement from the vendor, not a release. There is no download link yet, no licence, no weights, no code repository, no pricing and no hardware you can buy or try today. So this article keeps both halves in view: what AGIBOT says GO-3 does, and what is still just a promise.

How we put this together

We verified the story against AGIBOT's press release via PRNewswire APAC on 3 November 2026, also syndicated via Korea Herald / Macau Business / Manila Times. We have not run GO-3 ourselves, so nothing here is a hands-on finding. Where a claim is the vendor's own — especially the benchmark rankings — we label it as exactly that, and where the release published no numbers, we quote none.

Verdict

GO-3 Preview is the most ambitious embodied AI announcement of the week, and its open-source promise is what makes it worth more than a passing headline. But today there is nothing to download, no score to quote, and no robot to try. The practical takeaway is not "go get GO-3" — it is "watch this one." Mark the end of 2026, when the open-source release is promised, and judge GO-3 then by what actually ships.

What it is

GO-3 Preview is AGIBOT's third-generation embodied foundation model. "Embodied" means it is built to live inside a physical body — a robot — rather than inside a chat window. It takes in what the robot sees and is asked to do, and it produces actions: reaching, grasping, moving, manipulating objects in the real world.

AGIBOT describes its architecture as WRAM, short for World Reasoning Action Model. The idea is to unify three things that are usually handled separately: understanding the task, predicting what the world will look like next, and generating the action to take. Inside WRAM sit three core designs AGIBOT names in the announcement:

CoAE (Control-Oriented Autoencoder) — compressing what the robot perceives into a form built for control, not just for description.
SVP (single-step future-state prediction) — predicting the very next state of the world, one step at a time, rather than dreaming far ahead and hoping it stays accurate.
KASO — selecting, from the model's predictions, the ones that stay consistent with the actions actually taken during training, so the robot's plans do not drift away from what it has really seen work.

You do not need to memorise those acronyms. What matters is the shape of the claim: a single model that understands, predicts and acts, instead of a pipeline of separate systems bolted together.

How it was trained — and what it claims to learn

For pre-training, AGIBOT says GO-3 learned from two kinds of data: human first-person videos — footage of people doing things, seen from their own point of view — and robot trajectories, recordings of robots actually moving through tasks. The pitch is that watching people do things, at scale, teaches a robot more general skills than robot-only data ever could, because there is simply far more human video in the world than robot experience.

From that, AGIBOT claims two kinds of adaptation that, if real, are the whole point of a foundation model for robots:

Zero-shot task adaptation — handling a task it was not specifically trained on, without extra demonstrations.
Few-shot adaptation — picking up a new task from only a small number of demonstrations. The example AGIBOT gives is LEGO assembly with limited demonstrations: show it a few times, and it generalises from there.

Both claims are AGIBOT's, from its own announcement. We have not tested them, and no independent verification is cited in the release.

The post-training loop: 100 robots, simulation, and a game of tabletop curling

After pre-training comes what AGIBOT calls Genie Evolver, its post-training system. It is described as a distributed hybrid-environment system that combines a fleet of 100 physical robots with physics simulation and world models — real robots and simulated ones, learning together.

The demonstrations AGIBOT cites are deliberately everyday and physical: tabletop curling, block extraction, and throwing a ball into a moving basket. The curling claim is the eye-catching one: after a few hours of practice, GO-3 is claimed to have achieved a higher win rate than typical human players. That is a vendor claim, not an independently verified result, and "typical human players" is AGIBOT's own framing — but it tells you what kind of learning AGIBOT wants you to picture: not a robot repeating a memorised motion, but one that improves at a physical skill through practice.

After deployment: a robot that keeps improving in a real shop

The third stage is post-deployment, and it is where AGIBOT's language gets boldest. GO-3 comes with Genie Master, an embodied agent framework built around EEP, the Embodied Execution Protocol, which covers capabilities, guidance, feedback and continuity — roughly, what the robot can do, how it is instructed, how it learns from what happens, and how it keeps going across tasks.

The demonstration here is a Genie G2 robot in a real convenience store, claimed to improve across tasks without human demonstrations or manual tuning. AGIBOT calls this Physical RSI — Recursive Self-Improvement in the Physical World: a robot that does not just run a fixed policy after deployment, but gets better at its job by doing it.

That is, if it works as described, the most consequential claim in the whole announcement. A robot that improves in a real shop, without a human retraining it by hand, is a different proposition from a robot that performs well in a lab demo. It is also the claim that most needs independent checking, because it is the hardest to verify from a press release alone.

Where GO-3 sits in AGIBOT's own lineage

GO-1, built on the ViLLA framework.
GO-2, which introduced action chain-of-thought — the robot reasoning through its actions step by step.
GO-3 Preview, which extends scaling across the full lifecycle: pre-training, post-training and post-deployment together.

AGIBOT calls this "full-lifecycle scaling" — the argument that progress in embodied AI does not come from scaling just one stage, but from scaling all three, from how the model is first trained to how it keeps learning once it is out in the world.

Who it matters for

Robotics developers and researchers. If GO-3 is fully open-sourced by the end of 2026 as promised, it would be a shared foundation to build on and compare against — and the WRAM architecture, the human-video pre-training mix, and the full-lifecycle scaling claim are all worth studying, whether or not the benchmark claims hold up independently.
Teams building physical AI products. The convenience-store demonstration, and the Physical RSI claim behind it, point at robots that keep improving after deployment rather than freezing at shipment. That is the direction to watch, and the claim to verify, before betting a product on it.
Developers tracking open models. The open-source promise is the date to put in your diary. Until the weights, code and licence actually appear, GO-3 is a story to track, not a tool to use.
Anyone curious about where AI goes next. Chatbots answered questions; agents used tools; embodied models move things in the real world. GO-3 is a clear sign of where the industry's attention is heading, even before any of its claims are independently confirmed.

Limits — stated plainly

This is a PREVIEW announcement from the vendor. GO-3 Preview is announced, not released. Treat every capability claim in this article as AGIBOT's claim, not as an established fact.
The benchmark claims are AGIBOT's own. First place on RoboDojo, RoboTwin and RoboColiseum is claimed in AGIBOT's release. No independent verification is cited in the release, and no scores or numbers were published in the release text we have — so we are not quoting any. Do not repeat a score for GO-3 that you have not seen from an independent source.
It is NOT open-source yet. The full open-source release is promised by the end of 2026. It has not happened. Do not describe GO-3 as downloadable, open-source today, or available to try.
No download link, licence, model weights, code repository, pricing or hardware availability was given in the release. If someone offers you a "GO-3 download" today, it is not coming from this announcement.
We have NOT tested GO-3 hands-on. No robot running GO-3 is available to try today, and nothing in this article is a hands-on finding.
The demonstrations are AGIBOT's chosen examples. Tabletop curling, block extraction, throwing a ball into a moving basket, and the convenience-store G2 robot are the cases AGIBOT chose to show. They are not an independent test suite.

The bottom line is a two-part sentence, and both parts matter. GO-3 points at a future where a robot's brain is open, general, and still learning after it leaves the lab — and the architecture story, from human-video training to a 100-robot post-training fleet to in-store self-improvement, shows how AGIBOT thinks that future is built. But today it is a preview announcement with vendor claims, no scores to quote, and nothing to download. Watch the end-of-2026 open-source promise, and judge GO-3 then by what actually ships.

Source: AGIBOT press release via PRNewswire APAC, 3 November 2026: "AGIBOT Unveils GO-3 Preview, Takes Top Spot on Three Embodied AI Benchmarks" (PRNewswire), also syndicated via Korea Herald / Macau Business / Manila Times. No hands-on testing was performed for this article, and no benchmark scores, prices, download links or availability beyond the release are claimed.

DeepSeek's Creator Mode Turns Plain English Into Working Harness Plugins — Explained Honestly

Paul Lovelace — Tue, 03 Nov 2026 01:49:21 +0000

DeepSeek's Harness team has announced Creator Mode for DeepSeek Harness, and the pitch is as simple as it gets: describe an idea in plain English, in chat, and get back a ready-to-use plugin. No plugin code to write, no extension API to learn first — you say what you want, and Harness builds the plugin for you. The slogan is "Your Harness. You Define It."

It is a genuinely appealing idea, and it lands on top of a design where, in principle, almost anything in Harness can be a plugin. But the honest version of this story has a second half, and it matters just as much: Harness is in developer preview, its core plugins are basic, its APIs are still changing in ways that will break things, and it has never had a security audit. Both halves are true, so this article keeps both in view.

What it does

Creator Mode lets a user turn an idea into a ready-to-use plugin by describing it in plain English in chat. That is the whole interaction as announced: you write what you want, in ordinary language, and Harness produces a plugin you can use. The point is not that describing software in English is new — it is that the result here is a working extension of your own agent environment, not just a snippet of code to paste somewhere.

That works because of how Harness is designed. The Harness team describes it as "everything is a plugin": plugins can extend tools, skills, and parts of the interface itself. In most tools, the interface is fixed and only the capabilities plug in. In Harness, the claim is broader — the surface you work with is itself made of plugins, so a plugin you create in chat can change more than what the agent can do; it can change how the workspace looks and behaves. Creator Mode is the feature that puts that design in the hands of people who do not write plugins by hand.

The context matters too. Harness featured in DeepSeek's October 2026 model update, with V4.1-Flash optimized for Harness, and the Harness team was formed during 2026 to build agents competing with tools like Anthropic's Claude Code. Creator Mode is therefore not a standalone novelty — it is the next step in an agent project DeepSeek is actively pushing, from the same team that published the Super-agent research prototype days earlier. The Harness code, including Creator Mode, is reported as published under the MIT licence.

The 7 demo prompts — and the reproduction caveat

Alongside the announcement, DeepSeek published 7 demo prompt sets, in both Chinese and English, showing what Creator Mode is supposed to produce. The range is deliberately wide:

A design workspace
A sandbox game
A 3D LLM visualizer
A 3D model renderer / architectural showcase (Eiffel Tower, Great Wall, Forbidden City)
A video-editing workbench
Poster design
Paper reading
Session statistics
Transformer computation visualization
Interface style switching

That list is the strongest evidence for the "everything is a plugin" claim: games, visualizers, workbenches, and interface themes are all the same kind of object in Harness. But there is a caveat attached to the demos, and DeepSeek states it openly: some of the demos were refined over multiple rounds of dialogue. A single copied prompt may therefore NOT reproduce the final result shown. If you try a demo prompt and get something simpler or rougher than the showcase, that is not necessarily a failure on your part — the showcase version may be the product of several back-and-forth rounds. Judge Creator Mode on what you can build with a few rounds of iteration, not on a one-shot copy of a demo prompt.

Who it matters for

Developers who customize their agent tools. If you have ever wanted a small, personal addition to your coding agent — a stats view, a paper-reading workflow, a visualizer — Creator Mode promises that without the plugin-development overhead.
Agent builders and researchers. A system where the interface itself is plugin-built, and where plugins can be generated from chat, is a design worth studying — especially next to the Harness team's Super-agent prototype from the same week.
Teams evaluating open agent platforms. MIT-licensed code plus chat-generated plugins is a combination worth tracking, provided the preview limits below are taken seriously.
Curious non-specialists. The plain-English entry point is the whole point: Creator Mode is aimed at people with an idea, not only at people with plugin experience.

Limits and safety warnings — stated plainly

Harness is in developer preview. It is not a finished product, and no timeline has been announced for leaving preview. Expect rough edges and change.
Its core plugins are basic. The built-in starting point is simple. Creator Mode's demos show what is possible, not what ships as standard.
Its APIs are still evolving, with compatibility-breaking changes ahead. Plugins built today may need rework as the APIs change. Do not build anything you cannot afford to rebuild.
It has NOT had a security audit. The GitHub safety notice says so directly, and it is blunt about the consequences: the software can run model-generated code and commands, and may damage files or leak credentials if a plugin or prompt goes wrong.
Never run it near real code or real credentials without review. That follows directly from the warning above. A sandbox, a throwaway directory, and no real secrets nearby — that is the only sensible way to try a preview agent that executes generated code.
We have NOT tested Creator Mode hands-on. Nothing in this article is a hands-on finding. Our verdict is based on the announcement and the reporting around it, plus the project's own stated limits.

The verdict

Creator Mode is the most user-friendly idea to come out of the Harness project so far: if it works as described, it collapses the gap between "I wish my agent tool did this" and "it does this now" down to a single chat message. But Harness is a developer preview with basic built-in plugins, evolving APIs, and no security audit — so treat Creator Mode as a promising direction to watch and to try carefully in a sandbox, not as a finished platform to build production workflows on today.

Try it in a sandbox, iterate over several rounds rather than judging it on one prompt, and keep it far away from real code and real credentials until the project matures.

Sources: DeepSeek Harness team announcement on X (@DeepSeekHarness), 2 November 2026; Bloomberg (via reports); Quartz (via IlPunto.AI); PANews; TokenPost; IlPunto.AI. No hands-on testing was performed for this article, and no benchmarks, prices, or availability beyond the sources above are claimed. Nothing here is sponsored — no affiliate links. This breaking article is not the daily buyer-intent post.

Meituan's LongCat-2.5 Wants Your Agent to Finish the Whole Job — Terminals, Browsers, Spreadsheets and All

Paul Lovelace — Mon, 02 Nov 2026 08:54:53 +0000

Nothing here is sponsored — no affiliate links on this page. This breaking article is not the daily buyer-intent post. Facts below come from the sources listed at the end, checked 2 November 2026. We have not tested LongCat-2.5 hands-on, and no hands-on claim is made anywhere in this article.

Meituan released LongCat-2.5 on 2 November 2026, moving from the 2.5-Preview of 25 September 2026 to a full release. The pitch is not a smarter chatbot. It is a model built for the unglamorous middle of real development work: staying on a task across terminals, browsers, graphical interfaces, spreadsheets and design tools, instead of answering one prompt well and losing the thread on the next step.

How we put this together

We verified the story against TechNode, Daily AI Brief and AI Affairs coverage of 2 November 2026. We have not run LongCat-2.5 ourselves, so nothing here is a hands-on finding. Every benchmark below is labelled vendor-reported and unverified, and the disputed parameter figures are flagged as disputed, not repeated as fact.

Verdict: LongCat-2.5 is interesting not because of its headline scores, which are vendor-reported and unverified, but because of what it is optimised for: sustained, multi-surface agent work, with visual and text input in one framework. If your work lives in one editor and one terminal, this changes little today. If your work regularly spans a browser, a GUI app and a spreadsheet, it is worth watching — once independent testing, and the promised open releases, arrive.

What LongCat-2.5 actually is

LongCat-2.5 is a native multimodal model, which in practice means it takes visual and text input inside a single unified token framework rather than bolting a vision encoder onto a text model as an afterthought. That matters for agent work: much of what an agent has to deal with — a browser page, a GUI window, a design canvas, a spreadsheet — is visual first. A model that can genuinely read those surfaces, rather than relying on a scraped text dump of them, has a better chance of doing something sensible with them.

Meituan positions it for long-horizon agentic coding: sustained execution across terminals, browsers, GUIs, spreadsheets and design tools, plus visual coding, creative design and 3D tasks. The through-line is duration and breadth, not a single clever trick. The model is supposed to keep going — and keep context — across tools that normally force an agent to start over.

Two honest caveats belong right here, before any numbers. First, the reported scale — 1.6 trillion total parameters, with about 48 billion activated per token — is disputed: a report noted that the same figures were attached to LongCat-2.0 and carried across to the preview, so treat them as reported, not settled. Parameter counts are a weak proxy for capability anyway; what matters is what the model does on real tasks, and that is still largely unproven for this release. Second, Meituan says it trained on extended agent-action sequences including failed attempts, and optimised 4-bit weights and activations for domestic chips. That is a plausible recipe for a long-horizon agent — learning from dead ends, not just clean demonstrations — but it is the vendor's description of its own training, not an independently confirmed fact.

The vendor-reported benchmarks — read them as claims, not results

Meituan's reported numbers, all vendor-reported and not independently verified, are: Terminal Bench v2.1: 88.4, against 70.8 for LongCat-2.0; AutomationBench: 51.8; BrowseComp: 91.9; and Program Bench: 25.5, against a top entry of 37.

The Terminal Bench jump, if it holds up, would be the most meaningful of the four: terminal work is the backbone of agentic coding, and a leap from 70.8 to 88.4 would suggest the long-horizon training is doing something real. But "if it holds up" is doing a lot of work in that sentence. Vendor benchmarks are run in the vendor's harness, on the vendor's choice of tasks, and they have a long history of not surviving contact with independent evaluation. The Program Bench figure cuts the other way and is worth more attention than it will probably get: 25.5 against a top entry of 37 is a reminder that this model is not claiming to lead everywhere. A model that is strong on terminal and browser automation but middling on program synthesis is a specialist, not a general champion — and specialists are fine, as long as nobody sells them as champions.

The right posture is simple: note the numbers, wait for independent runs, and in the meantime judge the model by what it can demonstrably do in your own workflow, not by a benchmark table.

How you can actually try it — and what is not out yet

LongCat-2.5 is available through longcat.chat and the LongCat API, and it supports Claude Code, Codex, Hermes and other agent tools. That tooling support matters more than the chat window: an agentic model that only lives in a web chat is a demo, while one that plugs into the agent harness you already use is something you can actually test on a real job.

What is not out yet is equally important, and it is easy to get wrong in the rush of a launch day. GitHub and Hugging Face releases are planned, not yet released. Do not go looking for an open-weights download today expecting to find one, and treat any link claiming to be the official LongCat-2.5 weights with suspicion until Meituan actually publishes them. The gap between "planned" and "live" is where launch-day confusion — and copycat repos — thrive.

What this means for developers, honestly

Judge it on sustained jobs, not single prompts. The whole case for LongCat-2.5 is duration across tools. A one-shot code-generation test will not tell you whether it is good at what it claims to be good at. If you try it, give it a job that actually spans a terminal, a browser and a document, watch where it loses context, and compare that failure point with whatever you use today. That is the test that matters.

Visual input is the quiet differentiator. Most coding agents still live in text. If LongCat-2.5's unified visual-text framework genuinely lets it work with GUIs, design tools and spreadsheets rather than around them, that opens up a class of work — updating a dashboard, checking a design against a spec, reconciling a spreadsheet — that text-only agents handle badly. Again, that is a claim to test, not a fact to repeat.

The disputed parameter count is a warning label, not a scandal. Figures that migrate unchanged from one release to the next are a reminder to read launch coverage sceptically, including this article's own sources. It does not make the model bad; it makes the marketing around it unreliable. Capability claims need independent evidence, and parameter counts are not evidence.

Do not rebuild your stack on launch day. The model is new, the open releases are still pending, and no independent benchmark has landed yet. The sensible move is a small, time-boxed trial on a real multi-tool job — inside the agent tool you already use, if it is supported — while waiting for the open release and independent numbers.

What LongCat-2.5 does NOT prove

It does not prove long-horizon agents are solved. One vendor release with vendor benchmarks does not settle a problem every lab is still working on. Sustained execution is hard precisely because errors compound; a model that survives ten steps can still fail at fifty.

It does not prove the parameter figures. The 1.6 trillion / 48 billion activated figures are reported and disputed, as noted above. Treat them as unverified.

It does not prove leadership on program synthesis. Its own reported Program Bench score trails the top entry by a wide margin.

We have not verified any of this hands-on. This article reports Meituan's release and the coverage of it, as listed below. We have not run LongCat-2.5, and no hands-on testing, benchmark reproduction, or performance claim beyond the sources is made here.

The useful takeaway is narrower than the launch headlines, and more durable. The agent race is shifting from "who writes the best function" to "who can stay on a messy, multi-tool job until it is actually finished." LongCat-2.5 is Meituan's bet that the second question is the one that matters — and that training on long action sequences, failures included, plus genuinely multimodal input, is how you answer it. Whether the bet pays off will be decided by independent testing and by the open releases that are still to come, not by today's announcement. Until then, try it on a real job, watch where it breaks, and keep the scepticism switched on.

Sources

Sources: TechNode, "Meituan launches LongCat-2.5 multimodal AI model for extended coding tasks," technode.com, 2 November 2026 (full release from the 2.5-Preview of 25 September 2026; long-horizon agentic coding across terminals, browsers, GUIs, spreadsheets and design tools; visual + text input in a unified token framework; availability via longcat.chat and the LongCat API; Claude Code, Codex and Hermes support; GitHub and Hugging Face releases planned, not yet out; training on extended agent-action sequences including failed attempts; 4-bit weights/activations optimised for domestic chips); Daily AI Brief, "Meituan releases LongCat-2.5 multimodal model," dailyaibrief.com, 2 November 2026 (vendor-reported benchmarks: Terminal Bench v2.1 88.4 vs 70.8 for LongCat-2.0, AutomationBench 51.8, BrowseComp 91.9, Program Bench 25.5 vs top entry 37); AI Affairs, "Meituan releases LongCat-2.5 for long-running coding tasks," aiaffairs.com, 2 November 2026 (multimodal agentic coding positioning; visual coding, creative design and 3D tasks). Parameter figures (1.6 trillion total, ~48 billion activated per token) are reported but disputed — a report noted the same figures were attached to LongCat-2.0 / carried across to the preview — and are presented here as reported, not settled. No hands-on testing was performed for this article, and no benchmarks, prices, or availability beyond the sources above are claimed.

SemiAnalysis GDPx: The Best AI Model Scores Just 12% — What That Actually Means for Developers

Paul Lovelace — Mon, 02 Nov 2026 05:48:11 +0000

Nothing here is sponsored — no affiliate links on this page. Facts below come from the sources listed at the end, checked 2 November 2026. We have not tested GDPx hands-on, and we have not run any of these models on its tasks.

SemiAnalysis published a new benchmark on 2 November 2026, and its headline number is deliberately uncomfortable: the best frontier AI model scores just 12%. That is not a typo, and it is not a claim that AI agents are useless. It is a claim about what today's agents can — and cannot — do when they are asked to do real professional work, end to end, inside a realistic environment, instead of answering a well-scoped question in one shot.

How we put this together

We verified the story against SemiAnalysis's original GDPx publication of 2 November 2026 and the v1.0 leaderboard coverage the same day. We have not run GDPx tasks ourselves, so nothing here is a hands-on finding. Every number below is labelled with where it came from, and the limits section is not a footnote — it is half the story.

Verdict: Do not read 12% as "agents don't work." Read it as "agents are still early at sustained professional work." If you build with agents, GDPx is a useful reality check for where to trust them, where to keep a human in the loop, and which model is strongest for which kind of work — because the leaders are not the same model in every domain.

What GDPx actually is

GDPx covers 11 domains that SemiAnalysis picked not by their share of GDP, but by where it believes frontier intelligence will earn the highest return in the next couple of years: chip design, hardware design, and materials science; cybersecurity, biology, and alignment; finance, legal, and quant trading; recursive self-improvement (RSI); and software engineering. Government, real estate, and insurance are deliberately left out. The argument is blunt: AI capability will not diffuse evenly across the economy, so a benchmark that weights every sector equally would mislead you about where frontier models actually matter.

Each domain was built with a specialised partner — for example, chip design with Aria, Arcverex, and Ergodex; cybersecurity with Arithmetic; biology with Latch Bio; finance with Living Context; legal with Chakra; quant trading with Third Moment; and software engineering with Datacurve. SemiAnalysis says every partner had to pass its agentic quality-assurance process on the first try, with only minor mistakes at worst, and that it dropped prominent partners who failed that bar.

That partnership model is the point. OpenAI's earlier GDPval benchmark, released in September 2025, is still widely cited on model cards, but SemiAnalysis argues it was designed before agents were really a thing: every task was precisely specified and non-interactive, with all the context spoon-fed in the prompt. GDPx tasks, by contrast, put the agent inside a simulated work environment and make it gather context itself.

The finance example makes the difference concrete. One GDPx finance task is seeded by a real transaction — a private-equity fund buying about 62% of a snack company for $880 million plus an earnout — with roughly 4,000 anonymised files across the target's virtual data room and the deal folders of the buyer, the sell-side banker, and the accounting advisor. The agent, working from one party's perspective, has to navigate a roughly 2,000-file deal room to find what it needs, just as a real associate did.

Other domains are built the same way: cyber tasks based on real zero-days with multiple running services, materials-science tasks inside simulated laboratories with battery cyclers and a transmission electron microscope, and hardware-design tasks in live Siemens NX sessions tested on real AWS FPGA instances. Tasks generally allow up to 8 hours, models run in their native harness where one exists — Claude Code for Opus 5.5, Codex for GPT-6 Astra, Antigravity for Gemini 4 Carbon, OpenCode otherwise — and the headline score is pass@1 across three attempts, with all domains weighted equally.

The leaderboard: 12% at the top, 0% in finance and legal

On GDPx v1.0, the headline scores are: Claude Opus 5.5 (Anthropic): 12.0% — best overall; Gemini 4 Carbon (Google): 10.9% — second; GPT-6 Astra (OpenAI): 9.6% — third. OpenAI and Anthropic generally dominate the top of the ranking, SemiAnalysis says, while other labs and open-weight models are meaningfully behind. Gemini 4 Carbon is, in its words, "a real improvement from Google and the only model in the same ballpark as Opus and Astra."

The domain winners are spiky, and that spikiness is itself the story. Opus 5.5 wins quant trading, hardware design, and chip design, and is the best all-around model. Gemini 4 Carbon leads biology and edges out the win in software engineering — the domain most developers will care about first. GPT-6 Astra wins convincingly for recursive self-improvement and is also best for materials science. Finance and legal: basically 0% for every model. SemiAnalysis says its finance and legal tasks are so challenging that basically every model scores exactly 0, and that for legal tasks, no redline produced across 20 rollouts and four models was usable. Not one.

There is an important qualification, and SemiAnalysis states it plainly: Opus 5.5 and GPT-6 Astra have "sandbagged" overall scores because their safety classifiers sometimes refuse tasks in cybersecurity, biology, and alignment. Exclude those three domains and the ranking shifts. The same effect explains a striking sub-result: Muse Wonder Full, with fewer refusals, ranks top on cyber by a meaningful margin, and SemiAnalysis calls it "actually the best available cyber model today." On cost versus performance, the picture it describes matches everyday experience with the models: Luna and DeepSeek fight for the low end, Opus wins the high end, and OpenAI claims the middle.

What this means for developers, honestly

Stop picking a model on a single headline score. GDPx's whole argument is that a general score hides the differences that matter. The best software-engineering model on this benchmark is not the best overall model, and the best cyber model is not either of the top two overall. If you are choosing an agent for a specific job, look at the domain score for that job — and at the cost curve for the volume you actually run.

Agents are good at some professional work and nowhere near done at others. A 12% top score on 8-hour, environment-rich tasks is not a reason to dismiss agents — the tasks are deliberately frontier-hard, and binary grading gives no partial credit for a mostly-right answer. But it is a strong reason not to hand an agent an unsupervised finance or legal workflow today.

Safety classifiers are now a performance variable, not just a policy footnote. If a model refuses cyber or biology tasks that another model completes, that refusal shows up in its score — and in your product. When you evaluate models for a sensitive domain, test refusals explicitly, not just capability.

Benchmarks themselves need the same scepticism as model claims. SemiAnalysis is candid that building a good broad benchmark is hard — it says its own quality process flags nearly 50% of tasks in Terminal Bench 4.0 as broken — and that a benchmark can be gamed by iterating tasks until they pass quality checks. GDPx will be updated every 3 to 6 months, which means today's ranking is a snapshot, not a verdict. Treat GDPx as one strong signal, cross-checked against your own tasks, not as a replacement for testing on your own work.

What GDPx does NOT prove

It does not prove agents are failing. The tasks are designed to be hard for the right reasons, with binary grading and no partial credit. A low score on frontier-hard tasks is compatible with agents being genuinely useful on easier, well-scoped, supervised work.

It does not prove any model is "best" in general. The domain spikes cut against any single-winner story. The honest summary is a table, not a trophy.

It does not settle the finance and legal question. A 0% result on extremely hard tasks tells you those workflows are not agent-ready on this benchmark's terms. It does not tell you that agents cannot help with narrower, supervised pieces of finance or legal work.

We have not verified these results independently. This article reports SemiAnalysis's published benchmark and its own description of its methodology. We have not run GDPx tasks, and no hands-on testing is claimed.

The useful takeaway is narrower, and more actionable, than the headline. Agents have moved from answering questions to doing multi-step work inside realistic environments — and when you measure them that way, the gap between the best model and a finished professional job is still large, uneven across domains, and sensitive to safety refusals. Build with that gap in mind: pick per domain, supervise the hard parts, and test on your own tasks before you trust any leaderboard — including this one.

Sources

SemiAnalysis, "GDPx: Measuring Frontier Model Capabilities Across the Most Valuable Domains," newsletter.semianalysis.com, 2 November 2026 (original benchmark publication; domain list, methodology, domain winners, safety-classifier qualification, cost/performance summary); Crypto Briefing, "SemiAnalysis unveils GDPx benchmark, and the best AI model scores 12%," 2 November 2026 (v1.0 leaderboard: Opus 5.5 12.0%, Gemini 4 Carbon 10.9%, GPT-6 Astra 9.6%; 3–6 month update cadence); AI Brief / Daily AI Brief, 2 November 2026 (8-hour task limit, native harnesses, pass@1 across three attempts, equal domain weighting). No hands-on testing was performed for this article, and no benchmarks, prices, or availability beyond the sources above are claimed.

DeepSeek Super-agent: A Proactive Open-Source Coding Agent Prototype — What It Actually Is, and What It Is Not Yet

Paul Lovelace — Sun, 01 Nov 2026 11:51:03 +0000

On 31 October 2026, DeepSeek's Harness team published dsh-superagent, an open-source research prototype for a proactive coding agent. It is available as deepseek-ai/dsh-superagent-prototype on GitHub, under the MIT licence. The headline is easy to misread, so it is worth being precise: this is a prototype for reference, not an official DeepSeek product, and it is not identical to DeepSeek's internal version.

What it actually is

In the project's own words, dsh-superagent is a proactive coding agent for one GitHub repository, packaged as a bundle for DeepSeek Harness (dsh). It listens to GitHub and, optionally, Feishu. When someone who is allowed to use it asks for work, it opens a work item, works on it in its own agent session and directory, and answers in the original conversation — for example, with a pull request. A web panel shows what needs a person.

That design matters more than the word "super-agent". The point is not that the agent works unsupervised forever. The point is that it is designed to take as little human attention as possible while giving as much value as possible. Because an agent that can act for a whole team can also waste a whole team's attention, it is meant to act only when it has a good reason to do so.

The repository also sets out the thinking behind that trade-off in a series of numbered documents, covering philosophy, the domain model, authorisation, execution, prompts, the panel, deployment, architecture and a cookbook for adding a source. The accompanying article, "Exploring Super-agent Design: Towards a More Autonomous Agent System", explains the direction of travel.

What it is not yet

First, it is not a finished product. DeepSeek describes it as a research prototype for reference only. Some designs discussed in the accompanying article are directions for future development and are not implemented in the published code.

Second, it is not a general-purpose agent for every repository, tool or team workflow. It is scoped to one GitHub repository at a time, with Feishu as an optional source. That narrow scope is deliberate: it makes authorisation, execution and review tractable.

Third, it is not a replacement for human judgement. The web panel exists precisely because some items need a person. The prototype's value depends on operators deciding who is allowed to ask it for work, what it may change, and when a human must step in.

Why developers should care

For developers, the interesting question is not whether this prototype will replace coding agents, but what it suggests about the next step beyond prompt-and-response tools. A coding agent that watches a repository, picks up a request in context, does the work in its own session and returns to the same conversation is closer to a team member with a narrow job than to a chatbot with a code editor.

That also raises practical questions that teams should test before trusting any such system: How are permissions granted and revoked? What happens when a request is ambiguous? How is work reviewed before it lands? And how much attention does the agent consume when it is wrong?

How to try it

The repository's setup is itself agent-assisted: the suggested route is to ask a coding agent to read SETUP.md in the repository and set up dsh-superagent with you. It asks one short question at a time, shows the full plan once, and then installs and configures the system. Developers can also read the numbered documentation in order, since each document builds only on the ones before it.

The bottom line

DeepSeek Super-agent is best understood as an experiment made public: a proactive, MIT-licensed coding-agent prototype that shows one way to reduce the attention cost of agent-assisted development, without pretending that the hard problems of authorisation, review and trust are already solved. Treat it as a reference design to study, test and adapt — not as a finished product to deploy blindly.

Source: https://github.com/deepseek-ai/dsh-superagent-prototype

Canonical: https://toolsdig.com/posts/deepseek-super-agent-proactive-coding-prototype.html

OpenAI Is Merging Your ChatGPT and Codex Allowances Into One Shared Pool in December — Explained Honestly

Paul Lovelace — Sun, 01 Nov 2026 04:45:19 +0000

OpenAI is about to change how your subscription is metered, and if you split your day between chatting and coding, you will feel it. Starting in December 2026, ChatGPT and Codex will draw from one shared token-based allowance for Plus, Pro and Business subscribers. Two buckets become one pool. That sounds like a simplification — and in some ways it is — but it also means a heavy afternoon of Codex work now competes directly with the allowance you would otherwise spend in ChatGPT.

Nothing here is sponsored — no affiliate links on this page. This breaking article is not the daily buyer-intent post. Facts below come from the sources listed at the end, checked 1 November 2026. Where OpenAI has not published a detail, we say so plainly instead of filling the gap.

What is actually changing

Today, ChatGPT and Codex each have their own usage allowance. From December 2026, Plus, Pro and Business subscribers get one combined allowance across both products. Everything you do in ChatGPT's agent features and in Codex — through ChatGPT, your code editor, or the terminal — draws from the same pool.

OpenAI links the change to bringing ChatGPT Work's agent features into the main ChatGPT experience. Codex, the company's coding tool for engineering work, is being folded more fully into that ecosystem, and a single meter follows naturally from that.

Usage is measured in tokens, and how fast you burn through the pool depends on what you ask for. Advanced models and complex tasks generally use more; a quick question costs far less than a long agentic coding run. That is the same token-based logic OpenAI moved to in April 2026, when it replaced per-message estimates with credits per million tokens — a system designed to reflect the real computational cost of different tasks rather than treating every message as equal.

Who this hits

Plus subscribers — chat and Codex now share one allowance. If you code with Codex on weekends and chat during the week, the two now draw from the same well.
Pro subscribers — same shared pool, with the plan structures that already differ: Pro plans do not carry a 5-hour limit, while Plus and Business plans do, and Pro users may still face weekly caps. How those weekly caps interact with the combined allowance is one of the open questions below.
Business subscribers — one metered balance to track and forecast instead of two. For a team, that is arguably the cleanest win here: a single number for budgeting, rather than two allowances that run dry at different times.
Free users — not covered by this change. The shared pool is a paid-tier change only.

What stays outside the meter

One important carve-out: Instant chat will not draw from your usage. OpenAI states this explicitly. So your quick, lightweight chats are not competing with your coding runs — only the heavier, metered work draws from the pool. If most of your ChatGPT use is light chat, this change may barely touch you.

What happens when you hit the limit

Three options, unchanged in shape from today:

Wait for the reset. Combined remaining usage and reset times will be visible under Settings → Usage, so you can see exactly where you stand instead of guessing across two products.
Upgrade your plan. A higher tier buys a bigger pool.
Buy credits for eligible features. For features where credit purchase is offered, you can top up rather than wait.

OpenAI expects most users will not need to wait for resets more often than they do now. Treat that as OpenAI's own expectation, not a guarantee — it is a forecast about typical usage, and heavy users are exactly the people whose experience will test it.

The practical consequence: plan your month, not just your day

Here is the shift that matters in practice. Under separate allowances, a Codex-heavy week could leave you locked out of coding while chat allowance sat unused — annoying, but contained. Under one pool, the trade-off moves inside your own account: a big Codex sprint on Monday eats the allowance your Thursday brainstorming would have used. The flip side is just as real — allowance that used to sit stranded in one product can now cover the other.

For developers, that is mostly good news: no more running dry in Codex while ChatGPT credits go untouched. For teams on Business plans, the single balance is easier to forecast. But for anyone who leans heavily on both products in the same month, the new discipline is simple — check Settings → Usage before starting a big run, and remember that the expensive model on a complex task burns the pool fastest.

What OpenAI has NOT published — and why it matters

No exact December date. OpenAI has said December, not a day. Do not trust any post that claims a specific launch day yet.
No per-plan allowance amounts. Nobody outside OpenAI knows yet how big each plan's shared pool will be, so nobody can honestly tell you whether your plan gets effectively bigger or smaller.
How weekly Pro caps interact with the combined pool is still unclear, as is whether Plus and Business users will find their 5-hour limits more restrictive once Codex draws from the same balance.

That last point deserves emphasis, because OpenAI's allowance numbers have moved before. In October 2026 it doubled Pro 100 and Pro 500 allowances and cancelled a planned reduction for Pro 200 — after notifying subscribers of the shared-pool change at checkout without giving a start date or plan allowances. Anyone building workflows around current limits should expect the numbers to move again.

How this fits the last few weeks

This is the second OpenAI usage change in days, and it is easy to confuse with the first. On 30 October, OpenAI reversed a planned ChatGPT Pro cut and doubled Work and Codex limits — that was the old story, already covered here. The shared pool is the new one: it does not change how much you get (amounts are unpublished), it changes how what you get is counted. Separately, Pro and Business subscribers are also in line for monthly API credits — a different benefit, not part of this pool. Keep the three stories apart, and you will read December's announcement correctly when it lands.

The bottom line: one pool is simpler to understand and fairer in one specific way — your allowance follows you between chat and code instead of being trapped in one product. But simplicity is not the same as generosity. Until OpenAI publishes the date and the amounts, the honest position is: watch Settings → Usage in December, keep your heavy runs deliberate, and do not let anyone sell you a number that does not exist yet.

Sources: OpenAI Help Center, "Understanding ChatGPT and Codex usage limits" (updated 31 October 2026), via the reporting below; TokenPost, "OpenAI Will Combine ChatGPT and Codex Usage Allowances in December", 31 October 2026, https://www.tokenpost.com/news/technology/45608 ; CryptoBriefing, "OpenAI to merge ChatGPT and Codex token allowances in December 2026", 31 October 2026, https://cryptobriefing.com/openai-unifies-chatgpt-codex-token-allowance/ ; PANews, 1 November 2026; Automater.ai, analysis of the OpenAI Help Center page.

Vercel's agent-desktop Gives Your Coding Agent Hands on the Whole Desktop — Without Screenshots, Explained Honestly

Paul Lovelace — Sat, 31 Oct 2026 17:38:24 +0000

Vercel's agent-desktop Gives Your Coding Agent Hands on the Whole Desktop — Without Screenshots, Explained Honestly

Vercel Labs has open-sourced agent-desktop, a tool that lets a coding agent operate native desktop apps on macOS, Windows and Linux — and it does so without taking a single screenshot. Announced on X late on 30 October 2026 ("Computer use for your agents", 23:48 UTC), version 1.0.2 shipped the same day under Apache-2.0. If you have ever watched an agent fumble at pixel coordinates, this is the release that tries to end that era: instead of guessing where a button is in an image, the agent reads the app's own structure and clicks the named element.

Nothing here is sponsored — no affiliate links on this page. This breaking article is not the daily buyer-intent post. Facts below come from the four sources listed at the end, checked 31 October 2026. Where a figure comes from the builder rather than an independent test, I label it as self-reported.

What it actually is

agent-desktop is a Rust CLI plus a C library, not an agent. That distinction matters, and Vercel's docs are explicit about it: it embeds no LLM, has no GUI, and has no reasoning loop of its own. Every command prints one JSON envelope and exits. Your coding agent — any shell-capable one — supplies the judgement; agent-desktop supplies the hands.

Think of it as the desktop sibling of agent-browser. Web pages stay with agent-browser. Native apps — Slack, VS Code, Notion, Apple Maps, a settings panel, a desktop installer — are agent-desktop's territory. For the web contents inside a Chromium or Electron app you launch, it can open a DevTools port that agent-browser connects to, so the two tools hand off rather than compete.

Install is one command: npm i -g agent-desktop (Bun, Yarn and pnpm work too). The package bundles native binaries for x64 and ARM64, plain CPU, no GPU needed.

Why the accessibility tree beats screenshots

Most computer-use systems work the way a human with only eyesight would: take a screenshot, find the button in the image, click at those pixel coordinates. That costs tokens — Anthropic's own docs put each screenshot at roughly 1,000 to 1,800 input tokens, plus about 4,500 tokens for the tool definition on every request — and it breaks whenever a window moves, scales, or re-renders slightly differently.

agent-desktop reads the operating system's accessibility tree instead: the logical structure of buttons, fields and menus that apps already expose to assistive tools. On macOS that is the AX API, on Windows UI Automation, on Linux AT-SPI. The agent gets a JSON snapshot with a ref for every element it can act on, acts on the ref, then snapshots again to verify. No pixel matching anywhere in the loop.

That structural view is also what makes it cheap in principle. A screenshot is a picture of everything; a tree is a list of only what can be acted on, and it can be pruned.

How the snapshot/ref loop works

The loop is deliberately boring, and that is the point:

Snapshot. The agent asks for a snapshot of an app and gets JSON back, with a qualified ref per element (for example @s8f3k2p9:e8). The snapshot ID inside the ref makes it self-describing — a bare @e8 is rejected with INVALID_ARGS.
Act. The agent acts on a ref — click it, type into it, read it — through the accessibility API.
Verify. The agent snapshots again and checks that the UI actually changed as expected.

If the interface changed between snapshot and action, the action does not guess. It returns STALE_REF or AMBIGUOUS_TARGET, and the agent takes a fresh snapshot. Every error carries a disposition telling the agent whether a retry is safe. Ref resolution fails closed rather than clicking the wrong thing — a design choice that matters a lot when an agent has its hands on your real desktop.

Dense apps are the hard case: an Electron app can expose thousands of accessibility nodes. agent-desktop handles that with skeleton snapshots — read only 3 levels deep, see each cut container's children_count, then drill into one region with snapshot --root and work only there. Map the outline first, then open one drawer at a time, instead of dumping the whole tree on every look.

And it runs headless by default. Ref actions go through the accessibility API without moving the pointer or taking focus, so an agent can work in the background while you keep using the machine — and, in principle, several agents can work on one app at once. The global --headed flag is the explicit opt-in when physical input is actually needed. Every ref action also auto-waits up to 5,000 ms for a visible, enabled, stable target.

What you need to run it

macOS 13+, Intel or Apple Silicon — grant Accessibility permission (agent-desktop permissions --guide).
Windows 10 1809+ or Server 2019+, x64 or ARM64 — no extra grant needed for apps at your terminal's integrity level.
Ubuntu 24.04+, x86_64 or aarch64 — a graphical session with at-spi2-core.

There are 60 command names, 56 operational. Four — key-down, key-up, mouse-down, mouse-up — fail closed until a daemon can release a held key or button, so do not plan a workflow around held keys yet. Agents learn the tool from bundled docs via agent-desktop skills get desktop, and a C library (libagent_desktop_ffi) lets Python, Swift, Go, Ruby and Node hosts call it in-process instead of shelling out to the CLI each time.

Who this actually helps

Developers automating desktop apps. If your test or workflow lives in a native app with no API, this is a structured way in — no screen-scraping, no fragile pixel coordinates.
Agent builders. If you already run a coding agent, agent-desktop is a tool it can call, not a new agent to adopt. It is model-agnostic, so it does not lock you to one provider's computer-use API.
Teams running agents alongside humans. Headless-by-default actions that do not steal focus are the difference between "an agent helps on this machine" and "an agent hijacks this machine". That is the practical win here.
Cost-watchers on dense apps. If the skeleton numbers hold up in your app, reading one region instead of the whole window is a real token saving on long tasks — but see the caveats below before budgeting on it.

What it does NOT do

It is not an agent. No model, no planning, no loop. Pointing it at a task without an agent driving it does nothing.
It does not automate web pages. That is agent-browser's job.
It cannot see apps with no accessibility tree. If an app does not expose its interface to the OS accessibility APIs, agent-desktop cannot reach it, full stop.
It is not a cursor. The launch posts talk about parallel cursors; the shipped default is headless structured actions, not pointer movement. Physical input needs --headed.

The honest caveats — read these before you quote the numbers

The token-cut figures are self-reported. The 78–96% cut on dense Electron apps (Slack, VS Code, Notion) and the Apple Maps example — 3,811 tokens per look falling to 273 with skeleton drilling, and a simulated 52-step task falling from 198k to 31k tokens — come from the builder's own posts. There is no independent computer-use benchmark for agent-desktop yet, and no public comparison on standard computer-use tests. Treat those numbers as a promising claim from one simulated task, not a measured result.
Results will vary by app. Accessibility-tree tools depend entirely on how well each app exposes its interface. A well-built app gives a clean tree; a sloppy one gives a messy or incomplete one, and your mileage will follow the app, not the tool.
Apps with no accessibility tree are out of reach. This is a hard limit, not a rough edge.
Private desktop content is in scope. The README says it plainly: snapshots, clipboard reads, screenshots, command output and debug artifacts can contain private desktop content. Keep them out of public logs and uploads, and give an agent a machine or account scoped to the work. An agent that can read every app can also read whatever those apps show.
Version history is short. The repository dates to February 2026, version 1.0.0 reached npm on 28 October 2026, and 1.0.2 is the current release. This is a young tool with a fast-moving surface — check the README before building anything load-bearing on a command name.

The bottom line

agent-desktop is a small, sharp idea executed in the right place: give agents the app's own structure instead of a picture of its pixels, make every action verifiable and fail-closed, and keep the agent out of the user's way by default. If the skeleton savings survive independent testing, it could make desktop automation meaningfully cheaper as well as more reliable. But today it is a promising open-source tool with builder-reported numbers and no benchmark — worth trying on a scoped machine, not worth quoting as proven savings yet.

Install it, point your coding agent at one well-behaved app, and watch the snapshot/ref loop do its work. That first afternoon of testing will tell you more than any launch post.

Sources: MarkTechPost, "Vercel Labs Open-Sources agent-desktop for Agent Computer Use", 31 October 2026, https://www.marktechpost.com/2026/10/31/vercel-labs-agent-desktop-computer-use/ ; CellCog, "Vercel's agent-desktop Gives Agents Computer Use", https://cellcog.ai/blog/vercel-agent-desktop/ ; Subagentic, "Vercel Labs ships agent-desktop for coding agents", https://subagentic.ai/posts/vercel-labs-agent-desktop/ ; AlexTech.ai, "Vercel open-sources agent-desktop to use PC apps without screenshots", https://www.alextech.ai/en/news/vercel-open-sources-agent-desktop-to-use-pc-apps-without-screenshots/ ; GitHub repository vercel-labs/agent-desktop and docs at agent-browser.dev, via the sources above.

Full version with FAQ: https://toolsdig.com/posts/vercel-agent-desktop-computer-use-no-screenshots.html