Gemini Native Tools and Modular-Qualcomm Reshape Inference

Two simultaneous shifts to the same layer

Google shipped native computer-use in Gemini 3.5 Flash this morning. The release lands on the inference and agent-execution layer that many teams rebuilt late in 2025. A separate event in the same layer, the Qualcomm acquisition of Modular, arrived the same day and pulls in a different direction.

Gemini 3.5 Flash ships native computer-use

Google released computer-use as a built-in tool across browser, mobile, and desktop surfaces. No scaffolding. The model itself emits structured browser and desktop actions, which collapses the agent-framework layer (Browser-Use, Claude Computer Use wrappers, LangGraph orchestration) into a model primitive. The tradeoff is framework complexity for tighter latency and lower cost per step, with reduced observability.

The thing this release doesn't tell you is how it performs on real workloads. No benchmarks were published. Easy demos will look fine, and multi-step web tasks probably land where everyone else lands, at first. The validation path is mechanical: port 20–50 representative tasks from the current agent eval onto native tool-calls and compare task success rate, mean steps to completion, p95 latency, and cost per successful task.

Qualcomm acquires Modular for $3.9B

Modular's pitch was vendor neutrality: write once in Mojo, run efficiently across NVIDIA, AMD, Intel, and emerging accelerators. The prior cases rhyme. Intel/Habana, NVIDIA/OctoML, AMD/Nod.ai. Cross-silicon parity erodes quietly once a chip vendor controls the roadmap. Qualcomm calling it 'silicon-agnostic' in the press release is the standard line; the empirical question is whether AMD and Intel backends keep getting optimization cycles in the next four quarterly releases.

A chip vendor doesn't buy a compiler company to keep it neutral.

The combined implication

A stack that looked like Mojo/MAX for inference optimization → custom agent framework for browser automation → tool-call accuracy eval harness is now under pressure on all three layers at once. Even with a single-layer dependency, the decision window is this quarter.

What to do this sprint

For the agent layer: run the Gemini native-tool eval in parallel with the existing harness for one release cycle. Define success by end state, not path taken. The old tool-call-accuracy metric breaks once the model drives the screen itself. If rankings reshuffle, and expect at least one position change, the native-tool number is the one that matches user experience.

The attack is now documented at industrial scale

Anthropic publicly accusing Alibaba of running 25,000 fake accounts to issue 28.8 million queries against Claude is the first public confirmation of model-extraction-at-scale against a frontier API. The numbers matter more than the accusation. About 1,150 queries per account sits comfortably below most naive abuse thresholds. Per-key rate limits will not catch that. Most existing telemetry will not flag it either.

The academic literature (Tramèr et al., Krishna et al.) puts 1–10M well-chosen queries in the range where a competitive distillation target is recoverable for non-trivial tasks. At 28.8M you are well past that, especially on narrow task slices where a high-quality student model is the realistic outcome. The thing the headline number doesn't tell you is how concentrated the queries were on the slices that actually transfer. That is the variable that decides whether the attack worked.

Per-key rate limits don't stop a 25,000-account distillation attack. Distribution-level monitoring does.

The defensive architecture

The blind spot is structural: per-account telemetry is useless when the campaign is distributed across 25K accounts. What measures the right thing:

• Prompt embedding entropy per account cohort — real users produce diverse, contextual queries; extraction campaigns produce systematically varied but statistically distinguishable patterns
• Account-age-to-query-complexity ratio — extraction accounts ramp to sophisticated queries faster than organic users
• Cross-account clustering — supposedly independent accounts querying the same regions of capability space at coordinated rates
• Account-creation-to-first-query latency — synthetic accounts follow different temporal distributions than genuine signups

Complementary defenses

Detection alone is not sufficient. Layer these:

1. Output watermarking or canary tokens on high-value generative endpoints, which gives you a way to identify leaked outputs downstream
2. Response perturbation for accounts with anomalous embedding distributions, degrading outputs enough to reduce distillation fidelity without affecting normal users
3. Query-budget throttling at the cohort level, not per-key, but per-cluster of accounts with similar behavioral signatures

If a model is served via API, including internal APIs consumed by partner teams, this attack shape applies. The Anthropic disclosure is effectively a free red-team report on a documented production attack pattern. The open question is whether the defense gets instrumented before someone runs the playbook against another set of endpoints or after.