gemini-2.5-flash, the answer to “should I move?” is almost certainly yes — but the migration is not a simple model-ID swap. The Gemini 3.x family changed the thinking config, dropped the classic sampling knobs, and tightened the function-calling contract. Here is what I’d hand a teammate on day one of the cutover.
Hold the model name fixed at Flash and look at the deltas that matter for a production agent:
thinking_level is a string enum (minimal → high), and medium is the new default. The model is tuned for it, and chain-of-thought scaffolding in your prompts is now actively counterproductive — simpler prompts at medium beat elaborate CoT at low.One thing, and it matters: price.
The fix on cost is almost always the same: aggressive prompt caching ($0.15/M cached is the cheapest token Google sells), and thinking_level: 'minimal' or 'low' on routes that don’t need reasoning.
- model = "gemini-2.5-flash"
+ model = "gemini-3.5-flash"
GA, no preview suffix. Available in the Gemini API, AI Studio, Antigravity, the Gemini app, and AI Mode in Search.
temperature, top_p, top_kThese are no longer recommended on any Gemini 3.x model. The reasoning is tuned for default sampling; passing custom values is a net-negative on most evals I’ve seen.
- generation_config = {
- "temperature": 0.2,
- "top_p": 0.9,
- "top_k": 40,
- }
+ # leave sampling at defaults on 3.x
If you were using temperature=0 for determinism, you’re going to need a new strategy — usually thinking_level: 'minimal' plus a stricter system prompt and schema-constrained output.
thinking_budget → thinking_levelThe integer budget is gone. Replace it with the string enum.
- thinking_config = ThinkingConfig(thinking_budget=7500)
+ thinking_config = ThinkingConfig(thinking_level="medium")
Mapping I’ve been using as a starting point (adjust per route):
Old (thinking_budget) |
New (thinking_level) |
|---|---|
0 / disabled |
minimal |
~1k–3k |
low |
~5k–10k |
medium (new default) |
>10k |
high |
Important gotcha if you’re coming from gemini-3-flash-preview rather than 2.5: the preview defaulted to high. 3.5 GA defaults to medium. If your eval scores quietly dropped after the model-ID swap, this is almost certainly why — set thinking_level: 'high' explicitly to restore the previous behaviour.
FunctionResponse partsThe function-calling contract is stricter now. Three requirements you must satisfy or the call will be rejected / hallucinated around:
id must match the original FunctionCall.id — you can no longer get away with omitting it.name must match the call’s name. response_part = Part.from_function_response(
+ id=call.id,
name=call.name,
response={"result": tool_output},
)
Two related cleanups while you’re in this file:
Part.3.5 Flash punishes the prompting habits that 2.5 Flash rewarded.
thinking_level: 'medium' (or 'high') and let the model do the reasoning natively. I’ve seen 5–10% accuracy gains from removing CoT prompts on 3.5.media_resolution_high. Video usage typically goes down. Re-baseline both before you trust your cost projections.temperature / top_p / top_k. Re-run.thinking_budget → thinking_level using the table above. Re-run.FunctionResponse site: add id, verify name, ensure 1:1 with the call.The TL;DR: the model is meaningfully better at exactly the workloads most teams are running (agents, tool-use, coding) and the migration is mostly a config-and-prompt cleanup rather than an architectural change. Budget a day for a small team, two days if your function-calling layer is non-trivial.
— Priyanshu
Sources:
Gemini 3.5 is the new frontier family. The framing Google used — “frontier intelligence with action” — is the giveaway. 3.5 is being positioned less as a benchmark-chasing release and more as the substrate the rest of the agentic stack runs on. Gemini 3.5 Flash was the SKU shown end-to-end on stage; the bigger sibling was alluded to but not benchmarked head-to-head against Opus 4.7 or GPT-5.5, which tells you something about where Google wants the conversation to go.
Gemini Omni is the more interesting release. “Any input to any output, starting with video” is the pitch. The demos that landed were the editing ones — point at a frame, describe the change in natural language, get a coherent edit back across the rest of the clip. This is the first time I’ve seen a multimodal model where video editing felt like a first-class output modality rather than a party trick stitched onto an image model.
This is the part of the keynote I’ll remember. Five separate product launches, all of them agents, all shipping into surfaces that already have hundreds of millions of users:
Three things stood out to me, and I think they’re going to shape the rest of the year:
1. Google is now competing on distribution, not model quality. The model announcements were almost a formality. The keynote spent its minutes on what the models do inside Gmail, Docs, Keep, Drive, Search, and the Gemini app. When your moat is a billion-user surface area, the model is a feature; the agent on top of it is the product. Anthropic and OpenAI do not have this lever, and yesterday made that asymmetry very visible.
2. The “agentic in everything” pivot is now industry-wide. Microsoft has Copilot agents, Anthropic has Claude with computer-use and tool ecosystems, OpenAI has Operator-class products, and now Google has shipped its own coherent agent layer end-to-end across consumer and developer surfaces in a single keynote. The interesting question for buyers in Q3 is no longer “which model is best” — it’s “whose agent layer integrates with our system of record.” That is a very different procurement conversation.
3. Antigravity is the one to watch for developer tooling. The agentic-IDE space has been fragmenting fast. Google entering with first-party access to Gemini 3.5 + Omni + the Workspace graph is a different kind of entrant than the startups in this category. I expect a real fight over the next two quarters.
The headline yesterday wasn’t “Google shipped Gemini 3.5.” It was “Google stopped shipping a model and started shipping an operating layer.” That is a different company than the one that showed up at I/O 2024.
— Priyanshu
Sources:
Anthropic’s compute deal with SpaceX is the structural story of the week. 220K+ GPUs at Colossus 1, doubled Claude Code rate limits, and gigawatt-scale orbital data-centre talks. The capex race is now openly the lever pulling everything else. (I wrote about this on Tuesday — see the previous post.)
CAISI’s pre-launch agreements with Google, Microsoft, xAI. Pre-deployment government evaluation moved from voluntary commitment to formal-and-repeated. This is going to start showing up as a procurement-checklist item by Q4. Anthropic has had a separate arrangement; OpenAI’s status is less clear. Watch for the next labs to sign on.
DeepSeek V4-Pro is the #2 open-weights model on Artificial Analysis’s intelligence index. Behind only Kimi K2.6. Open-weights gap on reasoning is single-digit-percent territory now. MIT licence on V4 makes it deployable in places Llama Community Licence isn’t. (Wrote about this last week.)
MCP roadmap update is worth reading. The 2026 priorities are unglamorous but exactly right: audit trails, SSO-integrated auth, gateway patterns, async/long-running tools, configuration portability. The protocol won the integration layer. Now the boring work of enterprise-readiness gets done. The community link is below.
Quiet shift in the agent stack: the move from “frameworks” to “primitives”. The trend through 2024 was full-stack agent frameworks — opinionated, vertically integrated. The trend in 2026 is people composing MCP servers + a stateful orchestrator (LangGraph or similar) + their own evaluation harness, instead of buying a framework. We made that move last quarter and the operability gain was real.
GPT-5.5 (“Spud”) shipping under the GPT-5 brand instead of GPT-6. OpenAI held the line on what counts as a major version. Industry-restraint signal. Worth watching whether competitors follow suit; the model-versioning hype cycle has been a problem for buyers.
Take care of yourselves. See you next week.
— Priyanshu
Sources:
The model itself is positioned as an incremental upgrade over Opus 4.6:
Pricing-flat-with-quality-up is the move I’ve been expecting from all the frontier labs as competition tightens. Worth noting that the headline numbers don’t move; the unit economics do.
The structurally interesting announcement. Anthropic signed a deal with SpaceX for the entire compute capacity at Colossus 1:
Yes, orbital. The pitch for space-based compute is solar (constant illumination), thermal (radiative cooling against deep space), and political (jurisdiction, supply-chain redundancy). Whether it’s actually economical at scale is a different question, but the fact that it’s being seriously discussed at the GW scale by an organisation that ships product is worth filing away.
The downstream effects are immediate:
The compute war is here. The frontier labs are now openly trading capital for capacity in ways that show up as customer-facing rate limits. Operating at the frontier is a capex question first, R&D question second.
The duopoly dynamic is real. Anthropic at $30B annualised, OpenAI at $24B, both racing to lock in compute. The mid-2025 view that the field would have 4–6 frontier labs is now harder to defend. Most of the rest are de-facto open-source partners or cloud-vendor offerings.
Vendor risk is back on the agenda. When two companies are responsible for most of the inference for the GenAI economy, single-vendor dependency starts costing real procurement points. Build for vendor-neutrality (MCP, abstracted model calls) accordingly.
We doubled our Claude Code allocation today and used it. The new Opus is genuinely better. If the orbital data-centre piece comes together, this gets even more interesting.
Sources:
This is the first concrete instance I’ve seen of pre-launch evaluation moving from voluntary commitments to a formal, repeated process. It deserves more attention than it’s getting.
The reported scope:
CAISI also recently published its evaluation of DeepSeek V4-Pro following V4’s April release — separate work, but the same body, and a useful signal that they’re scaling up evaluations across both U.S. and overseas frontier labs.
Worth being clear about the limits:
Compliance buyers will want to see the evaluation report. If you’re advising a regulated client on model selection, the CAISI report is becoming the artefact you’ll be asked about. Not the model card. Not the system card. The independent evaluation.
The pre-launch window is shifting. Labs that have been comfortable with “ship fast, eval after” are facing a structural pressure to delay launches for evaluation. This shows up downstream as longer pre-release windows, more cautious staged rollouts, and (sometimes) features held back at launch.
Cross-border models become a separate question. A model evaluated by CAISI is in a different operational risk category — for U.S. enterprise procurement — than a model that wasn’t. This isn’t legally required (yet), but it’s becoming a procurement-checklist item at large enterprises.
This is the kind of slow, mostly-procedural development that won’t make AI Twitter trend, but will substantially shape what enterprise AI procurement looks like in 2027. We’ll start seeing CAISI-evaluation status as a vendor-comparison axis. Plan accordingly.
Sources:
]]>The headline:
MIT. Not a Llama-style “community licence” with monthly-active-user carve-outs — a genuinely permissive licence that allows commercial use, modification, and redistribution.
On the Artificial Analysis Intelligence Index for open weights, V4-Pro is now #2, behind only Kimi K2.6. On the GDPval-AA agentic-real-world-tasks benchmark, V4-Pro Max scored 1554, beating Kimi K2.6 (1484), GLM-5.1 (1535), GLM-5 (1402), and MiniMax-M2.7 (1514).
Coding-specific: V4-Pro now outperforms most closed flagships on Codeforces, LiveCodeBench, and Terminal-Bench. The “open-weights gap” on coding has effectively closed.
Three concrete shifts I’m thinking about for our roadmap:
One. For workloads where the cost-per-token math has been borderline (high-volume RAG, agentic pipelines that burn tokens on tool-calling intermediate steps), V4-Flash on self-hosted infrastructure is now competitive on quality with where Claude Sonnet was twelve months ago. The unit economics shift.
Two. For reasoning-heavy workloads — Text2SQL on complex schemas, code agents, multi-step plans — V4-Pro is the first open-weights model I’d seriously consider against the closed flagships. The activation count (49B per token) means you can serve it on a node a lot of teams already have provisioned.
Three. MIT licence changes the conversation in regulated industries. The Llama Community Licence is a non-starter at some financial-services and healthcare clients I’ve worked with — their legal teams won’t sign off. MIT clears that hurdle.
We’re now at the point where every 2–4 weeks, a frontier-class open release lands. Llama 4 in early April. Mistral Large 3 in March. Gemma 4 in April under Apache 2.0. DeepSeek V4 now. The closed-source labs still have the absolute leading edge, but the gap measured in “months until the open model is good enough for this workload” has dropped to single digits for most enterprise tasks.
If you haven’t priced an open-weights deployment into your 2026 architecture decisions, do it now.
Sources:
]]>The recap, briefly:
There are two threads to pull on here. The benchmarks, and the naming.
Pre-launch leaks pointed to GPT-6-class performance: a high-70s SWE-bench Pro score (the agentic software-engineering benchmark that’s become the headline metric for “frontier” claims), substantial improvements on long-context reasoning, etc.
The actual numbers in the system card came in lower than the leaks. SWE-bench Pro at 58.6%, well short of the high-70s rumour. Strong-but-incremental gains on most other axes.
That score is genuinely good — comparable to or above the latest Claude Opus releases on several axes — but it’s not the leap that “GPT-6” had been priced into.
The decision to ship as GPT-5.5 rather than GPT-6 is the part of this release I find most worth dwelling on.
OpenAI has been criticised — fairly — for inflating model versioning in the past (the GPT-4-Turbo / GPT-4o / o1 lineage was a mess for end users to track). Choosing to not call this GPT-6 when the benchmark didn’t land is a small but real act of restraint. It’s the right call. It also tells us something:
GPT-5.5 is a serious frontier release — particularly on coding and reasoning workloads. It’s also incremental. If you’ve already standardised on Claude Opus 4.6 / 4.7 or Gemini 2.5 Pro, there’s no urgent reason to switch. If you’re on an older GPT-4-class model, the upgrade is worth running an eval on.
The bigger story is the honesty of the renaming. We’re past the era where every release has to be the biggest one yet, and that’s a healthier place for the field to be.
Sources:
]]>Going into Q2 2026:
This release is Google saying: we have the model, we have the data, we have the cloud — now we have the agents.
Google’s competitive moat in enterprise AI is integration with what enterprises already use: Gmail, Drive, Calendar, Docs, Sheets, BigQuery, Workspace. Anthropic has MCP (and the connector ecosystem on top). OpenAI has Operator and a growing tool catalogue. Google has the data the agent should be acting on, already in their cloud.
If the agents are even competent, the integration story alone makes them a serious enterprise play. You don’t need to build connectors for the data when the data lives in the same cloud as the agent.
MCP support. Will Google’s new agents speak MCP, or push their own integration story? My bet — they’ll do both, badge MCP support as table stakes, and try to differentiate on Workspace/Cloud-native depth. The vendor-neutral protocol is too widely adopted to ignore at this point.
Enterprise SLAs. Anthropic’s enterprise lead is partly built on operational reliability — SLAs, predictable rate limits, a quieter incident history. Google’s enterprise track record on AI products is mixed (remember Bard?). The model is the easy part. Operating a model business at enterprise scale is the hard part.
We now have three credible agent platforms competing for enterprise share, plus a healthy long tail (Microsoft via Azure + OpenAI, AWS via Bedrock, Salesforce, etc). For customers, this is excellent — pricing pressure is real, multi-vendor patterns become viable. For practitioners, it means the integration layer (MCP, agent frameworks, eval harnesses) becomes more important, not less.
Pick the platform that’s strong where your data lives. Build the integrations on the standard.
Sources:
]]>We use MCP heavily at Elastiq. We’ve also tripped over most of the rough edges. A short field report on what’s actually shipped, and what’s still in the roadmap column.
A real connector ecosystem. The public MCP server registry grew from ~1,200 in Q1 2025 to 9,400+ by April 2026, and that’s just the public ones — the count of internal/private servers in enterprises is much higher. Drive, GCS, S3, Azure Blob, Slack, GitHub, Postgres, Sentry, Snowflake, Salesforce — every major data source has at least one server, often three.
Cross-vendor adoption. Anthropic open-sourced MCP. The interesting part is that OpenAI, Google, Microsoft, and AWS have all adopted it as a first-class integration surface. The protocol is genuinely vendor-neutral now, in a way it wasn’t 12 months ago.
Enterprise deployment patterns. 78% of enterprise teams with AI agents in production are now running them on MCP. The “build a connector for every model provider” anti-pattern has died.
Audit trails and SSO-integrated auth. This is the biggest gap. Out-of-the-box MCP doesn’t give you the audit story enterprise security teams want. Most production deployments have a custom logging layer wrapped around the protocol. The 2026 roadmap calls these out as priorities — enterprise readiness is the headline theme — but they’re not in the standard yet.
Gateway patterns. As MCP servers proliferate, you need to centralise auth, rate-limiting, and policy. The community is converging on a gateway pattern (an MCP-aware reverse proxy), but there’s no blessed implementation. We rolled our own.
Async / long-running tools. MCP doesn’t have a great answer for tool calls that take 30+ seconds, or that want to stream partial results back. The roadmap mentions a Tasks primitive for async agent calls; it’s not there yet.
Configuration portability. Moving an MCP setup from one host application to another (Claude Desktop → Cursor → your own product, etc.) is still more friction than it should be.
ACL propagation. I keep banging on about this. Connectors know who the user is. The LLM doesn’t have a first-class way to honour that identity downstream when it composes responses or chains calls. Solved in our shop with a custom layer. Should be in the protocol.
The protocol has won the integration layer. That’s settled. The next 12 months are about closing the enterprise-readiness gap — auth, audit, gateways, async — without breaking the simplicity that made it spread in the first place. Hard problem. Solvable.
If you’re building enterprise AI in 2026 and you’re not on MCP, the burden of proof is now on you to explain why.
Sources:
]]>Both are open-weight under the Llama Community Licence. Scout’s 10M context — supported by a technique called Interleaved RoPE that lets it generalise from a 256K training window — is the largest of any openly available model at launch.
“Is the 10M context real, or marketing?” Real, in the sense that Scout can be fed and reason over very long inputs. Real-but-caveated, in the sense that performance degrades on the long tail of the window, attention drift is real, and your inference cost scales with input tokens regardless.
“Does this kill RAG?” No. Read on.
Three things stack against the “stuff everything into the prompt” architecture, even when it’s technically possible:
Cost. Generating against 8M input tokens costs roughly 8M-tokens-worth of inference. RAG keeps your effective input small (top-K retrieved chunks), and that ratio determines your unit economics. For workloads that run thousands of times an hour, the math doesn’t even close.
Latency. Time-to-first-token scales with context length. A user-facing query at 1M tokens of context is tens of seconds in. RAG keeps the LLM call fast.
Recency and update propagation. A long context is baked at request time. RAG is evaluated at retrieval time. When your underlying corpus updates, RAG sees the change immediately. Long-context approaches need to re-stuff.
Access control. This is the one nobody mentions enough. RAG can apply ACLs at retrieval — the user only ever sees passages they’re authorised for. Long-context naively dumps everything in. Solving ACL inside a 10M-token prompt is a problem you don’t want.
Single-document workflows on huge documents. Legal corpora, code bases, full books, multi-day audio transcripts. If the entire input is one logical thing the user wants to reason over, the long-context model is the right tool.
Reduced retrieval engineering for prototypes. For internal tools and experiments where the corpus is “this one PDF” or “this one repo”, you can skip the retrieval stack entirely and ship faster.
Long-trace agentic workflows. Agents that maintain extensive history (tool calls, intermediate reasoning) benefit from windows that won’t truncate them mid-task.
The thoughtful pattern in 2026 is RAG for retrieval, long-context for reasoning over the retrieval. The two compose. They don’t replace each other.
Sources:
]]>