ai – Software Online Review

The Hidden Cost of AI-Generated Code: Technical Debt and Quality Risk in 2026

Posted on November 4, 2026 by Filip Keser

AI coding assistants write code fast — that part isn’t in dispute. What’s less settled is what that code looks like six months later, after it’s been merged, extended, and handed off to someone who didn’t write it. A handful of named studies have tried to measure this directly, and their findings don’t fully agree with each other. This piece sticks to what those studies actually say, including where they conflict.

At a Glance

Source	Scope	Headline Finding
GitClear, “Coding on Copilot” (2024)	~153 million changed lines, Jan 2020–Dec 2023	Code churn projected to double in 2024 vs. the 2021 pre-AI baseline
GitClear, “AI Copilot Code Quality” (2025)	211 million changed lines, Jan 2020–Dec 2024, enterprise repos	Copy-pasted (“cloned”) code rose from 8.3% to 12.3% of changed lines (2021→2024); moved (reused) code fell from 25% to under 10%
Xiao et al., “Self-Admitted GenAI Usage in Open-Source Software” (arXiv, 2025)	151 repositories with explicit AI-usage mentions	Found no general increase in churn; disputes GitClear’s churn-quality link directly
Uplevel Data Labs study	785 enterprise developers, before/after Copilot rollout	41% higher bug rate for developers with Copilot access; no measurable throughput gain
Yetiştiren et al., arXiv 2304.10778	HumanEval benchmark, 3 AI tools compared	Copilot: 46.3% correct-code rate; ~9.1 minutes of estimated technical debt per generated snippet

The Productivity Story Everyone Already Knows

Most of the public conversation about AI coding assistants centers on speed: how much faster developers ship code with GitHub Copilot, Cursor, or similar tools. Stack Overflow’s 2024 Developer Survey — cited in GitClear’s own 2025 report — found that 63% of professional developers already used AI tools in their development process, with another 14% planning to. That adoption curve is real. What’s less discussed is whether the code those tools produce is as easy to live with later as the code it replaces.

What GitClear’s Data Actually Shows

GitClear, a code analytics vendor, has published two widely cited reports built from large commit datasets. The 2024 report (“Coding on Copilot: 2023 Data Suggests Downward Pressure on Code Quality”) analyzed roughly 153 million changed lines of code from January 2020 through December 2023 and defined churn as the percentage of lines reverted or updated within two weeks of being authored. Its headline projection: churn was expected to double in 2024 relative to the 2021 pre-AI baseline. The report did not publish exact churn percentages, only this doubling projection.

The 2025 follow-up (“AI Copilot Code Quality: 2025 Data Suggests 4x Growth in Code Clones”) expanded the dataset to 211 million changed lines from repositories owned by large enterprises, covering 2020–2024. Its most specific finding: copy-pasted (“cloned”) code rose from 8.3% of changed lines in 2021 to 12.3% in 2024, while “moved” code — lines relocated and reused rather than duplicated — fell from 25% to under 10% of changed lines over the same period. For the first time in GitClear’s dataset, copy/paste code volume exceeded moved code volume. The report frames this as evidence that AI-assisted development leans toward duplicating logic rather than refactoring it into something reusable.

The Academic Pushback

Not every study agrees with GitClear’s churn framing, and it’s worth being upfront about that disagreement rather than treating GitClear’s conclusion as settled fact. A 2025 arXiv paper, “Self-Admitted GenAI Usage in Open-Source Software” by Tao Xiao, Youmei Fan, Fabio Calefato, Christoph Treude, Raula Gaikovina Kula, Hideaki Hata, and Sebastian Baltes, specifically tested GitClear’s 2024 claim that rising churn signals downward pressure on code quality — and its data didn’t support it. Looking at 151 repositories with explicit, self-admitted mentions of GenAI tool usage (in commit messages, comments, or docs), the authors found average file-based churn actually fell from 0.17 to 0.06 after AI adoption (a medium effect size), and line-based churn fell from 0.68 to 0.50 (a negligible effect). Of the repositories showing statistically significant churn trend changes, only a minority trended upward faster; some trended downward. The one nuance that did hold up: “generation” tasks — producing new code, test data, or regular expressions — showed more rework-proneness than optimization or maintenance tasks using AI.

The two studies used different populations (GitClear: broad enterprise commit history; Xiao et al.: a curated set of repos where developers explicitly admitted to using AI) and somewhat different churn definitions, which may partly explain the divergence. The honest takeaway is that the “AI increases churn” claim is contested in the literature, even though it’s often repeated as settled.

Where the Duplication Concern Holds Up Better

Unlike churn, GitClear’s duplication findings haven’t been directly contradicted by the academic paper above — the Xiao et al. study didn’t attempt to measure code cloning itself, and cites GitClear’s duplication figures only for context rather than disputing them. That leaves the copy-paste trend as the better-supported half of GitClear’s thesis so far: more code is being duplicated rather than abstracted into shared functions, which is a classic driver of long-term maintenance cost even when it doesn’t show up as “churn” in the short term.

Bug Rates: The Uplevel Finding

A separate line of evidence comes from Uplevel Data Labs, which compared 785 enterprise developers (351 with GitHub Copilot access, 434 without) across matched time windows before and after Copilot rollout. The result most often cited: developers with Copilot access had a 41% higher bug rate than the control group. Critically, the same study found no measurable improvement in PR cycle time, throughput, code complexity, or test coverage for the Copilot group — the productivity gain some teams expect didn’t show up in this dataset, even as the bug-rate increase did. Uplevel itself describes the results as observational and not causal, and the sample is limited to a specific set of enterprise customers, so it shouldn’t be read as a universal verdict on Copilot.

Code Smells and Estimated Technical Debt

A 2023 academic paper by Burak Yetiştiren, Işık Özsoy, Miray Ayerdem, and Eray Tüzün — “Evaluating the Code Quality of AI-Assisted Code Generation Tools” — benchmarked GitHub Copilot, Amazon CodeWhisperer, and ChatGPT against the HumanEval problem set. On raw correctness, ChatGPT scored highest (65.2% correct solutions), followed by Copilot (46.3%) and CodeWhisperer (31.1%). More relevant to the technical-debt question: the authors estimated technical debt in minutes required to fix code smells in the generated output, finding roughly 9.1 minutes of estimated debt per snippet for Copilot’s output, 8.9 minutes for ChatGPT, and 5.6 minutes for CodeWhisperer. These are small, synthetic benchmark tasks rather than production codebases, so the absolute numbers don’t generalize directly — but they corroborate the broader pattern: AI-generated code frequently compiles and often passes tests, while still carrying maintainability costs that static analysis can detect.

Trade-offs at a Glance

Dimension	What the evidence suggests	Confidence
Code duplication / cloning	Rising — GitClear’s 2024→2025 reports; not directly disputed in the literature reviewed	Moderate
Code churn	Contested — GitClear projects an increase; Xiao et al.’s academic re-analysis found no general increase	Low / disputed
Bug rates	Higher in one controlled enterprise study (Uplevel, +41%), but observational and not causal	Moderate, single study
Code-smell debt per snippet	Measurable in benchmark tasks (Yetiştiren et al.), magnitude varies by tool	Moderate, synthetic benchmark

What This Means for Engineering Teams

None of this research supports banning AI coding assistants, and none of it supports treating their output as consequence-free either. The pattern that recurs across sources — duplication trending up, code-smell debt showing up in generated snippets, and at least one controlled study linking Copilot access to higher bug rates — points toward the same practical response regardless of which specific churn number you believe: keep human code review mandatory for AI-assisted PRs, track duplication metrics (not just lint and test pass rates) in CI, and budget refactoring time explicitly rather than assuming velocity gains are free. Teams that treat AI-generated code as a first draft requiring the same scrutiny as a junior engineer’s PR are acting on the strongest part of the evidence; teams that treat it as reviewed-grade output are relying on the weakest part.

Bottom Line

The claim that AI coding assistants universally degrade code quality is not as settled as it’s often presented — GitClear’s churn-doubling projection has been directly challenged by a peer-reviewed-adjacent academic re-analysis using a different (if smaller) dataset. What’s better supported across sources is a duplication problem: more copy-pasted code, less refactored reuse, and measurable code-smell debt in AI-generated snippets, plus at least one controlled study tying Copilot access to a meaningfully higher bug rate without a matching productivity gain. Read any single statistic in this space with its sample size and methodology attached, not as a universal law.

FAQ

Does AI-generated code definitely increase technical debt?
Not definitively. GitClear’s reports argue that duplication is rising and churn is increasing; a 2025 academic re-analysis specifically disputes the churn claim using a different dataset. The duplication trend is less contested than the churn trend.

What is “code churn” and why does it matter?
GitClear defines churn as the percentage of lines reverted or updated within two weeks of being written — a proxy for how often code needs immediate rework, which can indicate rushed or low-confidence changes.

Is the 41% higher bug rate from the Uplevel study reliable?
It comes from a specific, named study (785 developers across several enterprise customers, comparing before/after Copilot access) and the authors themselves describe it as observational, not causal, and limited to their sample. It’s a real data point, not a universal benchmark.

Which AI coding tool produces the fewest code smells?
In the Yetiştiren et al. HumanEval benchmark, Amazon CodeWhisperer had the lowest estimated technical debt per snippet (5.6 minutes) versus Copilot (9.1 minutes) and ChatGPT (8.9 minutes) — but CodeWhisperer also had the lowest correctness rate (31.1%), so lower estimated debt didn’t mean better overall output.

Should teams stop using AI coding assistants based on this research?
The research reviewed here doesn’t support that conclusion — it supports treating AI-generated code with the same review rigor as any other untrusted first draft, and tracking duplication and churn metrics rather than assuming velocity gains come free.

Artificial Intelligence, Cloud & Infrastructure, Engineering

Nvidia NIM and Triton Inference Server Explained: The Developer Tooling Layer Behind Nvidia’s AI Software Moat

Posted on November 3, 2026 by Filip Keser

Nvidia’s hardware moat gets most of the attention, but the software layer that sits between a trained model and a running production endpoint is just as deliberate a lock-in strategy. NIM (Nvidia Inference Microservices) and Triton Inference Server — now rebranding as Nvidia Dynamo-Triton — are the two pieces developers actually touch when deploying a model, distinct from the Blackwell GPUs and CUDA layer we covered in Nvidia’s Data Center AI Empire and the NVLink/InfiniBand networking stack we covered separately. Here’s what each one actually does, based on Nvidia’s own documentation.

At a Glance

	NVIDIA NIM	Triton Inference Server (→ Dynamo)
What it is	Pre-packaged, production-ready microservices for deploying specific foundation models	A general-purpose, open-source server for deploying models from any supported framework
Model scope	Nvidia’s curated catalog: LLMs, vision-language, speech, biology (AlphaFold2, Evo 2), climate (Earth-2), medical imaging, embedding/reranking, OCR, guardrails	Any model in TensorRT, PyTorch, ONNX, OpenVINO, Python, or RAPIDS FIL format
Deployment	Containers; NIM Operator for Kubernetes; GKE integration; WSL2 support	Linux containers via NGC; Windows/Jetson binaries on GitHub; Kubernetes with Prometheus monitoring
Licensing	Part of NVIDIA AI Enterprise	Open source (Apache-licensed on GitHub); also bundled in NVIDIA AI Enterprise for production support
Successor project	N/A	NVIDIA Dynamo — an open-source framework Nvidia calls “the successor to Triton Inference Server,” adding disaggregated prefill/decode serving

Short Verdict

NIM is the fastest path to a production endpoint if the model you need is already in Nvidia’s catalog — you get a hardened container with security updates, not a model you have to optimize and package yourself. Triton (and its emerging successor, Dynamo) is the right tool when you need to serve your own custom or fine-tuned model, or a model outside NIM’s catalog, with fine control over batching and multi-framework support. Both route through the same business reality: Nvidia bundles production support for either one inside NVIDIA AI Enterprise, a subscription Nvidia’s own CEO has publicly pegged at roughly $2,000 per GPU per year — the software half of Nvidia’s moat, sitting directly on top of the hardware half.

What NIM Actually Is

Nvidia describes NIM as “easy-to-use microservices for accelerating the deployment of foundation models on any cloud or data center.” In practice, a NIM is a pre-built, pre-optimized container for one specific model: Nvidia has already handled the inference engine selection, quantization, and performance tuning, and ships the result as a container with “production-grade runtimes” and ongoing security patching. The catalog is broad — large language models and vision-language models are the obvious entries, but it also covers speech (recognition, text-to-speech, translation), biology models like AlphaFold2, Evo 2, and RFdiffusion, Nvidia’s Earth-2 climate models, medical imaging, embedding and reranking models for retrieval-augmented generation, OCR, object detection, and safety guardrail models. Deployment tooling includes a NIM Operator for Kubernetes clusters, direct integration with Google Kubernetes Engine, and even a path to run NIMs inside WSL2 for local development. The trade-off for that convenience is scope: if the model you need isn’t in Nvidia’s catalog, NIM isn’t the tool — you fall back to Triton or another serving layer.

What Triton Does, and Why It’s Becoming Dynamo-Triton

Triton Inference Server is the general-purpose counterpart: an open-source server that deploys models from essentially any framework — TensorRT, PyTorch, ONNX, OpenVINO, Python, and RAPIDS FIL — on NVIDIA GPUs, non-NVIDIA accelerators, or plain x86/ARM CPUs, in the cloud or on-premises. Its core production features are dynamic batching (grouping incoming requests to use GPU capacity more efficiently), concurrent model execution, and support for real-time, batched, ensemble (multi-model pipeline), and streaming audio/video workloads. It integrates with Kubernetes for orchestration and Prometheus for monitoring, and Nvidia distributes Linux containers through NGC alongside Windows and Jetson binaries on GitHub.

Here’s the detail that’s easy to miss if you only know Triton by its old name: Nvidia’s own developer site now describes NVIDIA Dynamo as “the successor to NVIDIA Triton Inference Server.” Dynamo is an open-source, modular inference framework purpose-built for serving generative AI models across distributed, multi-GPU fleets, and it supports SGLang, TensorRT-LLM, and vLLM as backend engines. Its headline features go well beyond what Triton originally offered: disaggregated serving splits a request’s prefill and decode phases across different nodes so each can be scaled and optimized independently; a KV-aware router and KV Block Manager reduce redundant cache recomputation and offload cached attention state to cheaper memory tiers; and an SLO Planner adjusts allocated GPU resources to keep a deployment within a target latency budget. Nvidia cites independent benchmarks showing up to 50x higher throughput for mixture-of-experts models on its newest GB300 NVL72 systems running Dynamo compared with Hopper-generation hardware running older serving stacks — though as with any vendor-cited benchmark, treat the specific multiplier as directional rather than something every workload will replicate. Dynamo is available now as open source on GitHub, and Nvidia says NVIDIA AI Enterprise will add Dynamo for production inference support in a future release.

Licensing: What NVIDIA AI Enterprise Actually Costs

Triton itself is free and open source under an Apache license on GitHub — you can run it today with no Nvidia subscription. NIM and production support for Triton/Dynamo, however, are gated behind NVIDIA AI Enterprise, Nvidia’s commercial software subscription. Nvidia’s own licensing guide describes per-GPU licensing (every GPU in a server needs its own license), available as a subscription, a perpetual license with five years of support, or metered cloud consumption billed per GPU per hour on AWS, Google Cloud, Azure, or Oracle Cloud. The guide doesn’t publish a flat headline price and instead points to a separate pricing page — but Nvidia CEO Jensen Huang has publicly stated the company prices its AI Enterprise software at roughly $2,000 per GPU per year, a figure widely reported in coverage of Nvidia’s software strategy. Some data center GPUs (H100 PCIe/NVL, H200 NVL) ship with a bundled five-year AI Enterprise subscription already included, which is one reason the per-GPU economics of Nvidia’s platform are harder to compare directly against a GPU-only competitor’s sticker price.

Trade-offs vs. Alternatives

vLLM is the most common open-source alternative for LLM-specific serving: it’s free, widely adopted, and focused specifically on high-throughput language model inference with its own paged-attention memory management — notably, it’s also one of the backend engines Dynamo itself can orchestrate, so the two aren’t strictly competitors anymore. TensorFlow Serving is Google’s older, narrower serving system, built specifically around TensorFlow’s SavedModel format; it lacks Triton’s multi-framework flexibility and Dynamo’s distributed-serving features, but remains a simple, battle-tested choice for teams fully committed to the TensorFlow ecosystem. The general pattern: Nvidia’s stack (NIM/Triton/Dynamo) buys you tighter hardware-software co-optimization and enterprise support at the cost of a subscription and some platform lock-in; the open-source alternatives are free and portable but ask your team to own more of the integration and tuning work yourselves.

Pros and Cons

NVIDIA NIM

Pros: Fastest route to a production endpoint for catalog models; Nvidia handles optimization and security patching; broad catalog spanning far beyond LLMs.
Cons: Limited to Nvidia’s curated catalog; tied to NVIDIA AI Enterprise licensing; less control than rolling your own serving stack.

Triton / Dynamo-Triton

Pros: Open source and free to run; true multi-framework support; Dynamo’s disaggregated serving and KV-cache management are genuinely novel at large scale; works across NVIDIA and non-NVIDIA hardware.
Cons: You own the optimization and packaging work NIM would otherwise handle; production support still requires an AI Enterprise subscription; Dynamo’s most advanced features are newest and least battle-tested.

Who It’s a Good Fit For

Teams deploying a well-known foundation model with minimal customization — and who want Nvidia to own the optimization and patching burden — are the clearest fit for NIM. Teams serving their own fine-tuned or custom models, or running a genuinely multi-framework inference fleet, should look at Triton/Dynamo instead. Organizations operating at the scale of many GPUs across distributed nodes, where prefill/decode disaggregation and KV-cache offloading meaningfully change unit economics, are exactly who Dynamo was built for.

Who Should Look Elsewhere

If your workload is a single open-source LLM and you don’t need Nvidia’s broader catalog or enterprise support, vLLM alone is simpler and free. If you’re fully committed to TensorFlow and don’t need multi-framework flexibility, TensorFlow Serving avoids adopting a new toolchain entirely. And if avoiding per-GPU software licensing costs is a hard budget constraint, run Triton’s open-source build without an AI Enterprise subscription and accept community-support terms instead of Nvidia’s production SLA.

Bottom Line

NIM and Triton/Dynamo are the developer-facing half of Nvidia’s AI moat — the layer that converts raw GPU performance into something a team can actually deploy and operate. NIM trades flexibility for speed and support; Triton (and its new Dynamo successor) trades some convenience for openness and multi-framework reach. Both ultimately route spending back through NVIDIA AI Enterprise licensing, which is the real business model underneath “free and open source” software running on Nvidia hardware.

FAQ

Is Triton Inference Server being discontinued?
Not immediately, but Nvidia’s own developer site names NVIDIA Dynamo as its successor, with Dynamo-Triton as a transitional branding. Triton remains available and supported, but new investment is clearly going into Dynamo’s distributed-serving features.

Do I need NVIDIA AI Enterprise to use Triton?
No — Triton is open source and free to run on its own. AI Enterprise is only required if you want Nvidia’s production support, stable APIs, and long-term branch maintenance for it.

How much does NVIDIA AI Enterprise actually cost?
Nvidia’s official licensing guide doesn’t publish a flat per-GPU price and refers buyers to a separate pricing page, but CEO Jensen Huang has publicly cited roughly $2,000 per GPU per year as the company’s software pricing target — a figure widely reported, not an official list price guaranteed for every deal.

Can I use NIM with models that aren’t in Nvidia’s catalog?
Not directly — NIM is pre-built around specific catalog models. For custom or fine-tuned models outside that catalog, Triton or Dynamo is the appropriate serving layer instead.

How does Dynamo relate to vLLM?
They’re not strictly competitors — Dynamo is a distributed orchestration framework that can run vLLM (along with SGLang and TensorRT-LLM) as one of its backend inference engines, adding disaggregated serving and KV-cache management on top.

Sources

Artificial Intelligence

Best Enterprise AI Code Generation Tools in 2026: Devin (formerly Codeium/Windsurf) vs Tabnine vs Amazon Q Developer

Posted on November 3, 2026 by Filip Keser

If you searched for “Codeium Windsurf enterprise pricing” expecting a straightforward comparison, you’ve run into the same surprise we did: as of late 2026, Windsurf no longer exists as a separate product. Codeium rebranded to Windsurf in 2024, Cognition (maker of the autonomous coding agent Devin) acquired Windsurf in late 2025 for a reported $250 million, and in June 2026 Cognition rebranded the Windsurf editor itself into “Devin Desktop.” This piece compares what that product has become — now simply part of Cognition’s Devin lineup — against Tabnine and Amazon Q Developer, the two other enterprise-oriented AI coding tools built specifically around on-prem/VPC deployment and compliance, rather than repeating our earlier Cursor vs. GitHub Copilot vs. JetBrains AI Assistant comparison.

At a Glance

Tool	Vendor	Entry enterprise pricing	Self-hosting/VPC	Key compliance certs
Devin / Devin Desktop (formerly Codeium/Windsurf)	Cognition	Teams: $80/mo + $40/seat/mo; Enterprise: custom	VPC deployment and a “dedicated deployment option” on Enterprise	SOC 2 Type II and ISO 27001 certified on all surfaces; FedRAMP High in progress
Tabnine	Tabnine	Not published; contact sales for Enterprise	Secured SaaS, on-premises, or fully isolated in your own VPC	SOC 2 compliant (per Tabnine’s own enterprise page)
Amazon Q Developer	AWS	Free; Pro at $19/user/month	VPC interface endpoints via AWS PrivateLink; inherits AWS’s compliance programs	Covered under AWS’s shared-responsibility compliance program (SOC, ISO, etc. at the AWS platform level)

Short Verdict

Devin (the product formerly known as Windsurf) is now the most compliance-forward of the three on paper, with SOC 2 Type II and ISO 27001 certification across cloud, desktop, and CLI, plus a FedRAMP High push underway — but it arrived there through two rebrands in under two years, which is worth weighing against stability. Tabnine remains the most deployment-flexible option, with genuine on-premises and air-gapped VPC installs, though its published compliance claims are thinner than its rivals’. Amazon Q Developer is the easiest sell for teams already standardized on AWS, inheriting AWS’s compliance programs and VPC networking rather than building its own from scratch, at the simplest published per-seat price of the three ($19/user/month for Pro).

What Happened to Codeium and Windsurf

This history matters for anyone evaluating the product today. Codeium launched as an AI code-completion tool, rebranded to Windsurf as it pushed into agentic editing, and became one of the most talked-about AI IDEs of 2025 — talked about partly because Google licensed Windsurf’s technology and hired several of its top researchers mid-year, leaving the standalone company in a weakened position. Cognition, the startup behind the autonomous coding agent Devin, acquired what remained of Windsurf in December 2025 for a reported $250 million. On June 2, 2026, Cognition shipped an over-the-air update that rebranded the Windsurf editor as “Devin Desktop”: existing accounts, plans, extensions, and keybindings carried over, but Windsurf’s built-in agent, Cascade, was retired in favor of “Devin Local,” a Rust-rewritten agent Cognition says uses roughly 30% fewer tokens and can spawn subagents. The practical upshot: there is no more “Codeium (Windsurf)” enterprise product to evaluate on its own terms — it’s now a surface inside Cognition’s broader Devin platform, alongside cloud Devin and a CLI.

What Each Platform Actually Offers

Devin / Devin Desktop now spans three surfaces — Cloud, Desktop, and CLI — and supports the Agent Client Protocol (ACP), which lets outside agents such as Codex or Gemini CLI run inside the editor rather than locking you into one vendor’s model. On the enterprise side, Devin’s security documentation states SOC 2 Type II and ISO 27001 certification across all surfaces, with FedRAMP High “in progress” for CLI/Desktop and Cloud. Enterprise deployment connects to internal systems via AWS PrivateLink or IPSec, with an outbound-only policy gateway (“Devin Connect”), and the vendor says single-tenant, region-pinned hosting is available on request. Devin Enterprise also supports self-hosted source control systems directly — GitHub Enterprise Server, GitLab self-managed, Azure DevOps Server, Bitbucket Data Center, Gerrit, and Perforce — which matters for codebase-aware features in locked-down environments. Pricing is published up to the Teams tier ($80/month plus $40/month per full seat, up to 200 users); Enterprise is quote-only.

Tabnine positions itself explicitly as “the AI code assistant that you control,” and deployment flexibility is its central pitch: Tabnine can run as a secured multi-tenant SaaS, fully on-premises, or isolated inside your own VPC with no outbound connectivity required. Its enterprise page states it doesn’t train on your code unless you explicitly connect your codebase, and that connected code stays inside your environment. Tabnine publishes SOC 2 compliance but its own enterprise materials don’t list ISO 27001, HIPAA, or FedRAMP, so compliance-sensitive buyers should confirm current certification status directly with Tabnine rather than assuming parity with Devin or AWS. IDE coverage includes VS Code, the JetBrains family (IntelliJ, PyCharm, WebStorm, and others), Eclipse, and Sublime. Tabnine does not publish per-seat enterprise pricing on its public site; it’s sold through a sales conversation.

Amazon Q Developer is the clearest fit for teams already deep in AWS. Its Free tier includes 50 agentic requests a month and 1,000 lines of code per user for Java upgrade transformations; Pro, at $19 per user per month, raises those limits, adds an admin dashboard with IAM Identity Center integration, automatic opt-out of data collection, and IP indemnity. Q Developer supports VPC interface endpoints through AWS PrivateLink, so traffic can stay off the public internet, and it inherits AWS’s existing compliance programs under the standard shared-responsibility model rather than publishing its own separate certification list — which is a meaningfully different compliance story than a vendor certifying its own product independently, and worth clarifying with your compliance team if you need a certification that names Q Developer specifically rather than “AWS” broadly.

Pros and Cons

Devin / Devin Desktop

Pros: Strongest published compliance posture (SOC 2 Type II + ISO 27001 on all surfaces, FedRAMP High in progress); supports self-hosted source control directly; ACP support avoids lock-in to one model vendor.
Cons: Two rebrands in under two years (Codeium → Windsurf → Devin Desktop) raise legitimate continuity questions; Enterprise pricing isn’t published; no on-premises option, only VPC/dedicated hosting.

Tabnine

Pros: True on-premises and air-gapped VPC deployment; broad, mature IDE support including Eclipse and Sublime; strong “your code stays yours” data-handling stance.
Cons: No public pricing; thinner published compliance-certification list than Devin or AWS; less agentic/autonomous capability positioning than Devin.

Amazon Q Developer

Pros: Simple, published per-seat pricing ($19/user/month Pro); VPC PrivateLink support; inherits AWS’s broad compliance program rather than building one from scratch; tight integration with other AWS services.
Cons: Compliance is inherited at the AWS-platform level, not independently certified for Q Developer specifically; most natural fit is inside the AWS ecosystem rather than as a standalone, cloud-agnostic tool.

Who It’s a Good Fit For

Choose Devin/Devin Desktop if you want the most agentic, autonomous workflow and can live with quote-only enterprise pricing and a security program that’s still completing FedRAMP High. Choose Tabnine if your compliance or infrastructure team requires a genuinely air-gapped, on-premises deployment with no outbound network dependency. Choose Amazon Q Developer if your organization already standardizes on AWS and wants predictable per-seat pricing with compliance handled under your existing AWS agreements.

Who Should Look Elsewhere

If brand stability matters to your procurement process, Devin’s rapid rebranding history (three names in roughly two years) is worth flagging to stakeholders before you commit. If you need a published, comparable enterprise price point without a sales call, Tabnine’s lack of public pricing may be a dealbreaker. And if you’re multi-cloud or cloud-agnostic by policy, Amazon Q Developer’s AWS-centric compliance and integration story may be a poorer fit than Devin or Tabnine.

Bottom Line

“Codeium (Windsurf)” as a distinct product is already history by late 2026 — it’s Devin Desktop now, inside Cognition’s broader agent platform, with a genuinely strong compliance story to show for the turbulence. Tabnine remains the deployment-flexibility specialist for teams that need true on-premises isolation. Amazon Q Developer is the low-friction default for AWS-committed organizations. None of the three is a universal “best” — match the choice to whether your constraint is agentic capability, deployment isolation, or cloud-platform alignment.

FAQ

Is Windsurf still a separate product from Devin?
No. As of June 2026, Cognition rebranded the Windsurf editor as “Devin Desktop,” retiring the Windsurf name and its built-in Cascade agent in favor of Devin Local. Existing Windsurf accounts and plans carried over automatically.

Does Tabnine support fully offline, air-gapped deployment?
Tabnine’s own enterprise materials describe running “fully isolated” in your VPC or on-premises, which is the strongest offline/air-gapped positioning of the three tools compared here.

What does Amazon Q Developer Pro cost per seat?
$19 per user per month, billed with the first month prorated from activation. The Free tier has no per-seat charge but caps agentic requests at 50 per month.

Is Devin Enterprise FedRAMP certified?
Not yet as of this writing. Devin’s security documentation lists FedRAMP High as “in progress” for its CLI, Desktop, and Cloud surfaces, alongside completed SOC 2 Type II and ISO 27001 certification.

Which of these three publishes clear enterprise pricing?
Only Amazon Q Developer publishes a specific enterprise-relevant per-seat price ($19/month for Pro). Devin publishes pricing up to its Teams tier but not Enterprise; Tabnine doesn’t publish enterprise pricing at all.

Sources

Artificial Intelligence, Cloud & Infrastructure

Oracle’s AI Cloud Capacity Deals in 2026: What the Mega-Contracts Mean for OCI’s GPU Business

Posted on November 3, 2026 by Filip Keser

Oracle’s cloud infrastructure business has gone from an afterthought to one of the most-discussed AI capacity stories in the industry, largely on the strength of a backlog metric most software companies would never let get this large: Remaining Performance Obligations (RPO), the dollar value of contracted revenue Oracle has not yet recognized. That number has become the de facto scoreboard for how much AI compute Oracle has committed to deliver — and how much financial risk comes with it. This piece sticks to what Oracle has actually disclosed in its own earnings materials, flags clearly where the widely reported headline numbers (like the reported $300 billion OpenAI deal) come from press reporting rather than an Oracle-confirmed figure, and explains what the backlog implies for OCI’s GPU buildout.

At a Glance

Metric (Oracle fiscal Q1 2027, reported Sept. 10, 2026)	Figure	Source
Total revenue	$19.3 billion, up 30% YoY	Oracle press release
Cloud Infrastructure (OCI) revenue	$7.4 billion, up 121% YoY	Oracle press release
Remaining Performance Obligations (RPO)	$664 billion, up $209 billion YoY	Oracle press release
New AI cloud contracts booked in the quarter	“More than $30 billion”	Oracle press release
GPUs delivered to AI Cloud customers since Q4	“More than 300,000,” nearly triple Q4’s pace	Oracle press release
Q2 FY27 total cloud revenue growth guidance	64%–70% constant currency	Oracle press release
Reported ~$300B, multi-year OpenAI compute deal	Not an Oracle-confirmed dollar figure	Press reporting (WSJ and others, Sept. 2025), unverified by Oracle filing

What Oracle Has Actually Disclosed

Oracle’s most recent earnings release (fiscal Q1 2027, covering the quarter ended August 31, 2026, reported September 10, 2026) is the most current primary source available as of this writing, and it is unusually specific for a company that doesn’t typically name AI customers in its press materials. Total revenue came in at $19.3 billion, up 30% year over year in both USD and constant currency. The headline figure, though, is Cloud Infrastructure (OCI/IaaS) revenue, which Oracle reported at $7.4 billion for the quarter — up 121% year over year.

The number that dominated coverage of the release was Remaining Performance Obligations: Oracle reported total RPO of $664 billion, up $209 billion year over year (implying prior-year RPO of roughly $455 billion, based on simple arithmetic from the two disclosed figures, not a percentage Oracle itself stated). Oracle attributed the jump specifically to booking “more than $30 billion of additional AI cloud contracts” during the quarter. Oracle also disclosed that it delivered more than 300,000 GPUs to AI Cloud customers since the end of the prior quarter — almost triple the capacity it delivered in the quarter before that — which is as close as the company gets to a physical-capacity proof point behind the RPO number. Oracle’s guidance for the following quarter (Q2 FY27) calls for total cloud revenue growth of 64% to 70% in constant currency, and full fiscal-year 2027 total revenue of at least $90 billion.

Notably, Oracle’s press release does not name individual AI customers behind these contracts, and it does not break out capital expenditure figures tied specifically to the AI buildout in the release itself; the company reported free cash flow of negative $5 billion for the quarter, which it attributed to investment supporting cloud infrastructure growth, alongside $23 billion of operating cash flow and $20 billion raised through an at-the-market common stock program.

What’s Reported, But Not Oracle-Confirmed

The number most people associate with this story — a roughly $300 billion, multi-year cloud computing deal between Oracle and OpenAI tied to Project Stargate — comes from reporting by outlets including the Wall Street Journal, citing people familiar with the agreement, in September 2025, and has been repeated widely since. It is a credible, widely corroborated report from reputable outlets, but it is not a figure Oracle itself has confirmed in a press release or SEC filing naming OpenAI as the counterparty and $300 billion as the contract value. Oracle’s own earnings materials describe AI cloud contract bookings only in aggregate and do not name which customers they’re with. Readers should treat the $300 billion OpenAI figure as credibly reported, not as an Oracle-disclosed fact, and the same caution applies to any other customer-specific dollar figures circulating in coverage of Oracle’s AI backlog that don’t trace back to an Oracle press release, 10-K, or 10-Q.

What RPO Actually Measures — and Its Limits

RPO is contracted, unrecognized revenue — a backlog, not cash in hand and not yet-earned revenue. It tells you Oracle has signed agreements obligating customers to pay for a certain amount of future cloud capacity, but it does not tell you the payment schedule, the credit quality of every counterparty, or how much of that capacity Oracle can physically build and deliver on the timeline the contracts assume. A large RPO number is genuinely a sign of real demand, but it’s also a number Oracle itself can influence through how aggressively it pursues long-duration, large-dollar-value contracts versus shorter, smaller ones — and analysts and financial press have flagged that funding a buildout this large requires Oracle to raise substantial capital (debt and equity, including the $20 billion at-the-market stock sale disclosed this quarter) ahead of actually recognizing the revenue those contracts represent. That’s a normal, disclosed part of Oracle’s financing strategy, not evidence of anything irregular, but it’s the context that should accompany any RPO headline number: backlog and delivered, recognized revenue are two different things, and the gap between them is where execution risk lives.

What This Means for OCI’s GPU Business

Taken together, Oracle’s own disclosures paint a consistent picture: OCI’s AI infrastructure business is growing extremely fast off a small base, is heavily reliant on a small number of very large contracts (Oracle’s SEC filings in prior quarters have separately disclosed meaningful customer concentration in RPO, a risk factor worth watching in Oracle’s subsequent 10-Q filings), and requires Oracle to keep raising capital well ahead of recognizing the revenue those contracts promise. The 300,000+ GPUs delivered since the prior quarter is the clearest evidence that contracted demand is translating into physically deployed capacity rather than remaining purely on paper, which matters because RPO growth without matching capacity delivery would be a much weaker signal. For a deeper look at OCI’s technical positioning against AWS, Azure, and Google Cloud for AI workloads, see our earlier piece linked below; this article is specifically about the financial and contractual side of that buildout.

Trade-offs and Open Questions

Strength: Oracle’s own numbers (RPO, OCI revenue growth, GPU delivery figures) are independently disclosed, audited-adjacent earnings figures, not marketing claims.
Uncertainty: individual mega-deal dollar figures (the reported $300B OpenAI agreement, and similar figures attributed to other AI labs in press coverage) are not independently confirmed by Oracle at the customer level.
Risk: a backlog this concentrated in a handful of counterparties carries real execution and credit risk if any major contract is delayed, renegotiated, or reduced — a dynamic Oracle’s own filings have flagged as a customer-concentration risk factor in the past.
Capital intensity: delivering on this backlog requires continuous, large-scale capital raising (debt and equity) well ahead of recognizing the matching revenue, which is a structural feature of this business model, not a one-time event.

The Bottom Line

Oracle’s own disclosed numbers — $664 billion in RPO, 121% OCI revenue growth, over 300,000 GPUs delivered in a single quarter — are real, verifiable, and describe a genuinely large and fast-growing AI infrastructure business. The specific mega-contract dollar figures that dominate headlines, including the widely reported $300 billion OpenAI deal, are credible press reporting but not figures Oracle has confirmed itself at the customer level, and that distinction matters when deciding how much weight to put on any single number. The more durable signal is the relationship between backlog growth and actual GPU delivery: as long as Oracle keeps converting RPO into deployed capacity at a pace resembling what it reported this quarter, the backlog is doing its job as a leading indicator rather than an accounting overhang.

FAQ

What exactly is Remaining Performance Obligations (RPO)?
It’s the total dollar value of contracted revenue a company hasn’t yet recognized under its revenue recognition rules — essentially a backlog of signed, unfulfilled contracts. For Oracle, it ballooned specifically because of large, multi-year AI cloud infrastructure agreements.

Has Oracle confirmed the $300 billion OpenAI deal?
Not at that specific dollar figure, tied to that specific customer, in an Oracle press release or SEC filing as far as this research could verify. The number traces to media reporting (the Wall Street Journal and subsequent outlets, September 2025) citing people familiar with the agreement. Oracle’s own earnings materials discuss AI contract bookings only in aggregate.

Is a growing RPO automatically good news?
It’s a positive demand signal, but RPO is unrecognized, contracted revenue, not cash or completed work. Its value depends on counterparty credit quality, contract durability, and Oracle’s ability to actually deliver the capacity on the assumed timeline — none of which the headline number alone tells you.

How is Oracle funding this buildout?
Through a mix of operating cash flow, debt, and equity issuance; this quarter’s release specifically disclosed $20 billion raised via an at-the-market common stock program alongside negative $5 billion in free cash flow, which Oracle attributed to infrastructure investment.

How does this relate to Oracle’s other AI announcements, like Database 23ai or its Nvidia partnership?
Those cover different layers of the same broader strategy: Database 23ai is about AI features built into Oracle’s database product, and the Nvidia partnership concerns the GPU hardware supply behind OCI. This article is specifically about the financial scale of Oracle’s AI cloud capacity contracts and what the backlog numbers imply.

Sources

Engineering

Vector Databases and Approximate Nearest Neighbor Search Explained: HNSW vs IVF for AI Retrieval

Posted on November 3, 2026 by Filip Keser

Every retrieval-augmented generation (RAG) pipeline, semantic search box, and recommendation engine built since 2023 depends on the same underlying problem: given a query vector, find the handful of vectors in a database of millions (or billions) that are closest to it. Doing this exactly, by comparing the query to every stored vector, is called k-nearest neighbor (kNN) search, and it does not scale — brute-force comparison is O(N) per query. So almost every real vector database instead does approximate nearest neighbor (ANN) search: trading a small, tunable amount of recall for orders-of-magnitude faster lookups. Two families of ANN algorithm dominate production systems in 2026: graph-based methods, led by HNSW, and partition-based methods, led by IVF. This piece explains how each actually works, what their real trade-offs are, and when to reach for which.

At a Glance

Factor	HNSW (graph-based)	IVF (partition-based)
Core idea	Multi-layer navigable graph; search by walking edges toward the query	Cluster vectors into cells with k-means; search only the nearest cells
Key build parameters	`M` (connections per node), `efConstruction`	`nlist` (number of cells)
Key query parameter	`efSearch`	`nprobe` (cells searched)
Query speed	Very fast, roughly logarithmic in dataset size	Fast, scales with `nprobe/nlist` fraction scanned
Memory overhead	Higher — stores the full graph on top of vectors (~`M × 2 × 4` extra bytes/vector)	Lower — mainly list IDs plus chosen vector encoding
Build time	Slower to build, especially at high `M`/`efConstruction`	Faster to build; k-means training step is comparatively cheap
Handles deletions well?	No — removing nodes breaks the graph structure	Yes — easier to add/remove vectors from a cell
Typical users	Qdrant, Weaviate, Milvus (default), pgvector (HNSW index)	FAISS, Milvus (IVF variants), many large-scale offline pipelines

Why Exact Search Doesn’t Scale

An embedding model turns text, images, or audio into a dense vector, typically a few hundred to a few thousand floating-point numbers, positioned so that semantically similar inputs land close together under a distance metric like cosine similarity or Euclidean distance. Finding the true nearest neighbors to a query vector means computing that distance against every vector in the collection. At a few thousand vectors this is trivial. At tens of millions, it means billions of floating-point operations per query — workable for a batch job, unworkable for an interactive RAG endpoint that needs to return results in tens of milliseconds. ANN algorithms accept a small, measurable chance of missing a true nearest neighbor in exchange for search that scales sub-linearly.

How HNSW Works

HNSW (Hierarchical Navigable Small World) was introduced by Yu. A. Malkov and D. A. Yashunin in their 2016 paper “Efficient and Robust Approximate Nearest Neighbor Search Using Hierarchical Navigable Small World Graphs,” building on earlier skip-list and small-world-graph ideas. Conceptually, HNSW organizes vectors into several stacked graph layers, like a multi-level transit map:

The top layer is sparse, with a small number of nodes connected over long links — good for covering large distances quickly.
Each layer below is progressively denser, with more nodes and shorter, more local connections.
The bottom layer contains every vector in the collection, densely interconnected.

A search starts at an entry point in the top layer and greedily walks toward the query vector, hopping to whichever neighbor is closer at each step. When no neighbor in the current layer is closer, the search drops down a layer and continues, refining its position until it bottoms out with a set of nearby candidates. This is similar to zooming from a country-level map down to a street-level map rather than scanning every street in the country directly.

Three parameters control the trade-off, as documented by vector database vendors such as Qdrant:

M — the maximum number of connections per node (commonly 8–64; Qdrant defaults to 16). Higher M improves recall but increases memory and build time.
efConstruction — how many candidate neighbors are evaluated when inserting a new vector into the graph (commonly 100–500). Higher values build a better-connected graph at the cost of slower indexing.
efSearch (sometimes called hnsw_ef) — how many candidates are evaluated per query at search time (commonly 50–200+). This is the main dial for trading query latency against recall, and unlike the other two, it can be changed per query without rebuilding the index.

HNSW’s practical downside is memory and mutability. The graph’s edges sit on top of the raw (or quantized) vectors, adding roughly M × 2 × 4 bytes per vector according to FAISS’s own documentation, and removing a vector cleanly is not supported because deleting a node can disconnect the graph around it — most implementations instead mark vectors as deleted and periodically rebuild.

How IVF Works

IVF (Inverted File index), as implemented in Meta’s FAISS library, takes a completely different approach: partition first, then search only the relevant partitions. FAISS’s own wiki documentation describes it as a “cell-probe method”:

During index training, a coarse quantizer (usually k-means) splits the vector space into nlist cells, each represented by a centroid.
Every vector in the collection is assigned to exactly one cell — whichever centroid it’s closest to — and stored in that cell’s inverted list.
At query time, the query vector is compared only against the nlist centroids to find the nprobe closest cells, then compared against the actual vectors inside just those cells.

FAISS’s documentation gives a rule of thumb for sizing nlist at roughly C × sqrt(n) for a dataset of n vectors. The fraction of the database actually scanned per query is approximately nprobe / nlist (in practice usually a bit more, since cells are rarely perfectly balanced). Raising nprobe improves recall by checking more cells, at a roughly linear cost in query time. Recall suffers specifically when a query’s true nearest neighbor happens to sit in a cell that wasn’t among the nprobe probed — a structural risk near cell boundaries that has no direct HNSW equivalent.

IVF is commonly paired with vector compression. IVFFlat stores full-precision vectors (about 4d + 8 bytes per vector, where d is dimensionality); IVFPQ (product quantization) compresses vectors much further at some recall cost, making it attractive for billion-scale, memory-constrained deployments. Because cells are just lists, adding and removing vectors is straightforward compared to HNSW’s graph surgery problem.

A Minimal Illustration of the Search Logic

The pseudocode below is a simplified sketch of the two query paths — not production code — meant only to show where each algorithm spends its effort.

function ivf_search(query, nprobe):
    centroids = get_cell_centroids()
    nearest_cells = top_k(centroids, query, k=nprobe)
    candidates = []
    for cell in nearest_cells:
        candidates.extend(cell.vectors)
    return top_k(candidates, query, k=final_k)

function hnsw_search(query, ef_search):
    layer = top_layer
    current = entry_point
    while layer > 0:
        current = greedy_walk(layer, current, query)
        layer = layer - 1
    candidates = explore_neighbors(current, query, ef=ef_search)
    return top_k(candidates, query, k=final_k)

HNSW vs IVF: When to Use Which

Neither structure is strictly better; they sit at different points on the recall/speed/memory curve, and the right choice depends on dataset size, update frequency, and hardware budget.

Choose HNSW when query latency matters most, the dataset fits comfortably in memory, recall needs to stay high even at low latency, and updates are frequent but deletions are rare (most RAG and real-time semantic search use cases). It’s the default or primary index type in Qdrant, Weaviate, and pgvector’s HNSW mode.
Choose IVF (often IVF+PQ) when the collection is very large (hundreds of millions to billions of vectors), memory is tight, and some recall can be traded for dramatically smaller index size. It’s also easier to shard and rebuild incrementally, which is why it shows up heavily in FAISS-based offline and batch retrieval pipelines.
Hybrid approaches exist: FAISS supports using an HNSW graph as the coarse quantizer inside an IVF index (IVF_HNSW), combining fast coarse routing with inverted-list storage.

In practice, most teams don’t hand-pick an algorithm from first principles — they pick a vector database (Qdrant, Weaviate, Pinecone, Milvus, or Postgres with pgvector) and then tune its exposed parameters. Pinecone’s newer serverless indexes go a step further and abstract the index type away entirely, separating storage from query compute and exposing on-demand read capacity rather than a pod size the user has to choose. That’s a trend worth watching: the HNSW-vs-IVF decision is increasingly made by the database vendor, not the application developer, with the practitioner left tuning recall targets and cost rather than graph parameters directly.

Trade-offs Summary

Pros of HNSW: excellent recall-to-latency ratio, logarithmic-ish query scaling, tunable at query time via efSearch without rebuilding.
Cons of HNSW: larger memory footprint, slower builds at high quality settings, poor support for deletions.
Pros of IVF: lower memory overhead (especially with PQ), faster builds, straightforward updates and deletions, scales well to very large, sharded datasets.
Cons of IVF: recall is more sensitive to data distribution and cell boundaries; needs careful nlist/nprobe tuning and periodic retraining of centroids as data shifts.

The Bottom Line

HNSW and IVF solve the same problem — fast approximate retrieval over dense vectors — with opposite structural bets: a navigable graph versus a partitioned index. For most RAG and application-facing semantic search workloads where the data fits in memory and queries need to be fast and fresh, HNSW’s recall-per-millisecond is hard to beat, which is why it has become the default in most purpose-built vector databases. For very large-scale, storage-constrained, or heavily batch-oriented retrieval, IVF (particularly IVF+PQ) remains the more economical choice. The practical skill isn’t memorizing one algorithm — it’s knowing which knobs (efSearch, nprobe, M, nlist) to turn when recall, latency, or memory becomes the bottleneck in production.

FAQ

Is ANN search ever exact?
No — by definition, approximate nearest neighbor search can miss some true nearest neighbors. Both HNSW and IVF expose parameters (efSearch, nprobe) that push recall closer to exact search as you increase them, at the cost of query speed.

Can I combine HNSW and IVF?
Yes. FAISS supports using an HNSW graph as the coarse quantizer inside an IVF index, and several systems layer quantization (scalar or product quantization) on top of either structure to shrink memory further.

Which one do most vector databases use by default?
Most purpose-built vector databases aimed at application developers — Qdrant, Weaviate, Milvus’s default configuration, pgvector’s HNSW index type — default to HNSW because of its strong recall-to-latency ratio on in-memory datasets. IVF (and IVF+PQ specifically) is more common in large-scale, cost-sensitive, or research/offline retrieval pipelines built directly on FAISS.

Does deleting vectors work the same way in both?
No. FAISS’s own documentation notes that HNSW does not support true vector removal because deleting a node can disconnect the graph; most systems instead tombstone and periodically rebuild. IVF’s list-based structure makes removal and insertion more straightforward.

How does this relate to RAG?
A RAG pipeline embeds a user’s query, runs ANN search (HNSW or IVF, depending on the vector store) against a corpus of pre-embedded chunks, and feeds the top results into an LLM’s context window as retrieved evidence. The ANN index’s recall directly caps how good the retrieved context — and therefore the generated answer — can be.

Sources

Related reading on this site: B-Trees vs LSM-Trees: How Databases Choose Their Storage Engine and Oracle Database 23ai and the Oracle–Nvidia Partnership, which covers vector search built directly into a relational database engine.

Artificial Intelligence

AI Browser Agents in 2026: Claude in Chrome vs OpenAI’s ChatGPT Agent vs Google’s Gemini in Chrome

Posted on November 2, 2026 by Filip Keser

Every major AI lab now ships something that can drive a web browser on your behalf: clicking buttons, filling in forms, and working through multi-step errands while you do something else. In 2026 the field has already gone through one round of consolidation. Google shut down its standalone “Project Mariner” research prototype in May. OpenAI discontinued its standalone Atlas browser in August, folding the technology back into ChatGPT. Only Anthropic’s Claude in Chrome is still shipped as a dedicated browser extension. Here is what each company’s current product actually does, who can use it, and what guardrails are documented on their own support pages — not what was announced a year ago and never updated.

At a Glance

Product	Maker	What It Does	Availability / Tier
Claude in Chrome	Anthropic	Chrome extension that reads pages, clicks, types, fills forms, and runs multi-step and background tasks across tabs	Paid plans only: Pro, Max, Team, Enterprise. Chrome only, desktop only
ChatGPT agent mode	OpenAI	Runs multi-step tasks in a visual browser, terminal, and code environment inside ChatGPT; absorbed the old Operator and the shut-down Atlas browser	Pro, Plus, Business, Enterprise, Edu. Not yet in EEA/Switzerland for full features
Gemini in Chrome (“auto browse”) and Gemini Tasks	Google	Completes shopping, booking, and research tasks in Chrome or a remote browser; Tasks absorbed much of the discontinued Project Mariner’s browsing engine	Google AI Pro or Ultra, personal account, 18+, US only for auto browse; Tasks excludes EEA, UK, Switzerland, Nigeria

Claude in Chrome (Anthropic)

Anthropic’s support documentation now calls the product “Claude in Chrome” rather than the “Claude for Chrome” name used at its August 2025 research-preview launch. It is a browser extension that works alongside the person using it: Claude can read a page, click, type, navigate between tabs, and fill out forms. According to Anthropic’s own help article, it can also handle background work that keeps running while you switch tabs (as long as Chrome stays open), take on multiple tabs at once if you drag them into Claude’s tab group, run tasks on a recurring schedule, save prompts as reusable shortcuts, and read console output, network requests, and DOM state for debugging purposes. A beta integration with 1Password on macOS lets Claude request logins without ever seeing the password itself.

Access is restricted to paid Claude plans: Pro, Max, Team, and Enterprise. There is no free tier and, per the documentation, no waitlist mentioned at this stage — it is simply gated by subscription. It only runs in Chrome itself, not other Chromium browsers, and it is not available on mobile. Enterprise and Team admins get the most granular control: they can enable or disable the extension outright, and set allowlists or blocklists that restrict which domains Claude is permitted to touch.

ChatGPT Agent Mode and the End of the Atlas Browser (OpenAI)

OpenAI’s browser-agent story has consolidated twice in the past year. First, in July 2025, OpenAI’s own announcement describes “ChatGPT agent” as a “natural evolution” that folded the earlier Operator research preview directly into ChatGPT — the standalone Operator site was sunset shortly after. Then, in 2026, OpenAI tried a second approach: a standalone Atlas desktop browser, launched in October 2025. That experiment was short-lived. OpenAI’s own help center article on the deprecation states plainly that the company is “deprecating Atlas and moving browser-based agentic capabilities into ChatGPT and Codex,” with Atlas stopping functioning on August 9, 2026 — about nine months after its debut. OpenAI pointed users toward the ChatGPT desktop app (which gained multi-tab support, downloads, and account-login handling) and a ChatGPT Chrome extension/sidebar for lighter in-browser assistance, while deeper agentic work lives in “agent mode” inside ChatGPT itself.

As it stands today, agent mode works from a visual browser, a text browser, a terminal, and direct API access, plus connectors to apps such as Gmail and GitHub. OpenAI’s documentation says it can browse and interact with websites, fill out forms, run code, analyze data, build slideshows and spreadsheets, and even make purchases — with a confirmation step first. Typical tasks take roughly 5 to 30 minutes. It is available on Pro, Plus, Business, Enterprise, and Edu plans (not the free tier), with monthly message caps of 40 for Plus/Business/Enterprise and 400 for Pro. Full availability has been rolling out gradually and was not yet complete in the EEA and Switzerland as of OpenAI’s published guidance.

Gemini in Chrome and the Shutdown of Project Mariner (Google)

Google’s path has been the most fragmented of the three. Project Mariner launched as a DeepMind research prototype in December 2024 and reached a stable release for Google AI Ultra subscribers in the US in May 2025, with plans to expand into the Gemini API, Vertex AI, and Search’s AI Mode. Multiple reports — corroborated by Google’s own Project Mariner page as cited in its Wikipedia history — confirm the standalone experiment was discontinued on May 4, 2026, with its underlying browsing technology folded into other Google products rather than continued as its own brand.

Two live Google products now carry that technology forward, and both are documented on Google’s own support site. The first is “auto browse” inside Gemini in Chrome, an experimental feature that lets Gemini “complete multi-step tasks for you on the web,” including comparing products, adding items to a cart, booking travel and restaurant reservations, buying event tickets, and drafting messages. It requires a Google AI Pro or Ultra plan, a personal Google account (not work/school, not Incognito), the latest Chrome build, and residency in the US while 18 or older; it is desktop-only and still rolling out gradually. Usage is capped at 20 multi-step tasks per day on AI Pro and 200 per day on AI Ultra. The second is “Tasks” within the broader Gemini app (mobile, Mac, and web), which can assign Gemini a goal to work on in the background or on a schedule — including web shopping and bookings through either the local Chrome browser or a remote browser Gemini controls itself. Tasks requires a Pro or Ultra subscription, a personal account, and is not available in the EEA, UK, Switzerland, or Nigeria; up to 15 tasks can run at once.

Feature Comparison

Capability	Claude in Chrome	ChatGPT Agent Mode	Gemini in Chrome / Tasks
Navigates sites & clicks/types	Yes	Yes	Yes
Fills out web forms	Yes	Yes (listed as a confirmed action)	Yes (requires confirmation)
Multi-step / long-running tasks	Yes, including background work across tabs	Yes, 5-30 minute typical tasks	Yes, scheduled or background Tasks; Chrome auto browse is session-based
Can complete a purchase	Not emphasized in documentation	Yes, with confirmation first	Yes, with confirmation; user bears responsibility for outcomes
Runs on a schedule	Yes, scheduled tasks and shortcuts	Yes, daily/weekly/monthly recurring tasks	Yes, Tasks can run on schedule or trigger on events
Org-level domain controls	Allowlist/blocklist for Team & Enterprise	Enterprise owners can block domains	Admin opt-in/out at domain or group level (Workspace)
Lowest qualifying paid tier	Claude Pro	ChatGPT Plus	Google AI Pro

Safety Guardrails Compared

All three vendors converge on a similar basic shape of safeguard, even though they describe it in different language. Anthropic’s support article says Claude in Chrome is “enhanced with our safety classifiers but is still risky,” and recommends reading its separate safety guide before use; the extension reviews each action and pauses to ask for approval when needed, and organizations can restrict it to specific domains via allowlists and blocklists, or disable it entirely. OpenAI’s documentation for ChatGPT agent mode describes a “takeover mode” that hands control of the virtual browser back to the user for logins (screenshots stop being captured while the user is in control), a “watch mode” that requires active supervision on certain sites, a confirmation step before high-impact actions, and an enterprise-configurable domain blocklist; the company also cites refusal patterns for disallowed tasks and ongoing monitoring for prompt-injection attempts.

Google’s support pages for both Gemini in Chrome’s auto browse and the broader Gemini Tasks feature are the most explicit about financial exposure: Gemini is required to ask for confirmation before sending communications, modifying data, submitting forms, making a purchase, or accessing sites with sensitive financial, health, or government-ID data — and that confirmation step applies even if a user has set permissions to “Always allow.” For sign-ins and payments, Gemini must hand control back to the user rather than entering credentials itself, and Google’s own guidance explicitly tells users not to type passwords or card numbers directly into a task thread. All three companies state, in their own words, that these measures reduce but do not eliminate risk, and that users remain responsible for monitoring the agent’s actions — particularly anything involving money, legal matters, or health information.

Trade-offs

Claude in Chrome is the most developer-leaning of the three, with console/network/DOM access built in for debugging, but it is Chrome-only, desktop-only, and gated entirely behind a paid plan with no lightweight free tier to try first.
ChatGPT agent mode has the broadest task surface (code execution, file analysis, app connectors, plus browsing) and the clearest purchase-confirmation flow, but it inherited two product pivots in twelve months — Operator folded in, then the standalone Atlas browser shut down after nine months — which is worth factoring in if you build a workflow around it.
Gemini in Chrome / Tasks has the tightest documented daily usage caps (20-200 tasks a day depending on tier) and the narrowest geographic availability of the three, restricted largely to the US for Chrome auto browse and excluding the EEA, UK, Switzerland, and Nigeria for the broader Tasks feature — a result of Project Mariner’s technology being redistributed into regionally gated products rather than a single global one.

Bottom Line

Browser-controlling AI agents are real and shipping today, but none of the three majors has settled on a final form yet. Anthropic has the most stable, single-product offering in Claude in Chrome, aimed at people already paying for Claude and comfortable with a developer-flavored tool. OpenAI has the most capable all-in-one agent once you’re inside ChatGPT, after abandoning the idea of a separate browser entirely. Google has split the old Project Mariner’s capabilities across two different surfaces — Chrome’s auto browse and the Gemini app’s Tasks — each gated by its own narrower eligibility rules. For teams evaluating these tools for productivity, QA, or site-scanning use cases, the practical advice is the same across all three: start with low-stakes, reversible tasks, keep an eye on the confirmation prompts rather than clicking through them, and expect the product you pick today to look different in six months. For a broader look at the agent landscape beyond browsers, see our explainers on what AI coding agents are and how the leading AI agent frameworks compare.

FAQ

Is OpenAI’s Atlas browser still available?
No. OpenAI’s own help center confirms Atlas was deprecated, with the browser stopping functioning on August 9, 2026, roughly nine months after launch. Its agentic capabilities moved into ChatGPT’s agent mode and Codex, and lighter browsing help is available through a ChatGPT Chrome extension/sidebar.

What happened to Google’s Project Mariner?
The standalone research prototype was discontinued on May 4, 2026. Its browsing technology was folded into Gemini in Chrome’s “auto browse” feature and into the broader “Tasks” capability inside the Gemini app, rather than continuing as its own branded product.

Can any of these agents make purchases on their own?
ChatGPT agent mode and Gemini’s Tasks/auto browse both document the ability to complete purchases, but both require an explicit confirmation step first and place responsibility for unexpected charges on the user. Anthropic’s documentation for Claude in Chrome does not emphasize purchasing as a core capability.

Do I need a paid subscription to use any of these?
Yes, for all three. Claude in Chrome requires a paid Claude plan (Pro and up), ChatGPT agent mode requires Plus and up, and Gemini in Chrome’s auto browse and Tasks both require a Google AI Pro or Ultra subscription.

Are these available outside the US?
Coverage varies and is still expanding. Gemini in Chrome’s auto browse is documented as US-only at this stage; Gemini Tasks excludes the EEA, UK, Switzerland, and Nigeria; ChatGPT agent mode’s full rollout had not yet reached the EEA and Switzerland as of OpenAI’s published guidance. Claude in Chrome’s own documentation does not state a country restriction but is limited to paid-plan Chrome users.

Sources

Anthropic — Get started with Claude in Chrome (support.claude.com)
OpenAI — Introducing ChatGPT agent (openai.com)
OpenAI — ChatGPT agent help article (help.openai.com)
OpenAI — Evolving Atlas into ChatGPT for browser-based agentic work (help.openai.com)
Google — Ask Gemini in Chrome to complete tasks for you with auto browse (support.google.com)
Google — Use Gemini Agent / Tasks for multi-step tasks in Gemini Apps (support.google.com)
Wikipedia — Project Mariner (citing Google’s Project Mariner page on the May 2026 discontinuation)

Artificial Intelligence

Do AI Coding Tools Actually Make Developers Faster? What the Productivity Research Really Shows

Posted on November 2, 2026 by Filip Keser

Nearly every AI coding assistant is sold on a speed promise, and most developers who use one report feeling faster. But when researchers set out to measure that speedup directly, rather than asking developers how fast they felt, the results have been far messier than either side of the AI debate suggests. The most rigorous study available, a 2025 randomized controlled trial from the AI evaluation nonprofit METR, found that experienced open-source developers were actually slower when using AI tools on their own familiar codebases, even though they believed they had sped up. Other research, including GitHub’s own studies and the 2025 DORA report from Google Cloud, points toward real gains, at least for certain tasks, tools, and organizations. This piece walks through what each credible, citable study actually measured, where its conclusions stop, and why the evidence as a whole is still unsettled rather than one-sided.

At a Glance

Study	Who Ran It	What It Found	Key Caveat
Early-2025 RCT (“Measuring the Impact of Early-2025 AI…”)	METR (independent AI research nonprofit)	Experienced developers were 19% slower on real issues when allowed to use AI, despite forecasting a 24% speedup and later believing they were about 20% faster	Only 16 developers and 246 tasks, all on large, familiar open-source codebases, using Cursor with Claude 3.5/3.7 Sonnet in early 2025
2026 follow-up / uplift update	METR	Weak signal of a swing toward speedup (returning developers around 18% faster, new developers around 4% faster), but both confidence intervals cross zero	METR itself calls the evidence “very weak” due to selection bias: developers most convinced AI helps increasingly refused to do tasks without it
Copilot productivity research (2022)	GitHub (vendor-run)	95 professional developers writing a new HTTP server from scratch were about 55% faster with Copilot (1h11m vs. 2h41m) and had a higher task-completion rate	Single, well-defined greenfield task; tested 2022 Copilot Technical Preview, not today’s agentic tools; GitHub is the product’s maker
2025 DORA State of AI-Assisted Software Development	Google Cloud / DORA	90% of developers now use AI; AI adoption is newly linked to higher team delivery throughput, reversing the prior year’s finding; over 80% self-report individual productivity gains	Based on self-reported survey data and organizational correlations, not controlled, task-level timing
2025 Stack Overflow Developer Survey	Stack Overflow	68% of professional developers use AI tools daily or weekly, yet favorable sentiment fell from over 70% in 2023–2024 to about 61%, and only roughly a third trust AI output’s accuracy	Measures usage and sentiment, not measured speed or output quality

METR’s Randomized Trial: Slower, Not Faster, Despite Feeling Faster

The study generating the most debate is METR’s “Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity,” published in July 2025. METR recruited 16 developers who were already experienced, long-tenured contributors to large open-source repositories, averaging more than 22,000 GitHub stars and over a million lines of code. The developers brought 246 real issues, mostly bug fixes, features, and refactors, averaging roughly two hours of expected work each. Each issue was randomly assigned to either allow or disallow AI assistance; when allowed, developers mostly used Cursor Pro with Claude 3.5 or 3.7 Sonnet. Work was screen-recorded and self-timed, and developers were paid $150 an hour.

The result ran against expectations on all sides: when AI was allowed, developers took about 19% longer to complete their issues, with a 95% confidence interval spanning roughly 2% to 39% slower. Just as notable was the gap between belief and reality. Before starting, developers forecast that AI would speed them up by about 24%. Afterward, having just experienced the slowdown, they still estimated that AI had made them roughly 20% faster. METR itself is careful about the limits of this finding: 16 developers is a small sample, participants may differ systematically from developers who declined to take part, and the results describe experienced contributors working in large, familiar codebases with high internal standards for documentation and testing. METR also notes it cannot rule out that developers were still climbing the learning curve on Cursor, and that the results reflect tools as they existed in early 2025.

METR’s 2026 Update: A Walk-Back on Certainty, Not a Reversal

METR did not stop there. In a February 2026 update, the organization described a second, larger study begun in August 2025: 57 developers (10 returning from the original study, 47 new), 143 repositories, and more than 800 tasks, this time paid $50 an hour. The raw numbers moved toward speedup: returning developers were estimated to be about 18% faster, and new developers about 4% faster. But both confidence intervals cross zero, meaning the data cannot statistically distinguish those numbers from no effect at all.

More important than the point estimates is what METR says drove them. Between roughly 30% and 50% of surveyed developers reported skipping tasks in the study because they didn’t want to do them without AI, which likely strips out the tasks where AI would have helped the most and biases the measured result toward looking slower than reality. Lower pay than the original study may have compounded the selection problem. METR’s own conclusion is blunt: developers are probably more sped up by AI in early 2026 than the original study found for early 2025, but the organization calls its evidence for the actual size of that improvement “very weak,” and it is redesigning the experiment rather than standing behind a new number. For anyone tracking how autonomous coding agents like Claude Code and Codex differ from older autocomplete-style tools, this matters: the tools used in the second study were materially more advanced than Cursor with Sonnet 3.5, yet the research still couldn’t pin down a confident number.

GitHub’s Own Research: A Large Speedup on a Narrow Task

GitHub’s most frequently cited productivity research dates to 2022, published on its own research blog while Copilot was still in technical preview. It combines two studies. The first was a survey of more than 2,000 developers who had signed up for the Copilot preview, built around the SPACE framework for developer productivity; over 90% agreed they completed repetitive tasks faster, but this is self-reported perception from an early-adopter population, not a measurement.

The second part is a genuine controlled experiment: 95 professional developers were randomly split into two groups and asked to write an HTTP server in JavaScript from scratch, with correctness and completeness scored automatically by a test suite. The group with Copilot access finished in an average of 1 hour 11 minutes versus 2 hours 41 minutes without it, a 55% speed gain that GitHub reports as statistically significant (P=.0017, 95% CI of 21% to 89%), and also had a higher completion rate (78% vs. 70%). The gap with METR’s finding is explained largely by what was being measured: a short, well-specified, greenfield task with no existing codebase conventions to learn or preserve, versus real maintenance work inside large, idiosyncratic repositories. It’s also a vendor-run study of a now-outdated tool version, which is worth weighing alongside the result itself.

DORA 2025: Near-Universal Adoption, and a Flip at the Organizational Level

The DORA (DevOps Research and Assessment) team at Google Cloud takes a different approach entirely: a large annual survey of software professionals correlating AI adoption with team-level delivery outcomes rather than timing individual tasks. The 2025 report found that AI adoption among software professionals had reached about 90%, up 14 points from the prior year, with professionals spending a median of roughly two hours a day working with AI tools. More than 80% of respondents said AI had improved their individual productivity, and 59% reported a positive effect on code quality, both self-reported.

The headline organizational finding is a reversal: in DORA’s 2024 report, higher AI adoption had been associated with lower software delivery throughput and stability; in 2025, adoption is now linked to higher throughput. DORA frames this cautiously, describing AI as a “mirror and a multiplier” that amplifies the strengths of cohesive, well-run engineering organizations and exposes the weaknesses of fragmented ones, rather than a tool with a fixed, universal productivity effect. Trust remains mixed: only about 24% of respondents report a great deal or a lot of trust in AI output. None of this is a controlled measurement of how much faster any individual developer becomes; it is a correlational, self-reported picture of how AI use tracks with outcomes across many organizations.

Stack Overflow 2025: Heavy Use, Cooling Trust

The 2025 Stack Overflow Developer Survey adds a sentiment and adoption layer rather than a productivity measurement. Among professional developers, 50.6% reported using AI tools daily and another 17.4% weekly, for a combined 68%. But favorable sentiment toward AI tools, which had been above 70% in both 2023 and 2024, fell to about 61% among professionals in 2025. Trust in the accuracy of AI output is notably thin: roughly a third of professional respondents say they trust it, while close to half say they distrust it. Over 40% rated AI as bad or very poor at handling complex tasks specifically. Read together with the benchmark scores covered in our explainer on SWE-bench, HumanEval, and what AI coding benchmarks actually measure, this survey is a useful reminder that benchmark performance, daily usage, and developer confidence can all move independently of each other.

Why the Findings Diverge

These studies aren’t simply contradicting each other; they’re measuring different things under different conditions, and the gaps line up with a few recurring variables.

Task familiarity and codebase complexity. METR’s slower result came from maintenance work inside large, idiosyncratic, long-lived codebases where developers already had deep tacit knowledge; GitHub’s faster result came from a short, self-contained, greenfield task with no existing conventions to navigate. AI assistance appears to help more when there’s little context to absorb and less when a developer already knows the codebase better than the model does.
Experience level and expectations. METR’s participants were highly experienced and had high internal quality bars (tests, documentation, linting), which may make AI-generated suggestions a net cost to review and correct. Less experienced developers, or those working outside their specialty, may see larger relative gains, though METR’s data doesn’t directly test that.
Measurement method. Self-reported speed (GitHub’s 90%+ “faster” figure, DORA’s 80%+ productivity figure, developers’ own post-task estimates in METR’s study) consistently reads more positive than directly timed, randomized measurement. METR’s own developers believed they were faster even while a stopwatch showed otherwise, which is a strong argument for discounting pure self-report.
Tool and model generation. GitHub’s 2022 result used an early Copilot preview; METR’s 2025 result used Cursor with Claude 3.5/3.7 Sonnet; METR’s 2026 follow-up involved more capable agentic tools like Claude Code and Codex. Capability has moved quickly, and a result anchored to one tool generation may not hold for the next.
Selection bias in who gets studied. METR explicitly flagged that developers most convinced of AI’s value increasingly refused to complete tasks without it, skewing later data. The direction of that bias is toward understating AI’s benefit in the newer study, which is part of why METR won’t commit to a number yet.

Bottom Line

There is no single honest answer to “do AI coding tools make developers faster,” because the best available evidence doesn’t converge on one. The most methodologically rigorous study of experienced developers working in familiar, complex codebases found them slower with AI, not faster, despite feeling faster, a finding worth taking seriously precisely because it cuts against both marketing claims and developer intuition. At the same time, a controlled study of a short, well-defined task found a large, statistically significant speedup, and broad industry survey data shows adoption climbing toward near-universal along with self-reported productivity and, newly, a positive link to team-level delivery throughput. What’s genuinely unsettled is magnitude and conditions, not existence: AI coding tools can speed some work up and slow other work down, and the honest position in late 2026 is that task type, codebase familiarity, developer experience, and tool generation all swing the outcome, with METR’s own follow-up research still unable to put a reliable number on where things stand today.

FAQ

Did the METR study prove AI coding tools make developers slower?
It proved that, for 16 experienced developers doing real maintenance work in large, familiar open-source codebases with early-2025 tools, measured time was about 19% longer with AI allowed. It did not establish that this holds for all developers, all tasks, or current tools; METR’s own 2026 follow-up suggests the picture may now be more favorable to AI, while cautioning that its new evidence is weak.

Why did developers in the METR study believe they were faster when they weren’t?
METR doesn’t fully explain the mechanism, but notes that developers forecast a 24% speedup beforehand and still estimated a roughly 20% speedup afterward despite the opposite result. This mirrors a broader pattern across the research covered here: self-reported speed consistently runs more positive than directly timed results.

Is GitHub’s 55%-faster Copilot statistic still relevant?
It’s a real, statistically significant result from a controlled study, but it dates to a 2022 Copilot preview and a single greenfield task (writing a new HTTP server), and it was run by the tool’s own maker. It says more about short, well-defined, from-scratch tasks than about day-to-day maintenance in large codebases.

Does the DORA report contradict METR’s findings?
Not directly; they measure different things. DORA tracks self-reported individual productivity and organization-level delivery throughput across a large survey population, while METR directly times a controlled sample of experienced developers on real tasks. DORA’s 2025 finding that AI adoption now correlates with higher throughput is an organizational, correlational result, not a controlled measurement of individual task speed.

What should a team take away from this research?
Treat vendor-reported and self-reported speedups skeptically, expect AI assistance to help more on unfamiliar, well-specified, or boilerplate-heavy work than on deep maintenance of complex systems a developer already knows well, and watch for the gap between how fast AI use feels and how fast it actually is.

Sources

Artificial Intelligence, Cloud & Infrastructure

Inside AWS’s AI Networking Stack: The Nitro System, EFA, and How Amazon Builds Infrastructure for Massive GPU Clusters in 2026

Posted on November 1, 2026 by Filip Keser

Nvidia builds the chips. AWS builds the plumbing. When Amazon talks about AI infrastructure, the conversation usually turns to Trainium chips or Bedrock’s managed models — but underneath both sits a less-discussed layer that is arguably just as important: the networking and virtualization stack that lets AWS wire tens of thousands of GPUs together into something that behaves like one giant computer. That stack has two main pieces — the Nitro System and the Elastic Fabric Adapter (EFA) — and this piece looks specifically at how they work and what they actually do.

At a Glance

Component	What It Is	Key Fact
Nitro System	Custom hypervisor and offload hardware underlying modern EC2 instances	Moves virtualization, networking, and storage I/O off the host CPU onto dedicated cards
Elastic Fabric Adapter (EFA)	OS-bypass network interface for HPC/AI workloads	Free add-on on supported instances; EFA on P5 delivers 3,200 Gbps per instance — 8× the prior generation
EC2 UltraClusters	Petabit-scale, non-blocking network connecting large GPU fleets	AWS and Nvidia described scaling to 20,000 H100 GPUs and 20 exaFLOPS (announced March 2023)

Short Verdict

AWS doesn’t win AI infrastructure on chips alone. The Nitro System and EFA are the plumbing that let it treat a rack — or tens of thousands of GPUs across many racks — as a single machine for training. Most of this is invisible unless you’re running distributed training or HPC workloads at scale, but it’s a real part of why AWS can credibly host frontier-scale training jobs at all.

What the Nitro System Actually Does

Every modern EC2 instance type is built on the Nitro System, AWS’s combination of dedicated offload hardware and a lightweight hypervisor. Instead of running networking, storage, and management functions as software on the same CPU that runs customer workloads, Nitro moves them onto dedicated cards:

Nitro Cards handle I/O offload for VPC networking, EBS storage, and instance storage, plus a Nitro Card Controller that coordinates them.
Nitro Security Chip moves virtualization and security functions to dedicated hardware and enforces a locked-down model that blocks administrative access — including, AWS states, by Amazon’s own employees.
Nitro Hypervisor is a lightweight hypervisor that only manages memory and CPU allocation; AWS describes its performance as indistinguishable from bare metal.
Nitro Isolation Engine enforces isolation between instances and between instances and AWS operators.
AWS Nitro Enclaves and NitroTPM provide isolated compute environments and a TPM 2.0-conformant module for cryptographic attestation, respectively — used for sensitive workloads handling PII, healthcare, or financial data.

The practical effect, per AWS’s own description, is that instances get “practically all” of the host’s compute and memory resources, because the host no longer has to reserve capacity for hypervisor or management overhead. That matters for GPU instances specifically: a Nitro-based host spends less CPU and memory on virtualization bookkeeping and more on feeding data to the GPUs.

What EFA Adds on Top

Nitro handles a single instance. Elastic Fabric Adapter (EFA) is what lets many instances act together. EFA is an optional network interface, available at no additional cost on supported instance types, that gives applications a custom OS-bypass hardware interface for inter-instance communication.

Normally, network traffic goes through the operating system’s TCP/IP stack and a standard network driver (AWS’s ENA). EFA skips that path: applications talk to the EFA device through the Libfabric API — the user-space API of the OpenFabrics Interfaces framework — bypassing the kernel entirely. Underneath, EFA uses AWS’s Scalable Reliable Datagram (SRD) protocol, which provides built-in congestion control and low-latency, reliable transport tuned for HPC and ML traffic patterns.

Because most HPC programming models (MPI) and ML collective-communication libraries (notably Nvidia’s NCCL, used by PyTorch, TensorFlow, MXNet, and others) already support Libfabric, AWS says existing distributed training code can usually move to EFA with little or no modification. On GPU instances, EFA also integrates with Nvidia GPUDirect RDMA, letting data move between GPU memory on different instances without an extra trip through host memory.

EFA Has Generations, and Support Varies by Instance

EFA isn’t one fixed spec — it has shipped in multiple versions tied to the underlying Nitro hardware generation, and not every EC2 instance family supports it. AWS’s own EC2 User Guide lists support roughly as follows:

Nitro Generation	EFA Version	Representative Instance Families
Nitro v3	EFA v1	p3dn, p4d/p4de, g4dn, g5, c5n, m5n/m5dn
Nitro v4	EFA v2	p5/p5e, trn1/trn1n, g6/g6e, c6i/c7i, hpc6a/hpc7a
Nitro v5	EFA v3	p5en, trn2/trn2u, c7gn, hpc7g
Nitro v6	EFA v4	p6-b200, p6e-gb200, g7/g7e, hpc8a

RDMA support also varies: older Nitro v3 instances mostly lack RDMA write support, while Nitro v4 and later support RDMA read broadly and RDMA write on most types. EFA traffic cannot cross Availability Zones or VPCs and is not routable — it’s built for tightly-coupled, low-latency communication within a cluster placement group, not general-purpose networking.

How It Comes Together in EC2 UltraClusters

Nitro and EFA combine most visibly in EC2 UltraClusters — AWS’s term for large-scale deployments of GPU instances connected by a petabit-scale, non-blocking network and backed by Amazon FSx for Lustre for high-throughput storage. When AWS and Nvidia announced EC2 P5 instances in March 2023, each P5 instance packed eight Nvidia H100 GPUs, 640 GB of high-bandwidth GPU memory, and 16 petaFLOPs of mixed-precision performance — and used AWS’s second-generation EFA to deliver 3,200 Gbps of networking per instance, eight times the prior generation, integrated with GPUDirect RDMA. AWS and Nvidia stated that UltraClusters built from P5 instances could scale to 20,000 H100 GPUs working together, delivering up to 20 exaFLOPS of aggregate performance, and that some customers were already training models across more than 10,000 GPUs.

This is a different layer from the one covered in our look at AWS’s Trainium and Inferentia chips or Bedrock and SageMaker’s managed AI services. Nitro and EFA are infrastructure that underpins both Nvidia-GPU-based instances (P5, P6) and AWS’s own Trainium-based instances (Trn1, Trn2) — the networking fabric doesn’t care which chip is doing the math.

Trade-offs and Limitations

Not every instance qualifies. EFA is tied to specific instance families and Nitro generations; older or smaller instance types don’t support it at all.
It’s AWS-specific plumbing. EFA competes conceptually with Nvidia’s own InfiniBand and NVLink/Spectrum-X networking (covered in our piece on Nvidia’s networking stack), so workloads tuned tightly for one fabric may need adjustment to move to another cloud or on-prem InfiniBand cluster.
Documented benchmarks are vendor-published. AWS’s own pages cite internal figures (the 4x CFD scaling improvement over its standard ENA networking, for instance) rather than independent third-party benchmarks; treat vendor performance claims as directional, not guaranteed for every workload.
EFA is not routable. It only works within a single cluster placement group in one Availability Zone, so it solves tightly-coupled cluster communication, not general cross-region networking.

Who Should Care

ML infrastructure engineers and platform teams evaluating cloud GPU providers for large-scale distributed training are the main audience — if you’re comparing cloud GPU platforms, the networking fabric underneath the GPU count is often the deciding factor for how well training actually scales past a handful of nodes. If your workloads are single-instance, inference-only, or small-batch, Nitro’s general virtualization benefits still apply, but EFA’s benefits are mostly invisible to you.

Bottom Line

The Nitro System and EFA are the unglamorous but essential layer that turns a pile of GPU instances into a cluster that can actually train large models efficiently. Nitro lowers virtualization overhead on every instance; EFA, where supported, removes the kernel networking bottleneck between instances and lets AWS wire tens of thousands of GPUs into UltraClusters with petabit-scale, non-blocking networking. None of it replaces chip choice or managed-service convenience — it’s the plumbing that makes both of those actually scale.

FAQ

Is EFA free to use?
Yes — AWS states EFA is available at no additional cost on supported instance types; you pay the normal EC2 instance price.

Does EFA work with Nvidia GPUs?
Yes. On GPU instances like the P5 family, EFA integrates with Nvidia GPUDirect RDMA to move data between GPU memory on different instances with lower latency.

What is SRD?
Scalable Reliable Datagram is AWS’s custom transport protocol underlying EFA. AWS describes it as providing built-in congestion control and low-latency, reliable delivery suited to HPC and ML traffic patterns, as an alternative to standard TCP.

How large can an EC2 UltraCluster get?
In their March 2023 joint announcement, AWS and Nvidia described UltraClusters built on P5 instances scaling to 20,000 H100 GPUs, delivering up to 20 exaFLOPS of aggregate compute performance.

Sources

Artificial Intelligence, Cloud & Infrastructure

Google’s TPU Chips Explained: Inside Trillium, Ironwood, and How They Stack Up Against Nvidia GPUs for AI Training in 2026

Posted on November 1, 2026 by Filip Keser

Nvidia’s GPUs get most of the attention in the AI infrastructure conversation, but Google has been building and running its own AI chips since 2015 — and today they train and serve a meaningful share of the world’s largest AI workloads, including Google’s own Gemini models. Tensor Processing Units (TPUs) are purpose-built silicon that Google rents out through Google Cloud, and in 2026 the lineup looks very different from even a year ago. Here’s what a TPU actually is, what Google currently offers, what it costs, and how the trade-offs against Nvidia GPUs really break down.

At a Glance

What it is	Google’s custom ASIC accelerators for AI training and inference, available only on Google Cloud
Current flagship generations	Ironwood (7th gen) and Trillium (6th gen) — both generally available
Coming soon	TPU 8t (large-scale pre-training) and TPU 8i (post-training and inference)
Core architecture	Systolic-array Matrix Multiplier Unit (MXU), not a general-purpose GPU core
On-demand price	$1.20/chip-hour (TPU v5e) up to $12.00–$13.20/chip-hour (Ironwood), region-dependent
Where you can get one	Google Cloud only — not available from other cloud providers or on-prem
Software support	JAX and OpenXLA natively; PyTorch via TorchTPU; vLLM and SGLang for inference

Short Verdict

TPUs are a legitimate, fast-moving alternative to Nvidia GPUs for teams already building on Google Cloud or on JAX/PyTorch-XLA — especially at the largest training scales, where Google’s co-designed networking and software stack pay off. They are not a drop-in GPU replacement: you’re locked into Google Cloud, the software ecosystem is narrower than CUDA’s, and the newest chip (Ironwood) carries a steep per-chip-hour price. For most teams outside Google’s own ecosystem, Nvidia GPUs remain the path of least resistance; for teams running JAX-based research or large-scale inference on Google Cloud already, TPUs are worth serious evaluation.

What a TPU Actually Is

A TPU is an application-specific integrated circuit (ASIC) — silicon designed from the ground up for one job, rather than a general-purpose chip adapted to that job. Google designs TPUs specifically to accelerate the matrix multiplication and tensor operations that dominate neural network training and inference, and it co-designs the chip alongside the software stack that runs on it.

The core of every TPU is the Matrix Multiplier Unit (MXU), built around a systolic array: thousands of arithmetic logic units (ALUs) arranged so that data is read from memory once and then flows continuously through the array, with partial results accumulating as they pass from one ALU to the next. That’s fundamentally different from a GPU’s architecture, where thousands of general-purpose cores repeatedly read and write to memory as they execute many parallel threads (an approach called SIMT, or single-instruction, multiple-thread). The systolic-array design cuts down on memory traffic for the specific pattern of repeated matrix multiplications in a neural network, which is where TPUs get much of their efficiency advantage for that one workload — at the cost of being far less flexible for other kinds of computation.

TPUs also lean heavily on reduced-precision arithmetic (16-bit and 8-bit floating point formats) to push more computations through the same silicon without sacrificing the accuracy modern AI models need. And they’re designed from day one to work in large groups: a pod is a big cluster of TPU chips wired together over Google’s high-speed interconnect (described by Google as Optical Circuit Switching, branded “Virgo”), and a slice is a smaller, rentable chunk of a pod — which is what you actually provision on Google Cloud.

The Current Lineup: Ironwood and Trillium

As of 2026, Google lists two generally-available flagship TPU generations on its Cloud TPU product page:

Generation	Status	What Google says it’s for	Headline spec Google cites
Ironwood (7th gen)	Generally available	Training, reasoning, and inference	9,216 liquid-cooled chips per pod; 42.5 ExaFLOPS per pod; up to 4x the performance per chip versus Trillium
Trillium (6th gen)	Generally available	Training and inference	4.7x higher peak compute per chip than TPU v5e; 67% more energy-efficient than v5e
TPU v5p / v5e	Still available, lower cost	General training (v5p) and cost-efficient training/inference (v5e)	Used by Google as the baseline Trillium is measured against
TPU 8t / TPU 8i	Coming soon (announced, not yet GA)	8t: large-scale pre-training and embedding-heavy workloads. 8i: post-training and low-latency inference	8t: 9,600 chips per superpod, ~3x compute per pod vs. the prior generation. 8i: Google claims an 80% performance-per-dollar improvement over previous generations for low-latency inference on large mixture-of-experts (MoE) models

Google also says its Google Kubernetes Engine (GKE) can scale a single cluster up to 130,000 nodes, and that a cluster can span up to 1 million TPU chips — figures aimed squarely at the handful of organizations training frontier-scale models, not at a typical engineering team.

What It Costs

Cloud TPU pricing is quoted per chip-hour, though the Google Cloud console bills by VM-hour (a single TPU host can bundle multiple chips, so the displayed hourly rate is higher than the per-chip figure). On-demand, region-dependent prices from Google’s own pricing page:

Generation	Representative on-demand price (per chip-hour)
Ironwood (v7)	$12.00 (us-central1) to $13.20 (europe-west2)
Trillium (v6e)	$2.70 (us-east1 / us-east5) to $3.24 (asia-northeast1)
TPU v5p	$4.20 (us-east1 / us-east5)
TPU v5e	$1.20 (most US regions) to $1.56 (Europe/Asia)

Committed-use discounts, spot pricing, and reservations can all bring these numbers down substantially; the figures above are the standard on-demand rate. Note that these prices exist only on Google Cloud — unlike Nvidia GPUs, which you can rent from dozens of providers (AWS, Azure, Oracle, CoreWeave, Lambda, and many more) or buy outright, a TPU is a Google Cloud exclusive.

TPU vs. Nvidia GPU: The Honest Trade-Offs

Google doesn’t publish head-to-head TPU-vs-GPU benchmarks on its own product pages, and neither does Nvidia for the reverse comparison, so treat any specific “TPU is X% faster/cheaper than GPU Y” claim you see elsewhere with caution unless it cites a reproducible, apples-to-apples benchmark. What can be said reliably, based on how each platform is actually built and sold:

Dimension	TPU	Nvidia GPU
Architecture	Purpose-built systolic array (MXU) for matrix multiplication	General-purpose SIMT cores, usable for AI and non-AI parallel workloads alike
Software ecosystem	Native JAX/OpenXLA; PyTorch via TorchTPU; narrower third-party tooling	CUDA — the most mature, widely supported accelerator software ecosystem in the industry
Where you can run it	Google Cloud only	Virtually every major cloud, specialized GPU clouds, and on-prem
Best-documented strength	Large, co-designed pods for frontier-scale training and inference within Google’s own stack	Breadth — the default choice for nearly any framework, model, or deployment target
Vendor lock-in	High — tied to Google Cloud and (mostly) to JAX/XLA-friendly workflows	Low to moderate — GPUs and CUDA code are portable across many providers

Who Should Care

Teams already standardized on Google Cloud, or using JAX for research, are the clearest fit — Google’s own frontier models (including Gemini) are trained on TPUs, which is the strongest existing proof that the stack scales. Teams running PyTorch workloads that need broad framework and library compatibility, multi-cloud flexibility, or on-prem hardware are better served sticking with Nvidia GPUs, at least until TorchTPU support matures further. Cost-sensitive inference workloads on large MoE models are worth watching closely once TPU 8i reaches general availability, given Google’s stated performance-per-dollar target.

Bottom Line

TPUs are not a marketing afterthought — they’re a real, continuously-updated chip line that powers a meaningful share of the industry’s largest AI workloads, and the jump from v5e to Trillium to Ironwood represents genuine architectural progress. But “best chip” depends entirely on where you already live: inside Google Cloud with JAX-friendly code, TPUs are a strong and often cheaper-at-scale option; everywhere else, Nvidia’s ecosystem breadth is still the safer default.

FAQ

Can I buy a TPU and run it myself?
No. TPUs are not sold as hardware; they are only available as a rented Google Cloud service.

Does TPU support mean I have to rewrite my PyTorch code?
Not entirely — Google supports PyTorch on TPUs through TorchTPU, but JAX and OpenXLA remain the most natively supported and best-documented path.

Is Ironwood always the right choice over Trillium?
Not necessarily. Ironwood costs roughly 4–5x more per chip-hour than Trillium, so unless your workload needs Ironwood’s extra headroom, Trillium (or even v5e for lighter jobs) may be the more cost-effective choice.

Are TPU 8t and TPU 8i available now?
No — as of this writing, Google lists both as “coming soon” rather than generally available. Check Google’s Cloud TPU release notes for the current launch status before planning around them.

Sources

Artificial Intelligence, Cloud & Infrastructure

Oracle Database 23ai and the Oracle–Nvidia Partnership: What “AI Database” Actually Means in 2026

Posted on November 1, 2026 by Filip Keser

Oracle talks about “AI” in two very different senses, and the two get blurred together in a lot of coverage. One is a feature inside the database engine: Oracle Database 23ai’s AI Vector Search, which lets you store and query embeddings alongside ordinary rows without standing up a separate vector database. The other is an infrastructure deal: Oracle’s expanding partnership with Nvidia to put GPU capacity — from H200s to Blackwell-generation GB200 NVL72 racks — inside Oracle Cloud Infrastructure (OCI). This piece pulls those two threads apart and checks what Oracle’s own documentation actually supports.

At a Glance

Thing	What Oracle states
Core DB feature	AI Vector Search — native vector data type, approximate (HNSW) and exact/partitioned indexes, built into SQL
Cost of Vector Search	No additional charge on Autonomous Database, Exadata Database Service, and Oracle Database Free (cloud services); on-prem Standard/Enterprise Edition pricing isn’t stated on the feature page
23ai status	Long-term support release, renamed from “23c” to “23ai” and made generally available for enterprises in 2024
Nvidia GPUs on OCI	H200 Tensor Core (GA), GB200 NVL72 (live, liquid-cooled racks), Vera Rubin NVL72 (listed, no specs given)
OCI Supercluster scale	Up to 260 exaFLOPS with Hopper GPUs; 2.4 zettaFLOPS with Blackwell GPUs (Oracle’s own figures, not independently benchmarked)
DGX Cloud	GB200 NVL72 racks available through both NVIDIA DGX Cloud and OCI directly
Pricing transparency	No public per-GPU or per-cluster price list for OCI Nvidia instances

Short Verdict

AI Vector Search is a genuinely useful, well-documented feature if you’re already an Oracle Database shop — it saves you from bolting on a separate vector database for retrieval-augmented generation (RAG). The Nvidia partnership is real and substantial (Oracle is one of the launch partners for GB200 NVL72 at scale), but Oracle’s own marketing pages give performance superlatives (“largest, fastest AI supercomputer in the cloud”) without GPU counts, bandwidth figures, or prices to back them up. Treat the database feature as verified and ready to evaluate; treat the infrastructure claims as directionally true but not independently confirmed.

What It Is: Two Separate Stories Under One Banner

Oracle Database 23ai (first shown as “23c” at Oracle CloudWorld in September 2023, and renamed and made broadly available in 2024) is a long-term support release of the core database. Its headline addition is AI Vector Search: a native VECTOR data type, so embeddings sit in the same tables as your relational, JSON, text, spatial, and graph data instead of in a bolted-on vector store. That is the product story.

Separately, Oracle and Nvidia have an infrastructure partnership that predates and extends past 23ai: Oracle Cloud Infrastructure offers Nvidia GPUs — up through the latest Blackwell-generation GB200 NVL72 racks — as “OCI Superclusters,” and Nvidia’s own DGX Cloud service runs some of its training capacity on that same OCI hardware. The database feature doesn’t require this specific Nvidia hardware to work; the two are related mainly in that Oracle markets both under an “AI” umbrella and because AI Vector Search can call out to Nvidia NIM inference containers for embedding generation.

How AI Vector Search Actually Works

Capability	What it does, per Oracle’s documentation
Native VECTOR type	Stores vectors directly in ordinary tables, supporting multiple dimension counts/formats; sparse vectors store only non-zero values
Vector generation	Import an embedding model in ONNX format and generate vectors inside the database, call out to NVIDIA NIM containers, or import pre-computed vectors
Indexes	In-memory HNSW (approximate) graph index for speed; neighbor-partition indexes for very large datasets; hybrid indexes combine full-text and vector search
Distance metrics	Built-in Euclidean, cosine, and dot product, plus user-defined custom distance functions
Query model	Similarity search is plain SQL, combinable in the same query with relational, JSON, text, spatial, and graph predicates
RAG support	A LlamaIndex integration and a “Select AI” feature that turns natural-language prompts into SQL using OCI Generative AI or third-party LLMs
Iceberg support	Similarity search can run directly over Apache Iceberg tables without first loading embeddings into the database

Oracle also says Exadata System Software 24ai adds an “AI Smart Scan” that offloads part of vector search to storage servers, and that OCI GoldenGate 23ai can replicate vectors in real time across different vector stores. Both are Exadata/cloud-tier features rather than something every 23ai installation gets automatically.

The Nvidia Side: OCI Superclusters and DGX Cloud

On the infrastructure side, Oracle’s current Nvidia lineup (per oracle.com/cloud/nvidia) includes general availability of OCI Supercluster with H200 Tensor Core GPUs, live liquid-cooled GB200 NVL72 racks available through both OCI directly and NVIDIA DGX Cloud, and an announced (but unspecified) Vera Rubin NVL72 tier for future training and inference workloads. Oracle’s claimed Supercluster scale is up to 260 exaFLOPS on Hopper-generation GPUs and 2.4 zettaFLOPS on Blackwell — figures Oracle presents as capable of training trillion-parameter models, with “ultrafast RDMA cluster networking” tying nodes together, bare-metal instances with no virtualization overhead, and orchestration through OCI Kubernetes Engine (OKE).

Oracle doesn’t publish the GPU counts behind those FLOPS figures, the actual network bandwidth, or a price list for renting Supercluster capacity — all of that requires talking to Oracle sales. NVIDIA AI Enterprise software is available natively inside the OCI console (Oracle cites “more than 160 AI tools”), and NIM inference endpoints are distributed through the OCI Marketplace, which is the most concrete link back to the database side: a 23ai instance can call a NIM container running on this same Nvidia infrastructure to generate the embeddings it stores.

Pros

Vector search lives inside the database you already run — no separate vector-database vendor, no separate data-sync pipeline
AI Vector Search is explicitly free of additional charge on Autonomous Database, Exadata Database Service, and Oracle Database Free
Multiple index types (HNSW for speed, partitioned for scale) and built-in distance metrics cover most RAG use cases out of the box
The Nvidia partnership gives Oracle customers a path to current-generation GB200/Blackwell capacity without a separate relationship with Nvidia or a hyperscaler

Cons

Oracle’s “free” claim for AI Vector Search is documented for its own cloud services and the Free edition — it is not clearly stated whether on-premises Standard or Enterprise Edition customers get it at no extra licensing cost, and third-party licensing-advisory sites report enough ambiguity here that you should confirm directly with Oracle or a licensing specialist before assuming
Supercluster performance figures (exaFLOPS, zettaFLOPS) are Oracle’s own marketing numbers, not independently benchmarked, and the underlying GPU counts aren’t disclosed
No public pricing for OCI Nvidia GPU instances or Superclusters — budgeting requires a sales conversation
The database feature and the GPU infrastructure are only loosely coupled; you can use 23ai’s vector search with any embedding model and don’t need Oracle’s Nvidia capacity to benefit from it

Who It’s a Good Fit For

Teams already standardized on Oracle Database who want to add RAG or semantic search without introducing a new vector-database dependency are the clearest fit for AI Vector Search. For the Nvidia infrastructure side, organizations that are already OCI customers, or that specifically want GB200/Blackwell capacity without negotiating directly with Nvidia or AWS/Azure/GCP, have a legitimate reason to look at OCI Superclusters — though they should get firm pricing in writing before committing.

Who Should Look Elsewhere

If you’re not already running Oracle Database, the vector-search feature alone isn’t a strong reason to migrate — dedicated vector databases and extensions for Postgres (pgvector) or other engines solve the same problem with less lock-in. For raw GPU capacity, teams that need transparent, published per-hour pricing should compare OCI’s actual quoted rates against AWS, Azure, and GCP before assuming Oracle is cheaper or faster; none of the performance superlatives on Oracle’s page are independently verifiable from the page itself.

Bottom Line

“AI Database” at Oracle really means two things bundled under one marketing phrase: a solid, well-documented set of in-database vector search and RAG capabilities in Database 23ai, and a large but opaque Nvidia GPU infrastructure deal that supplies the compute for training and inference elsewhere in Oracle’s cloud. The database feature is concrete enough to evaluate today. The infrastructure claims are the kind of numbers you verify with a sales rep, not the kind you take from a marketing page.

FAQ

Is Oracle Database 23ai the same as 23c?
Yes. Oracle renamed the long-term support release from “23c” to “23ai” and made it generally available for enterprises in 2024, citing the AI-focused features as the reason for the rename.

Do I need Nvidia GPUs to use AI Vector Search?
No. Vector generation can use an imported ONNX embedding model, pre-computed vectors, or an NVIDIA NIM container — the last option is convenient if you’re already on OCI, but it isn’t a requirement.

Is AI Vector Search really free?
Oracle states it’s available at no additional charge on Autonomous Database, Exadata Database Service, and Oracle Database Free. Whether that extends to on-premises Standard or Enterprise Edition licenses isn’t stated on Oracle’s feature page, so confirm with Oracle directly if that’s your deployment model.

What’s the difference between OCI Supercluster and NVIDIA DGX Cloud?
They can be the same underlying hardware. Oracle says GB200 NVL72 racks are available through both OCI directly and through NVIDIA DGX Cloud running on OCI infrastructure — the choice is mainly about which company’s service layer and support you’re buying.

Where can I get actual OCI Nvidia GPU pricing?
Oracle does not publish per-GPU or per-cluster rates for its Nvidia Supercluster offerings on its marketing pages; pricing requires contacting Oracle sales.

Sources

Artificial Intelligence, Cloud & Infrastructure

IBM watsonx.ai and the Granite Model Family: IBM’s Open, Developer-Facing Approach to Enterprise AI in 2026

Posted on November 1, 2026November 1, 2026 by Filip Keser

IBM’s enterprise AI infrastructure gets covered for its silicon — the Power11 chip and the Telum II mainframe accelerator. But IBM is also running a separate, less hardware-centric play: an AI platform called watsonx.ai, paired with a family of openly licensed foundation models called Granite. Together they’re IBM’s answer to the question developers actually ask — not “whose chip is fastest,” but “can I build on this without getting locked into a single vendor’s weights.” Here’s what watsonx.ai and Granite actually offer as of early 2026, verified against IBM’s own documentation and model cards.

At a Glance

Platform	watsonx.ai (IBM’s AI development platform) + Granite (IBM’s open foundation model family)
Granite license	Apache 2.0 (per IBM’s Granite 4.2 release)
Latest Granite generation	Granite 4.2 (language models at 3B, 8B, and 30B parameters)
Model types in the family	Language, vision, speech, embedding, guardrail (“Guardian”), and time-series models
Where to run Granite	watsonx.ai, Hugging Face, Ollama, LM Studio, OpenRouter, Replicate, Weights & Biases, Unsloth, AnythingLLM, Red Hat Enterprise Linux AI
Reported SWE-Bench Verified (pass@1)	47.67 (8B), 57.00 (30B) — IBM’s own published figures
Best for	Enterprises and developers who want an open-weight model they can self-host, fine-tune, or audit, plus a managed platform to deploy it

Short Verdict

Granite is a genuinely open (Apache 2.0) model family that’s small enough to self-host cheaply and is distributed across nearly every popular runtime, which is unusual for a model backed by a large enterprise vendor. watsonx.ai is the more conventional piece: a managed platform for deploying Granite, Meta’s Llama, Mistral’s models, and others, with API-level controls aimed at regulated enterprises. Neither is the most capable option on raw benchmarks against today’s frontier models, but the combination — open weights plus an enterprise deployment layer — is IBM’s real differentiator.

What Is watsonx.ai?

watsonx.ai is IBM’s hosted platform for building, tuning, and deploying AI models, available on IBM Cloud and on-premises through watsonx as a Service. It isn’t a single model — it’s a catalog-and-tooling layer. Developers pick a foundation model from a growing list (IBM’s own Granite family alongside third-party models such as Meta’s Llama and Mistral’s releases), then use watsonx’s APIs, notebooks, and AutoAI tooling to prompt, tune, or build retrieval-augmented pipelines on top of it.

IBM’s own changelog shows a platform under active, fairly rapid iteration. Recent additions include a chat API with explicit controls over model reasoning depth and response detail (added November 2025), a preview “model gateway” that routes requests across multiple LLM providers through one resource hub (October 2025, Toronto region only at launch), a text-classification API for pre-sorting documents before extraction, and a dedicated watsonx Developer Hub with quick-start guides (November 2025). On the other side of the ledger, IBM has also been retiring older capabilities — prompt tuning was removed from all data centers in October 2025, and Federated Learning was removed in September 2025 — which is worth knowing if you’re building on a feature you saw in older IBM marketing material.

What Is the Granite Model Family?

Granite is IBM’s line of foundation models, released under the Apache 2.0 license — meaning the weights are downloadable and usable commercially without the restrictions some competing “open” models carry. The family spans more than text: IBM groups language, vision, speech, embedding, a safety/content-moderation line called Guardian, and time-series forecasting models under the Granite name, though not all of those sub-families have reached the same generation number.

The current flagship generation, Granite 4.2, ships language models at three sizes — 3B, 8B, and 30B parameters — small enough that the 8B and even the 30B variant can realistically run on a single modern GPU or a well-resourced CPU server, rather than requiring a data-center cluster. IBM publishes its own benchmark results for these three sizes:

Benchmark	Granite 4.2 3B	Granite 4.2 8B	Granite 4.2 30B
MMLU-Pro (5-shot)	67.84	74.04	77.60
GPQA (pass@1)	54.80	64.14	66.41
AIME25 (pass@1)	78.33	86.67	89.17
SWE-Bench Verified (pass@1)	N/A	47.67	57.00
Arena-Hard-V2 (win rate)	34.96	65.19	67.93

These are IBM’s self-reported figures from its own Granite documentation, not an independent third-party leaderboard, so treat them as a starting point rather than the final word — as with any vendor-published benchmark, it’s worth checking an independent leaderboard for the specific use case you care about before committing.

Where You Can Actually Use Granite

This is the part that distinguishes Granite from most enterprise-backed model families: IBM has pushed it onto nearly every popular runtime rather than keeping it inside watsonx. According to IBM’s own Granite page, the models are available through:

Hugging Face (the models are hosted directly under the ibm-granite organization)
Ollama and LM Studio, for running locally on a laptop or workstation
watsonx.ai, for IBM’s managed enterprise deployment path
OpenRouter and Replicate, for pay-per-call hosted inference
Weights & Biases and Unsloth, aimed at fine-tuning workflows
AnythingLLM, for retrieval-augmented chat apps
Red Hat Enterprise Linux AI, IBM’s own enterprise Linux distribution with built-in support for running Granite

On Hugging Face, the individual model pages back this up with real usage signals rather than marketing claims: granite-4.2-8b shows roughly 69,000 downloads and granite-4.2-30b around 36,000, with smaller but active download counts on the speech and switch-routing variants — evidence that developers outside IBM’s own customer base are actually pulling these weights.

Pros

Granite’s Apache 2.0 license is genuinely permissive — no field-of-use restrictions to parse before you ship a commercial product
Small model sizes (3B–30B) make self-hosting realistic without a large GPU cluster
Distributed across almost every popular open-model runtime, not locked into IBM’s own platform
watsonx.ai gives enterprises a managed, auditable deployment path if they don’t want to run inference infrastructure themselves
Dedicated Guardian models for content moderation/safety are a distinct, less common offering among open model families

Cons

Benchmark figures are IBM’s own; there’s no independent third-party confirmation cited on the official page
Granite’s largest published language model (30B) is well below the parameter count of today’s frontier proprietary models, so it’s not positioned to compete on raw general-purpose capability
watsonx.ai’s feature set is still being actively reshuffled — capabilities like prompt tuning and Federated Learning have already been removed within the last several months, so documentation and tutorials age quickly
Some Granite sub-families (vision, embedding) lag the language models in generation number and weren’t fully visible in IBM’s own published model list at the time of writing

Who It’s a Good Fit For

Granite suits teams that want to self-host or fine-tune an open-weight model without wading through restrictive licensing, and that don’t need frontier-level general capability — document processing, internal chat assistants, classification, and retrieval-augmented generation are reasonable fits at the 8B–30B range. watsonx.ai suits regulated enterprises (finance, healthcare, government) that want a single managed platform to deploy Granite alongside other models like Llama or Mistral, with IBM’s audit and governance tooling layered on top.

Who Should Look Elsewhere

If you need the strongest possible general-purpose reasoning or coding performance regardless of openness, today’s frontier proprietary models will generally outperform Granite’s current 30B ceiling. And if you have no interest in IBM’s platform tooling and just want an open model, you may find a more actively-benchmarked open-weight alternative with a larger community already built around it.

Bottom Line

IBM’s AI infrastructure story isn’t only about silicon. Granite is a legitimately open, portable model family that doesn’t try to compete at the frontier, and watsonx.ai is a maturing — if fast-changing — managed platform for enterprises that want governance and deployment tooling around it. If your priority is license freedom and runtime flexibility over raw benchmark supremacy, it’s worth evaluating; if you need the absolute top of the leaderboard, look elsewhere first.

FAQ

Is Granite free to use commercially?
Yes — IBM releases Granite models under the Apache 2.0 license, which permits commercial use without the field-of-use restrictions some other “open” model licenses carry.

Do I need watsonx.ai to run Granite?
No. Granite is also distributed through Hugging Face, Ollama, LM Studio, OpenRouter, Replicate, and other runtimes, so you can self-host it entirely outside IBM’s platform.

How big is the largest Granite 4.2 language model?
30 billion parameters, according to IBM’s own Granite 4.2 documentation, alongside 8B and 3B variants.

Is watsonx.ai only for Granite models?
No — IBM’s own changelog shows the platform also hosting Meta Llama and Mistral models for deployment, alongside Granite.

Sources

Artificial Intelligence

How Good Is AI at Writing Code? SWE-bench, HumanEval, and What AI Coding Benchmarks Actually Measure

Posted on November 1, 2026 by Filip Keser

Every time a new AI model launches, its announcement includes a chart of benchmark scores — and coding benchmarks are usually front and center. But “74.5% on SWE-bench Verified” means very little unless you know what the benchmark is actually testing, how the number is computed, and what it leaves out. This guide breaks down the three benchmarks that dominate AI coding discussions — HumanEval, SWE-bench (and its Verified subset), and LiveCodeBench — and what their scores can and can’t tell you about a model you’re considering using for daily coding work.

At a Glance

Benchmark	What It Measures	Maintained By	Size
HumanEval	Whether generated code passes hand-written unit tests for a self-contained function	OpenAI (now archived/unmaintained)	164 hand-written problems
SWE-bench / SWE-bench Verified	Whether a model can resolve a real, previously-filed GitHub issue in an existing codebase	Independent academic team; Verified subset curated with OpenAI	2,294 instances (full); 500 (Verified)
LiveCodeBench	Code generation, self-repair, execution prediction, and test-output prediction on fresh contest problems	UC Berkeley, MIT, and Cornell researchers	Growing pool of dated contest problems from LeetCode, AtCoder, Codeforces

Short Verdict

No single benchmark tells the whole story. HumanEval tests isolated, textbook-style functions and is now considered too easy and too familiar to current models to be a meaningful differentiator. SWE-bench Verified is the closest thing the industry has to a real-world coding test, because it uses actual GitHub issues and actual codebases — but it is Python-only and still doesn’t capture everything about a messy, undocumented production repo. LiveCodeBench’s main contribution isn’t a different skill test so much as a defense against contamination: by dating every problem, it can tell you whether a model is actually reasoning or just recalling training data. Read all three together, and read them skeptically.

Why Coding Benchmarks Exist — and Why There Are So Many

A benchmark is only useful if it’s hard to game. The earliest code-generation tests simply asked a model to complete a function and checked whether the output compiled or looked plausible — which told you almost nothing about correctness. As models got better, each new benchmark had to raise the bar: first by actually running the generated code against tests, then by using realistic, large-codebase tasks instead of toy problems, and most recently by controlling for the possibility that a model has simply memorized the answer from its training data. HumanEval, SWE-bench, and LiveCodeBench represent three successive generations of that arms race.

HumanEval: The Original Pass@1 Test

HumanEval was introduced by OpenAI in the 2021 paper “Evaluating Large Language Models Trained on Code” (the paper behind the original Codex model) and shipped as an open evaluation harness, openai/human-eval, on GitHub. It consists of 164 hand-written programming problems, each made up of a function signature, a docstring describing the task, a reference solution, and a set of unit tests. A model is given the signature and docstring and has to generate the function body; the harness then runs the generated code against the hidden unit tests.

Scoring uses the pass@k metric: a model generates k independent samples for a problem, and pass@k estimates the probability that at least one of those k samples passes all tests. Pass@1 — a single attempt — is the figure most commonly quoted today. OpenAI’s own repository now flags human-eval as “deprecated and unmaintained,” kept only for historical reference; frontier models have been scoring near-ceiling on it for a while, which is exactly why the field moved on to harder tests.

SWE-bench Verified: Real GitHub Issues, Not Toy Problems

SWE-bench takes a fundamentally different approach: instead of writing new problems, it pulls 2,294 real, previously-resolved GitHub issues from 12 popular Python repositories. For each instance, the model is handed the original issue description and the state of the codebase at that commit, and has to produce a patch. That patch is graded by running the project’s actual test suite, including the tests that were added by the human-authored fix (so the model can’t pass by accident).

Because some of the original 2,294 instances turned out to be ambiguous, under-specified, or effectively unsolvable even by a correct human-equivalent patch, the SWE-bench team partnered with OpenAI to release SWE-bench Verified in August 2024: a 500-instance, human-filtered subset that has become the de facto standard that vendors quote at launch. It’s run inside a sandboxed agent scaffold (the official leaderboard’s default view uses a “Bash Only” mini-agent environment) so that different vendors’ agent setups are compared on a more even footing.

A useful, verified data point on what these scores mean in practice: in its own release notes for Claude Opus 4.5 (November 2025), Anthropic reported that the model matched its predecessor Sonnet 4.5’s best SWE-bench Verified score at a medium reasoning-effort setting while using 76% fewer output tokens, and exceeded Sonnet 4.5’s best score by about 4.3 percentage points at its highest reasoning-effort setting while using 48% fewer tokens — illustrating that on this benchmark, efficiency (tokens spent per correct patch) has become as much of a competitive axis as raw accuracy. Because every major lab resubmits new models to the public SWE-bench Verified leaderboard on a rolling basis, any specific score printed here would be stale within weeks — check the live leaderboard at swebench.com for current standings rather than relying on a single quoted figure.

LiveCodeBench: Fighting Contamination With Dates

The biggest problem with any fixed benchmark is contamination: once a benchmark’s problems and solutions circulate on the internet, they can end up in a later model’s training data, inflating its score without reflecting real reasoning ability. LiveCodeBench, built by researchers at UC Berkeley, MIT, and Cornell, addresses this directly by continuously collecting new competitive-programming problems from LeetCode, AtCoder, and Codeforces and tagging each one with its original release date. Because every problem is dated, a model can be evaluated only on the subset of problems released after its training cutoff — the leaderboard’s “scrolling over time” view lets you pick that window yourself.

LiveCodeBench also tests more than plain code generation: it scores models on self-repair (fixing a broken program from error feedback), code execution (predicting a program’s output without running it), and test-output prediction, in addition to generation — all measured with pass@1. That breadth makes it useful for spotting models that are good at writing code but weak at actually reasoning about what code does.

Comparing the Three

Benchmark	Strength	Main Limitation
HumanEval	Simple, fast, cheap to run; good historical baseline	Saturated — top models now near the ceiling; tests isolated functions, not real codebases
SWE-bench Verified	Uses real, previously-merged fixes to real GitHub issues in real codebases	Python-only; instances skew toward well-maintained open-source projects, not messy internal code
LiveCodeBench	Actively guards against training-data contamination via dated problems	Competitive-programming problems (LeetCode/Codeforces-style) still differ from day-to-day engineering work

What a Benchmark Score Doesn’t Tell You

It doesn’t measure performance on your actual codebase, your language/framework mix, or your team’s conventions.
It doesn’t capture agentic behaviors like asking clarifying questions, respecting existing architecture, or avoiding unnecessary refactors.
Scaffold and tooling differences (which agent harness, how many retries, how much “thinking” budget) can shift a score by several points independent of the underlying model.
A high score can still coexist with contamination risk if the benchmark’s problems predate the model’s training cutoff and aren’t excluded.

Who Should Care About These Benchmarks

Engineering leaders evaluating which AI coding assistant to standardize on should treat SWE-bench Verified as a reasonable first filter for raw problem-solving capability, but should still run a pilot on their own repositories before committing. Individual developers choosing between tools day-to-day will get more signal from hands-on trials and from LiveCodeBench’s self-repair and execution-prediction scores (which correlate better with “does this model actually understand what the code does”) than from a single headline HumanEval number, which is now close to meaningless as a differentiator.

Bottom Line

HumanEval told the industry that language models could write small, correct functions; it’s now largely retired as a serious differentiator. SWE-bench Verified is the current standard for measuring whether a model can act as a software engineer on a real, if still relatively clean, codebase. LiveCodeBench adds a contamination check that the other two lack. None of them replace testing a model on your own code — but together, they’re the most credible public signal available for comparing AI coding ability across vendors.

FAQ

Is a higher SWE-bench Verified score always better?
Generally yes for raw problem-solving ability, but check what agent scaffold and reasoning-effort setting produced the score — vendors often report their best configuration, which may cost more tokens or run slower than a default setting.

Why don’t vendors still report HumanEval scores prominently?
Because frontier models now score so close to the ceiling on HumanEval that it no longer meaningfully distinguishes between them; the benchmark’s own maintainers have marked the original repository deprecated.

Can a benchmark score be inflated by contamination?
Yes — if a benchmark’s problems and solutions appear in a model’s training data, its score can rise without a real improvement in reasoning. LiveCodeBench was built specifically to counter this by timestamping every problem.

Where can I see current, up-to-date scores?
The official SWE-bench Verified leaderboard is published at swebench.com and updates as labs submit new runs; LiveCodeBench’s leaderboard is hosted on Hugging Face. Treat any benchmark number quoted in an article (including this one) as a snapshot, not a live figure.

Sources

Artificial Intelligence

Best AI Agent Frameworks for Developers in 2026: LangChain vs AutoGen vs CrewAI

Posted on November 1, 2026 by Filip Keser

“AI agent” products for end users — the kind that autocomplete your code or summarize your inbox — are only half the story. Underneath most of them sits an open-source framework that developers use to wire large language models into autonomous, multi-step workflows. Three names dominate that layer in 2026: LangChain (with its agent-orchestration companion LangGraph), Microsoft’s AutoGen, and CrewAI. They solve the same basic problem — getting one or more LLM-driven “agents” to plan, call tools, and hand off work — but they take meaningfully different approaches, and one of the three has just been formally retired in favor of a successor. Here’s what each actually offers, verified against their own repositories and pricing pages.

At a Glance

Framework	License	Development Status (2026)	Core Model	Paid Tier
LangChain / LangGraph	MIT (open source)	Actively developed	Chains and graphs of LLM calls, tools, and agents	LangSmith: free Developer plan, Plus $39/seat/mo + usage, custom Enterprise
AutoGen (Microsoft)	MIT (open source)	Maintenance mode — bug/security fixes only	Multi-agent conversation (agents “chat” to solve tasks)	None; community-managed. Successor: Microsoft Agent Framework
CrewAI	MIT (open source)	Actively developed	Role-based “crews” of agents with defined tasks	Free Cloud tier (50 executions/mo); custom Enterprise

Short Verdict

If you want the biggest ecosystem, the most integrations, and don’t mind a steeper learning curve, LangChain (via LangGraph for the agent-orchestration layer) is the default choice. If you want agents that behave like a structured team with clear roles and tasks, CrewAI is the more opinionated, often faster-to-prototype option. AutoGen is the one to be careful with: Microsoft’s own repository now states it is in maintenance mode and points new projects to Microsoft Agent Framework instead, so it’s a poor choice for anything you plan to build on for the next few years.

What Each One Is

LangChain describes itself, in its own GitHub README, as “a framework for building agents and LLM-powered applications.” It’s the oldest and most sprawling of the three, with hundreds of integrations for models, vector stores, and tools. LangGraph, a companion library, is what most teams now use specifically for building controllable, stateful agents on top of LangChain’s primitives. The company behind both also sells LangSmith, a separate paid observability and deployment platform — the open-source framework itself remains free and MIT-licensed.

AutoGen is Microsoft’s framework for “creating multi-agent AI applications that can act autonomously or work alongside humans,” per its own README. As of 2026, Microsoft’s repository carries an explicit notice: “AutoGen is now in maintenance mode.” It will not receive new features, remains under the microsoft GitHub organization, and is described as “community managed going forward,” with contributions limited to bug fixes, security patches, and documentation. Microsoft directs new users to a separate project, Microsoft Agent Framework, which it calls the “enterprise-ready successor to AutoGen,” along with a migration guide for existing AutoGen users.

CrewAI bills itself as a “Framework for orchestrating role-playing, autonomous AI agents.” Rather than modeling agents as a graph of arbitrary steps, CrewAI organizes work around a “crew”: a set of agents, each with a role, goal, and backstory, assigned to specific tasks. Its own FAQ describes it as a “standalone Python framework with its own primitives” rather than a layer built on top of LangChain.

A Minimal Example

CrewAI’s role-based model is easiest to show in a few lines. This illustrates the shape of the API, not a guaranteed-working script — check current docs for exact argument names before running it:

from crewai import Agent, Task, Crew

researcher = Agent(
    role="Researcher",
    goal="Find and summarize recent facts on a topic",
    backstory="An analyst who double-checks every claim."
)

task = Task(
    description="Research current AI agent framework adoption trends",
    agent=researcher,
    expected_output="A short bulleted summary"
)

crew = Crew(agents=[researcher], tasks=[task])
result = crew.kickoff()

Pros and Cons

LangChain / LangGraph

Pros: Largest integration ecosystem of the three; LangGraph gives fine-grained control over agent state and branching; active, well-funded development; optional LangSmith adds tracing and evaluation.
Cons: Steeper learning curve and more abstractions to learn; LangSmith’s usage-based pricing (billed in “LangChain Standard Units”) can be hard to estimate in advance; some teams find the API surface large relative to what a simple agent needs.

AutoGen

Pros: Still free, open-source (MIT), and usable for existing projects or learning the underlying conversation-pattern concepts; backed by a large existing codebase and community of past adopters.
Cons: Officially in maintenance mode with no new features; Microsoft is actively steering new and existing users toward Microsoft Agent Framework; a risky foundation for a new, long-lived project in 2026.

CrewAI

Pros: Role-based model maps intuitively onto real team workflows; standalone design with its own primitives rather than a wrapper on another framework; free Cloud tier for small workloads; actively developed.
Cons: Less infrastructure-agnostic tooling (tracing, evaluation) than the LangChain ecosystem out of the box; Enterprise pricing isn’t public, so cost at scale requires a sales conversation.

Who It’s a Good Fit For

Teams that need maximum flexibility, lots of third-party integrations, and are willing to invest in learning a bigger framework should default to LangChain/LangGraph. Teams that think of their problem as “a small team of specialists handing off tasks” will likely prototype faster in CrewAI. Teams currently running AutoGen in production should start planning a migration to Microsoft Agent Framework, since Microsoft’s own repository says plainly that AutoGen won’t gain new features going forward.

Who Should Look Elsewhere

Anyone starting a brand-new multi-agent project in 2026 should not pick AutoGen as the long-term foundation, given its maintenance-mode status. Teams wanting a fully managed, no-code agent builder rather than a Python framework should also look elsewhere — all three of these are developer-facing libraries, not low-code platforms.

Bottom Line

All three frameworks are free and MIT-licensed at their core, so the real decision is architecture and longevity, not price. LangChain/LangGraph is the broad, extensible default; CrewAI is the faster, more structured option for role-based workflows; AutoGen is a known quantity that Microsoft itself is winding down in favor of Microsoft Agent Framework. For a new project, weigh LangGraph against CrewAI based on how your problem is shaped, and treat AutoGen as legacy.

FAQ

Is AutoGen dead?

Not dead, but no longer actively developed by Microsoft. Its own repository states it’s in maintenance mode, limited to bug fixes, security patches, and documentation, with Microsoft Agent Framework positioned as its successor.

Is CrewAI built on top of LangChain?

No. CrewAI’s own FAQ describes it as a standalone Python framework with its own primitives, independent of LangChain.

Do I have to pay to use any of these?

No — the core frameworks (LangChain, LangGraph, AutoGen, and CrewAI) are all free and open source under the MIT license. Paid tiers only apply to optional hosted add-ons: LangSmith for LangChain/LangGraph, and CrewAI’s Enterprise/Cloud offering.

Which one is easiest to learn first?

Most developers find CrewAI’s role/task/crew model quicker to grasp for a first project, while LangGraph’s graph-based state model takes longer to learn but scales to more complex, custom agent behavior.

Sources

Artificial Intelligence, Cloud & Infrastructure

Beyond the Chips: What Amazon Bedrock and SageMaker Actually Offer AWS’s AI Developers in 2026

Posted on October 31, 2026 by Filip Keser

AWS’s custom Trainium and Inferentia chips get a lot of attention as the hardware story behind Amazon’s AI push, but almost no developer touches that silicon directly. Most people building AI applications on AWS work through two higher-level services sitting on top of it: Amazon Bedrock and Amazon SageMaker. They solve different problems, and AWS itself publishes a decision guide explaining when to use which. Here’s what each one actually does.

At a Glance

Service	What It Is	Best For	Expertise Needed
Amazon Bedrock	Fully managed, serverless platform for building AI apps and agents on pre-trained foundation models	Prompting, retrieval-augmented generation, light model customization	Limited ML expertise
Amazon SageMaker AI	Platform for training, customizing, and deploying ML and foundation models with full infrastructure control	Custom training, fine-tuning, reinforcement learning, production ML pipelines	Deeper ML/infrastructure expertise

What Amazon Bedrock Actually Offers

AWS describes Bedrock as “a fully managed, serverless platform to build, run, and operate AI applications and agents at production scale.” In practice, Bedrock gives developers API access to more than 100 foundation models from multiple providers — including Amazon’s own Nova models, Anthropic’s Claude, and models from DeepSeek, Moonshot AI, MiniMax, OpenAI, and xAI — without provisioning any compute instances themselves. Bedrock exposes several API styles through its bedrock-runtime endpoint, including a Converse API, a Messages API, and OpenAI-compatible Responses and Chat Completions APIs, so teams can call different model providers through a largely consistent interface. AWS also builds customization directly into Bedrock: fine-tuning, continued pre-training, and model distillation, along with features like cross-Region inference for throughput and a built-in web search tool for grounding certain models in current information. AWS’s own guidance is direct about who this is for: “Amazon Bedrock is particularly useful if you have limited machine learning (ML) expertise or resources.”

What Amazon SageMaker Actually Offers

SageMaker sits a layer lower. AWS now positions the SageMaker family as “the center for all your data, analytics, and AI,” combining several components: SageMaker AI (the renamed core service) for training, customizing, and deploying models on managed infrastructure; SageMaker HyperPod for distributed training and orchestration across thousands of accelerators; SageMaker JumpStart, a catalog of pre-built and foundation models that can be deployed or further trained; SageMaker Unified Studio, a single development environment with a serverless notebook, SQL editor, and generative-AI app-building tools; and SageMaker Catalog and Lakehouse, which handle data governance and unified access to S3, Redshift, and other sources. Where Bedrock mostly abstracts infrastructure away, AWS recommends SageMaker AI specifically “when you need to access the container or orchestration layer to directly manage cost-latency-throughput and other tradeoffs” — in other words, when a team needs to actually control how and where a model runs.

How They Differ, Side by Side

Category	Amazon Bedrock	Amazon SageMaker AI
Model access	100+ pre-trained foundation models via API	JumpStart catalog of roughly 1,000 models, plus fully custom models
Customization	Automated fine-tuning, continued pre-training, distillation, custom model import	Serverless SFT/DPO, reinforcement learning (RLVR/RLAIF), full training jobs, HyperPod
Infrastructure	Serverless, no instances to manage	Serverless for light customization; full instance/endpoint/HyperPod control otherwise
Pricing model	Per-token, with Priority/Flex/Reserved tiers and batch discounts up to 50%	Per-token for serverless customization; usage-based compute pricing otherwise, with Savings Plans up to 64% off
Typical user	App teams with limited ML expertise	ML/infrastructure teams needing deep control

Where the Custom Silicon Actually Shows Up

This is where the chips re-enter the picture. AWS’s own architecture diagram for this comparison places “AI chips (Trainium, Graviton, NVIDIA GPUs)” at the base layer of the stack, with Bedrock and SageMaker both sitting above it as “models training and inferencing” services. In practice, the two expose that hardware very differently. SageMaker is explicit about it: AWS states that “SageMaker AI also supports cost-optimized hardware including AWS Trainium for training and AWS Inferentia for inference,” and customers choose instance types much as they would with EC2. Bedrock is serverless by design, so AWS does not publish which chips back a given model call — customers choose a model, not a chip. AWS does describe a common progression between the two: prototype with Bedrock using prompting and Knowledge Bases for retrieval-augmented generation, move to SageMaker AI’s serverless fine-tuning or reinforcement learning when prompting alone isn’t enough, and optionally deploy the resulting custom model back into Bedrock for serverless inference, or onto SageMaker endpoints or HyperPod for more granular control. Nova models customized on SageMaker, for example, can be imported directly into Bedrock.

Trade-offs

Bedrock trades control for speed: teams move faster but can’t choose the underlying instance type, chip, or container.
SageMaker trades simplicity for control: more powerful, but it requires a team that understands training jobs, instance types, and orchestration.
AWS’s “common path” framing — start on Bedrock, graduate to SageMaker — is AWS’s own recommendation, not a requirement; some teams skip straight to SageMaker, and others never leave Bedrock.
Neither service is useful without the AWS AI chip layer underneath, but only SageMaker lets customers choose which chip family runs their workload.

Bottom Line

Trainium and Inferentia are the hardware story, but Bedrock and SageMaker are the services most AWS customers actually touch. Bedrock is the fast path to a working generative-AI application with minimal ML overhead; SageMaker is the full-control platform for teams that need to own the training process, the hardware choice, and the deployment infrastructure. AWS’s own documentation treats them as complementary stages of the same pipeline rather than competitors — and that’s the most useful way to think about when to reach for each.

FAQ

Do I need to pick Bedrock or SageMaker, or can I use both?
AWS explicitly designs them to work together. A common pattern is prototyping on Bedrock, moving to SageMaker AI for fine-tuning or reinforcement learning once prompting isn’t enough, and then deploying the resulting model either back into Bedrock or onto SageMaker endpoints/HyperPod.

Does Bedrock run on Trainium chips?
AWS doesn’t publish per-model chip assignments for Bedrock, since it’s a serverless service. Trainium and Inferentia are explicitly named as supported hardware for SageMaker AI training and inference jobs, where customers choose the instance type directly.

What foundation models are available on Bedrock?
AWS lists more than 100 models from providers including Amazon (Nova), Anthropic (Claude), DeepSeek, Moonshot AI, MiniMax, OpenAI, and xAI, accessible through a shared set of APIs.

Is SageMaker only for training models from scratch?
No. SageMaker JumpStart provides a large catalog of pre-built and foundation models that can be deployed or further customized rather than trained from zero, alongside the option for fully custom training.

Sources

Artificial Intelligence, Cybersecurity

Prompt Injection and Agentic Security: A Checklist for Teams Deploying Autonomous AI Coding Agents in 2026

Posted on October 31, 2026 by Filip Keser

Autonomous AI coding agents — tools like Claude Code, Cursor’s agent mode, and Copilot workspace agents — can now read a codebase, write and run code, call external tools, and open pull requests with minimal human intervention. That autonomy is exactly what makes them productive, and exactly what makes them a new class of security risk. OWASP’s own guidance tracks this: in its GenAI Security Project’s 2026 update, prompt injection held the number-one spot for a third straight year, and “excessive agency” — the risk of a model having too much functionality or too many permissions — jumped from eighth to third place as agentic tool use has spread. This piece explains the core risks and gives a practical checklist for running coding agents safely.

At a Glance: Top Risks and Mitigations

Risk	What It Means for a Coding Agent	Primary Mitigation
Prompt Injection (OWASP LLM01)	Malicious instructions hidden in a file, README, issue comment, or fetched webpage change the agent’s behavior	Treat all retrieved content as untrusted data, never as instructions; sandbox and scope tool access
Excessive Agency (OWASP LLM06)	The agent has broader permissions or tool access than the current task needs (e.g., it can both read and delete files)	Least-privilege permission scoping per task/session; approval gates for destructive actions
Sensitive Information Disclosure (OWASP LLM02)	Agent reads or echoes credentials, API keys, or secrets it encounters while browsing a repo or terminal output	Secrets management outside the agent’s reach (vaults, env injection at runtime), output filtering
Supply Chain (OWASP LLM03)	Agent installs or runs a malicious dependency, plugin, or MCP server it was tricked into trusting	Pin and review dependencies/tools; restrict which registries and MCP servers an agent may use
Improper Output Handling (OWASP LLM05)	Agent-generated code or shell commands execute without review and introduce injection or logic flaws	Human-in-the-loop review before merge/deploy; automated static analysis gates in CI

What Prompt Injection Actually Is

OWASP’s Top 10 for LLM Applications defines a prompt injection vulnerability as occurring when user or external input alters a model’s intended behavior in a way the developer did not anticipate — including input the model retrieves on its own, such as a web page, a file, or a tool’s output. It has been ranked the number-one LLM risk in OWASP’s list for three consecutive editions. As Steve Wilson, co-chair of the OWASP GenAI Security Project, has put it, large language models “cannot differentiate between data and instructions” the way traditional software can, which is why OWASP frames prompt injection as something to be continuously managed rather than a bug that can be definitively patched the way SQL injection can.

For a coding agent, this risk is concrete and not theoretical: a comment in a GitHub issue, a string inside a dependency’s README, or text embedded in a web page the agent fetches while researching a bug can all contain instructions crafted to hijack the agent — for example, telling it to exfiltrate a secret, modify a CI config, or install a malicious package, phrased as if it were part of the legitimate task.

Why Agentic Tool Use Raises the Stakes

OWASP’s LLM06 category, Excessive Agency, covers what happens when a model is given more functionality, more tool access, or more autonomous decision-making power than a task requires. In OWASP’s 2026 update, this category rose to third place, up from eighth two editions earlier — a shift OWASP’s own co-chair attributes directly to AI systems now being able to browse the web, call external tools, and reach into business systems on their own. A coding agent that only needs to read a repository but is also wired up with file-delete, network-access, or production-deployment tools turns a single successful prompt injection into a much larger incident. OWASP’s suggested mitigation is explicit: tightly scoped permissions combined with continuous behavioral monitoring, rather than assuming the model will simply “know” not to misuse a capability it has been handed.

OWASP has also launched a dedicated Agentic Security Initiative (ASI), publishing threat-modeling guidance specifically for agentic systems and mapping it to established frameworks such as MITRE ATLAS, CWE, and NIST — a signal that agentic risk is now treated as its own discipline rather than a subset of general LLM security.

The Checklist: Deploying Coding Agents Safely

Sandbox execution. Run the agent’s shell, code execution, and file access inside a container or VM that is isolated from production credentials, your broader network, and other developers’ environments — never on a developer’s primary machine with full access.
Scope permissions per task, not per project. Grant only the tools and filesystem/network access a specific task needs (e.g., read-only repo access for research tasks; write access only for the specific directory being edited), and treat any request for broader access as something to approve explicitly, not assume.
Treat all fetched content as untrusted data. Web pages, issue comments, dependency READMEs, and tool outputs the agent reads should never be able to directly trigger privileged actions — apply the same mistrust you’d apply to unsanitized user input in a web app.
Keep secrets out of the agent’s reach. Inject credentials at the point of use via a secrets manager or short-lived tokens rather than placing them in files, environment dumps, or chat history the agent can read, log, or echo back.
Require human-in-the-loop review for anything destructive or externally visible. Code merges, deployments, infrastructure changes, and any action that sends data outside the sandbox (network calls, package installs, PR creation to public repos) should require explicit human approval, not run on autopilot.
Pin and vet tools, plugins, and MCP servers. Only connect agents to tool integrations (including Model Context Protocol servers) that have been reviewed, and pin versions rather than letting an agent dynamically discover and install new ones mid-task.
Run static analysis and dependency scanning on agent-generated code. Don’t exempt AI-authored commits from the same SAST/SCA gates applied to human-authored code — agents can introduce the same vulnerability classes, and prompt injection can specifically aim to make them do so.
Log and monitor agent actions continuously. Keep an audit trail of every tool call, file change, and command the agent executes, so an injected or misbehaving session can be detected and rolled back quickly.
Set hard limits on resource and API consumption. OWASP’s Unbounded Consumption category (LLM10) applies to agents too — cap how many tool calls, tokens, or cloud resources a single agent session can use to limit the blast radius of a runaway or hijacked loop.
Review system prompts and configuration for leakage risk. Agent instructions and internal tool definitions can themselves be exposed (OWASP’s System Prompt Leakage, LLM07); avoid embedding secrets or overly sensitive business logic directly in system prompts.

Trade-Offs to Expect

Every mitigation above trades some agent autonomy for safety, and that trade-off is the point, not a flaw. Tight permission scoping and mandatory human review will slow an agent down and reduce the “fire and forget” appeal that makes these tools attractive in the first place. Sandboxing adds infrastructure overhead. Treating all external content as untrusted will occasionally cause an agent to ask for clarification on something genuinely benign. Teams that skip these controls to move faster are accepting the same prompt injection and excessive-agency risks that OWASP has ranked at the top of its list for three years running — the checklist above is about managing that risk deliberately rather than eliminating friction by accident.

Bottom Line

Prompt injection cannot be fully “patched” the way a traditional vulnerability can — OWASP itself frames it as a risk to be continuously managed. For teams running autonomous coding agents, that means defense-in-depth: sandboxed execution, least-privilege permission scoping, secrets kept outside the agent’s reach, mandatory human review for destructive or externally-visible actions, and the same static analysis and dependency scanning you’d apply to any other code, applied without exception to agent output.

FAQ

Is prompt injection the same as a jailbreak?

They’re related but distinct. A jailbreak typically targets the model’s own safety guardrails directly in the conversation; prompt injection more broadly covers any input — including content the model retrieves on its own from a file, webpage, or tool output — that changes its behavior in unintended ways. OWASP’s Prompt Injection category covers both.

Can sandboxing alone solve the problem?

No. Sandboxing limits the blast radius of a compromised agent session, but it doesn’t stop prompt injection from happening — an injected agent can still exfiltrate data, corrupt code, or waste resources within the sandbox. It needs to be combined with permission scoping, secrets isolation, and human review.

Why did “excessive agency” rise so much in OWASP’s ranking?

According to OWASP’s GenAI Security Project, it’s a direct consequence of AI systems increasingly being able to browse the web, call tools, and access business systems autonomously — capabilities that barely existed at the scale seen in earlier editions of the list.

Does this apply to tools like GitHub Copilot’s simpler autocomplete mode, not just full agents?

The risk is much lower for autocomplete-style suggestions that a developer reviews before accepting, because there’s no autonomous tool use or multi-step execution involved. The checklist in this article is specifically about agentic modes that can read, write, execute, and act without a human approving each step.

Where can I read OWASP’s full guidance?

OWASP publishes the Top 10 for LLM Applications and a separate Agentic AI Threats and Mitigations guide through its GenAI Security Project at genai.owasp.org, both linked in the Sources section below.

Sources

platform, software

Best Email Clients for Power Users in 2026: Superhuman vs Spark vs Outlook

Posted on October 31, 2026 by Filip Keser

Power users who live in their inbox tend to gravitate to one of three tools: Superhuman, famous for speed and keyboard-driven triage; Spark, an AI-forward client built to run everywhere; or Outlook, the default for anyone already paying for Microsoft 365. We checked current pricing on each vendor’s own site, including Superhuman’s official help-center pricing article, to see what you actually get for the money in 2026.

At a Glance

Tool	Starting Price	AI Features	Best For
Superhuman	$30/mo (Starter)	Superhuman AI triage; Business adds Auto Drafts, Ask AI	High-volume email power users on Mac/mobile
Spark	$0/mo (Free), $10/mo (Plus)	Spark+AI assistant, AI Meeting Notes, Autopilot (Pro)	AI-assisted email across every platform, including Windows
Outlook (via Microsoft 365)	$9.99/mo (Personal, includes Copilot)	Copilot chat and drafting built into the subscription	Microsoft 365 households and power users needing full platform coverage

Short Verdict

Superhuman is the best pick for dedicated email power users on Mac and mobile who want the fastest, most opinionated inbox-zero workflow and can justify its premium price. Outlook via Microsoft 365 is the practical default for anyone who needs a true Windows app and already pays for the Microsoft ecosystem. Spark is the best middle ground — solid AI features at a fraction of Superhuman’s cost, on every platform.

What They Are

Superhuman

Superhuman is a premium email client layered on top of Gmail or Outlook accounts, built around speed: instant load times, exhaustive keyboard shortcuts, and AI features for triage and drafting. It has native apps for Mac, iPhone, and Android, plus a Chrome extension for desktop browsers — but no dedicated native Windows app.

Spark

Spark Mail (by Readdle) is an AI-assisted email client designed to work consistently across Mac, Windows, iOS, and Android. Its Spark+AI features — summarization, AI Assistant, AI Meeting Notes, and (on Pro) Autopilot and Auto-Drafts — are available on Plus, Pro, and Premium tiers.

Outlook

Outlook is Microsoft’s email client, bundled into Microsoft 365 subscriptions alongside Word, Excel, and now Copilot AI. It runs natively on Windows, Mac, iOS, Android, and the web, making it the most platform-complete option of the three, and a free, more limited version is also available through Outlook.com.

Pricing Breakdown

Tool / Plan	Price	Notes
Superhuman — Starter	$30/mo or $300/yr ($25/mo equivalent)	Most Superhuman AI features
Superhuman — Business	$40/mo or $396/yr ($33/mo equivalent)	Adds Auto Drafts, Ask AI, Custom Auto Labels, CRM integrations
Superhuman — Enterprise	Custom (contact sales)	Adds SSO, advanced security, dedicated support
Spark — Free	$0/mo	Limited AI preview, 5 lifetime AI Meeting Notes
Spark — Plus	$10/mo or $8.25/mo annual ($99/yr)	40 AI Meeting Notes/month, AI Assistant
Spark — Pro	$20/mo or $16.58/mo annual ($199/yr)	Unlimited AI Meeting Notes, Autopilot, Auto-Drafts
Outlook — Free (Outlook.com)	$0/mo	Basic Outlook, limited/no Copilot
Outlook — Microsoft 365 Personal	$9.99/mo or $99.99/yr	Full desktop Outlook + Copilot included, 1 person
Outlook — Microsoft 365 Family	$12.99/mo or $129.99/yr	Same as Personal; Copilot usage limited to the subscription owner

Pros and Cons

Superhuman

Fastest, most refined keyboard-driven workflow of the three
AI triage and drafting feel purpose-built for high email volume
Works on top of existing Gmail/Outlook accounts

By far the most expensive option ($30-40/month per person)
No native Windows app — desktop access is via a Chrome extension
No free plan to try before buying

Spark

True cross-platform support, including Windows
Usable free tier, with paid AI starting at $10/month
AI Meeting Notes and Autopilot are distinctive, practical features

Less polished/fast than Superhuman for pure speed-focused workflows
Full AI feature set requires Pro ($20/month) for unlimited use
Team pricing is handled on a separate page, less transparent upfront

Outlook

Broadest platform support: Windows, Mac, iOS, Android, web
Copilot AI included in the Microsoft 365 price, not a separate add-on
Best value if you already pay for Microsoft 365 for Word/Excel/Teams

Not purpose-built for inbox-zero speed the way Superhuman is
Copilot usage limits apply even on paid plans
Family plan AI features are restricted to the subscription owner only

Who It’s a Good Fit For / Who Should Look Elsewhere

Superhuman fits Mac- and mobile-based professionals processing huge email volumes who treat inbox speed as a competitive advantage. Look elsewhere if you need a native Windows app or are price-sensitive.

Spark fits individuals and small teams who want solid AI email features on whatever device they use, including Windows, without Superhuman’s price tag. Look elsewhere if raw speed and the most refined power-user shortcuts are your top priority.

Outlook fits anyone already in the Microsoft 365 ecosystem, or who needs guaranteed parity across every device including Windows. Look elsewhere if you want an email client built from scratch around speed rather than a general productivity suite.

Bottom Line

Pick Superhuman if you’ll genuinely use its speed and can accept Mac/mobile-first limitations and a premium price. Pick Outlook if you’re already paying for Microsoft 365 and need full platform coverage. Pick Spark if you want meaningful AI assistance across every device at a fraction of Superhuman’s cost.

FAQ

Does Superhuman have a Windows app?

Not a native one. Superhuman’s official download page lists apps for Mac, iPhone/iPad, and Android, plus a Chrome extension for desktop browsers — but no standalone Windows application.

Is Copilot included with Outlook, or is it a separate cost?

Copilot is bundled into Microsoft 365 Personal ($9.99/month) and Family ($12.99/month) plans at no extra charge, per Microsoft’s official pricing page, though usage limits apply.

Does Spark have a free plan?

Yes. Spark’s Free plan includes a limited preview of its AI features and 5 lifetime AI Meeting Notes; full AI access starts on the Plus plan at $10/month.

Is Superhuman worth the price over Gmail or Outlook alone?

It depends on email volume. For people processing dozens to hundreds of emails a day, the speed and AI triage can pay for themselves in time saved; casual users are unlikely to need a $30-40/month add-on layer.

Can I use Superhuman or Spark with my existing Gmail or Outlook account?

Yes, both are designed to connect to existing Gmail, Google Workspace, Outlook, or Microsoft 365 mailboxes rather than replacing your email provider.

Sources

Superhuman official pricing help article — Starter/Business/Enterprise pricing and AI feature differences
Superhuman download help article — confirms Mac, iOS, Android, and Chrome extension availability (no native Windows app)
Spark Mail pricing page — Free/Plus/Pro/Enterprise pricing and AI features
Microsoft 365 plan comparison page — Personal/Family pricing confirming Copilot is included with Outlook

Artificial Intelligence

AI-Powered Test Generation: How Developer Agents Are Automating QA in 2026

Posted on October 30, 2026 by Filip Keser

Writing unit tests has historically eaten a disproportionate share of developer time relative to how interesting the work is, which makes it a natural target for AI automation. The landscape here has shifted quickly, though, and the branded products worth knowing in 2026 aren’t always the ones that made headlines a year or two ago.

At a Glance

Tool	Status	What it claims
Qodo Cover (open source)	Unmaintained since June 2025	Aimed to increase code coverage; no benchmark numbers published in its own README
Qodo Gen	Active (current product)	Test generation folded into Qodo’s broader IDE extension and agentic platform
Diffblue Cover / Testing Agent	Active, vendor-marketed	Vendor claims 81% autonomous code coverage, “2.5x more than AI coding tools alone”

Short Verdict

The open-source tool many articles still reference, Qodo Cover, is no longer maintained; current test-generation capability from that vendor now lives inside Qodo Gen. Diffblue is the more actively marketed standalone player, with bold coverage-percentage claims that come directly from the vendor’s own press materials rather than an independently replicated benchmark — worth treating as a starting point for your own evaluation, not a guarantee.

Qodo Cover Is Deprecated

Qodo Cover, the open-source CLI tool previously known as “cover-agent,” carries an explicit notice on its GitHub repository, dated June 15, 2025, stating the repository is no longer maintained. Its original README described the goal as helping “increase code coverage” but never published specific before/after coverage benchmark numbers. Current test-generation functionality from Qodo now lives in the “Qodo Gen” IDE extension, part of the same broader platform that sells Qodo Merge for code review (covered in our AI code review comparison). Anyone evaluating Qodo for test generation today should look at Qodo Gen’s current capabilities rather than referencing the archived Cover project as if it were still active.

Diffblue

Diffblue markets a “Testing Agent” product built around autonomous unit test generation for Java codebases. In its own press materials, the company states its Testing Agent “delivers 81% code coverage autonomously, 2.5x more than AI coding tools alone,” and separately claims a “20x productivity advantage” compared with AI coding assistants used for test writing. These are vendor-published marketing figures from Diffblue’s own press release, and we found no independent, third-party benchmark replicating them during this research. That doesn’t make them false, but it does mean they should be read as a claim to verify against your own codebase, not an externally audited result.

Why This Matters for Teams Evaluating These Tools

Automated test generation tools are judged almost entirely on coverage improvement and the quality of the tests they produce (do they actually catch regressions, or just pad a coverage metric), and vendors in this space have strong incentive to publish favorable numbers. The most reliable way to evaluate any of these tools is still a trial run against your own codebase, comparing coverage and mutation-testing results before and after, rather than taking a vendor’s published percentage as representative of your specific code.

Pros and Cons

Qodo Gen pros: part of a broader, actively maintained agentic platform with IDE integration. Cons: test-generation-specific pricing isn’t broken out separately from Qodo’s general credit-based plans.
Diffblue pros: focused specifically on autonomous Java unit test generation, actively marketed and developed. Cons: headline coverage and productivity figures are vendor-published, not independently verified; no public pricing page was found during this research.

Who It’s a Good Fit For

Teams already using Qodo for code review should evaluate Qodo Gen’s test-generation features as a natural extension rather than looking for the now-unmaintained Qodo Cover. Java-heavy teams specifically interested in autonomous unit test generation as a standalone capability are the target audience for Diffblue, though they should request a trial and measure results against their own codebase before trusting the vendor’s published figures.

Bottom Line

AI test generation is a real and fast-moving category, but branding has shifted quickly (Qodo Cover to Qodo Gen) and the biggest numbers you’ll see quoted are typically vendor marketing claims rather than independently audited benchmarks. Evaluate any tool in this category against your own codebase’s coverage and mutation-testing results before trusting a headline percentage.

FAQ

Is Qodo Cover still usable?
The code may still run, but its GitHub repository has been explicitly marked unmaintained since June 2025, so it will not receive updates or fixes going forward.

Are Diffblue’s coverage claims independently verified?
Not as far as we could find. The 81% coverage and 2.5x/20x productivity figures come from Diffblue’s own press release, with no independent third-party benchmark replication located during this research.

Does AI-generated test coverage guarantee good tests?
No. Coverage percentage measures how much code is executed by tests, not whether those tests would actually catch a real regression — mutation testing or manual review is still the better way to judge test quality.

Sources

Artificial Intelligence, Engineering

Cursor vs GitHub Copilot vs JetBrains AI Assistant: Best AI Coding Assistant in 2026

Posted on October 29, 2026 by Filip Keser

AI pair programming has split into two camps: standalone AI-native editors like Cursor, and AI layered onto the editor you already use, like GitHub Copilot or JetBrains AI Assistant. We already published a full standalone review of GitHub Copilot’s plans; this piece instead compares all three head-to-head so you can decide which fits your workflow, your IDE, and your budget in 2026.

At a Glance

Tool	Starting paid price	Free tier	Best for
Cursor	Pro, $20/month	Yes — Hobby plan, limited agent/chat usage	Developers who want an AI-first editor built around agentic, multi-file workflows
GitHub Copilot	Pro, $10/month	Yes — 2,000 inline suggestions/month, limited chat & agent use	Teams already standardized on GitHub who want AI woven into existing IDEs and GitHub.com
JetBrains AI Assistant	AI Pro, $20/month (JetBrains’ help docs also show a $10 price point for this tier — see note below)	Yes — AI Free, a small monthly credit allowance	Developers already living inside JetBrains IDEs (IntelliJ, PyCharm, WebStorm, Rider, etc.)

Cursor

Cursor (by Anysphere) is a standalone code editor forked from VS Code and rebuilt around AI from the ground up, rather than an extension bolted onto an existing IDE. Its core features are a codebase-aware Chat, inline Cmd+K edits, Tab-based multi-line autocomplete, and an Agent mode that can plan and execute multi-file changes, run commands, and iterate against test results with far less hand-holding than a basic autocomplete tool. Cursor also offers Cloud/background agents that work asynchronously and a Bugbot feature for automated pull-request review. It supports multiple underlying models (Anthropic, OpenAI, and Google model families among them) that you can switch between per task.

On pricing: Cursor’s published plan structure is Hobby (free, limited usage), Pro ($20/month), Pro+ ($60/month), and Ultra ($200/month) for individuals, with Teams plans starting around $40/user/month and custom Enterprise pricing. We’ll be straightforward about sourcing here: Cursor’s own pricing page did not render reliably through our research tooling during this session, so these figures are cross-checked against Cursor’s Wikipedia entry (which cites Cursor’s own site for the $20 Pro price) and independent, recently updated pricing trackers rather than a single live fetch. AI tool pricing changes often — confirm current numbers at cursor.com before buying.

GitHub Copilot

GitHub Copilot integrates into most major IDEs (VS Code, JetBrains IDEs, Visual Studio, Xcode, and more) plus a CLI, GitHub.com, and mobile. Per GitHub’s official plans page, the current lineup is Free, Pro ($10/month), Pro+ ($39/month), and Max ($100/month), each priced around a pool of “GitHub AI Credits” that cover chat and agent usage beyond unlimited inline suggestions (Free is capped at 2,000 inline suggestions/month). Business and Enterprise tiers add SAML SSO, usage metrics, IP indemnity, and org-wide user management, but GitHub’s plans page doesn’t publish their price or credit allotment — it routes that to a sales conversation. All paid tiers share the same model list and now support delegating work to third-party coding agents (Anthropic’s Claude and OpenAI’s Codex, in preview) from Pro+ and Max.

For a deeper breakdown of exactly which tier to pick as an individual developer, see our GitHub Copilot Review: Plans, AI Credits, and Which Tier a Developer Actually Needs in 2026.

JetBrains AI Assistant

JetBrains AI Assistant runs inside JetBrains’ own IDEs (IntelliJ IDEA, PyCharm, WebStorm, Rider, and the rest of the family) and is priced on a credit system rather than flat feature tiers. Per JetBrains’ official AI Assistant licensing documentation, the tiers are AI Trial (free, time-limited), AI Free (3 credits per 30 days, unavailable in Android Studio and the Community editions), AI Pro, AI Ultimate, and AI Enterprise (organizations only). One AI credit equals $1 USD, and roughly: 10 AI Chat code-generation requests, 40 editor code-generation requests, 25 code explanations, or 280 documentation requests per credit — though “expensive” models and agentic use burn through credits faster.

A transparency note: JetBrains’ own licensing page currently shows two different price/credit pairings for the same tiers — one set lists AI Pro at $10 for 10 credits and AI Ultimate at $30 for 35 credits, while another set on the same page lists AI Pro at $20 for 20 credits and AI Ultimate at $60 for 70 credits — without clarifying which is current. We’re flagging that discrepancy explicitly rather than picking one number and presenting it as settled; check JetBrains’ store page directly for the figure that applies to your account before purchasing.

How the Coding Experience Differs

All three tools can generate a working function from a comment, but the depth of “agentic” behavior differs. A simple prompt like “write a function that calculates a discounted price and rejects invalid input” produces similar completions across all three — the differentiator shows up on multi-file, multi-step tasks, where Cursor’s Agent and GitHub Copilot’s agent mode will edit several files and run tests autonomously, while JetBrains AI Assistant leans more on in-editor chat and targeted code generation inside the file you’re already in.

// Typical completion all three tools can produce from a single comment prompt
function getDiscountedPrice(price, discountPercent) {
  if (price <= 0 || discountPercent < 0 || discountPercent > 100) {
    throw new Error("Invalid input");
  }
  return price - (price * discountPercent) / 100;
}

Whichever assistant you use, treat its output as a draft, not a finished patch — our AI-Generated Code Security in 2026 guide covers the review checklist every team should run against AI-generated code before it merges.

Pricing Comparison

Tier level	Cursor	GitHub Copilot	JetBrains AI Assistant
Free	Hobby — limited agent/chat	Free — 2,000 inline suggestions/month	AI Free — 3 credits/30 days
Entry paid	Pro, ~$20/month	Pro, $10/month	AI Pro, ~$10–$20/month (see note above)
Mid paid	Pro+, ~$60/month	Pro+, $39/month	AI Ultimate, ~$30–$60/month (see note above)
Top individual	Ultra, ~$200/month	Max, $100/month	Not published beyond Ultimate
Team/Enterprise	Teams from ~$40/user/month; Enterprise custom	Business/Enterprise — priced via sales	AI Enterprise — organizations only, via sales

Pros and Cons

Cursor pros: deepest agentic, multi-file workflow; fast Tab completion; flexible model choice.
Cursor cons: another editor to adopt instead of your current one; usage-based costs beyond the included pool can add up.
GitHub Copilot pros: works inside the IDE you already use; tightest GitHub.com/PR integration; cheapest entry paid tier of the three.
GitHub Copilot cons: Business/Enterprise pricing isn’t public; credit-based usage requires some mental math.
JetBrains AI Assistant pros: native to JetBrains IDEs; bundled free with some JetBrains subscriptions (per its licensing page); granular credit-based billing.
JetBrains AI Assistant cons: locked to the JetBrains IDE family; JetBrains’ own pricing documentation currently contains conflicting price/credit figures.

Who Should Pick Which

Pick Cursor if you’re willing to switch editors for the most autonomous, agentic coding experience available today. Pick GitHub Copilot if your team is already on GitHub and you want AI assistance inside your current IDE without changing tools, at the lowest individual entry price of the three. Pick JetBrains AI Assistant if your team already lives in IntelliJ, PyCharm, WebStorm, Rider, or another JetBrains IDE and you’d rather not add a second AI subscription from a different vendor.

Bottom Line

There’s no single winner — the right choice follows your existing toolchain more than any one feature. GitHub Copilot is the safest, cheapest default if you’re GitHub-centric. JetBrains AI Assistant is the obvious choice if you’re already paying for JetBrains IDEs. Cursor is worth the editor switch if agentic, multi-file autonomy is the thing you actually need. Whichever you choose, verify current pricing directly with the vendor — all three companies update tiers and credit allowances more often than most review articles get updated.

FAQ

Can I use GitHub Copilot inside a JetBrains IDE?
Yes — GitHub’s plans page confirms IDE/editor support across major editors including JetBrains IDEs, so Copilot and JetBrains AI Assistant can technically coexist in the same editor.

Is Cursor based on VS Code?
Yes, Cursor is built as a fork of Visual Studio Code, which is why most VS Code extensions and keybindings carry over.

Does JetBrains AI Assistant work in the free Community editions?
Per JetBrains’ licensing documentation, AI Free is not available in Android Studio or in PyCharm/IntelliJ IDEA Community editions or trial licenses — you need a paid or All Products Pack-eligible JetBrains product.

Which tool is cheapest to start with?
GitHub Copilot Pro has the lowest published entry price of the three at $10/month, versus roughly $20/month for Cursor Pro and JetBrains AI Pro (subject to the pricing discrepancy noted above).

Do any of these tools have a free tier?
Yes — all three do: Cursor’s Hobby plan, GitHub Copilot’s Free plan (2,000 inline suggestions/month), and JetBrains’ AI Free tier (3 credits/30 days).

Sources

Artificial Intelligence, Engineering

What Are AI Coding Agents? Autonomous Developer Agents Explained in 2026

Posted on October 29, 2026 by Filip Keser

“AI coding agent” has become one of the most overused phrases in developer tooling, applied to everything from inline autocomplete to systems that write, test, and ship code with almost no human in the loop. Those are genuinely different things. This explainer draws only on vendors’ own documentation and announcements to describe what today’s most-discussed coding agents actually claim to do, where those claims are vendor-reported versus independently verified, and how agents differ structurally from the assistants most developers already use.

At a Glance

Category	Autonomy Level	Typical Use	Examples
Autocomplete	None — predicts the next tokens as you type	Inline suggestions inside an editor	Classic Copilot-style inline completion
Coding Assistant (chat)	Per-request — acts only when asked, one exchange at a time	Answer questions, explain code, generate a snippet to review	Copilot Chat, ChatGPT used interactively for code
Autonomous Coding Agent	Multi-step — plans a task, uses tools in a loop, works with limited supervision	Research a repo, write and test code across files, open a pull request	Devin, GitHub Copilot coding agent, Claude Code / Claude Agent SDK applications, OpenAI Codex cloud agent

What Makes an “Agent” Different From an Assistant

The field hasn’t settled on one precise definition, and vendors use the word loosely, but the pattern that recurs across official descriptions is a loop: the system gathers context on its own, decides what action to take, uses a tool (a shell, an editor, a browser, a test runner) to take that action, observes the result, and repeats until it decides the task is done — rather than producing one reply and stopping. Anthropic’s own framing for its Agent SDK captures this directly: “An agent is an application that completes a task by planning its own steps and calling tools that read files, run commands, or edit code.” A plain autocomplete model has no loop at all; it predicts tokens. A chat-based assistant has a loop of exactly one turn, bounded by what you ask in that message. An agent’s loop can run for minutes, and in some vendors’ products, run many steps unattended inside a sandboxed environment before a human looks at the result. That last part — acting inside a real environment with real tools, across multiple steps, with the human reviewing an outcome rather than approving each line — is the structural thing that separates an “agent” from an “assistant” in vendor usage, even though the industry still argues about where exactly the line falls.

Devin (Cognition)

Cognition introduced Devin in March 2024 as, in the company’s own words, “the world’s first fully autonomous AI software engineer.” Per Cognition’s announcement, Devin plans and executes complex engineering tasks inside a sandboxed environment that includes a shell, a code editor, and a browser; the company says it can learn an unfamiliar tool from documentation, recall context across steps, and fix its own mistakes, while reporting progress and taking feedback from a human along the way. Cognition’s demonstrated examples included building and deploying a small web app, fixing a bug in an open-source codebase, and resolving real GitHub issues.

On the benchmark claim: Cognition’s launch post reported that Devin resolved 13.86% of a 25%-random-subset of SWE-bench issues end-to-end and unassisted, against a previous best of 1.96% unassisted (4.80% for models given the exact files to edit). This is important to flag clearly: this is Cognition’s own self-reported number from its own 2024 announcement, measured on a subset it selected, and we did not find an independently reproduced, third-party verification of that specific figure. Treat it as a vendor claim, not an audited benchmark result, and note that SWE-bench methodology and leaderboard figures across the industry have been debated since. Cognition said a fuller technical report would follow; our research for this article did not surface that report.

GitHub Copilot Coding Agent

GitHub’s own documentation describes Copilot’s cloud-based agentic capability this way: “Copilot can research a repository, plan changes, and implement them in the background.” It edits files and runs tests and linters inside a cloud sandbox or an Actions-based runner, then opens a pull request once you’ve reviewed its proposed changes or once your prompt explicitly asks for one. A related feature, Agent Merge, watches an open pull request and can automatically address failing Actions workflows or merge conflicts. GitHub is explicit about the limits: an Actions-based session can only touch the single repository it was assigned to and is capped at 59 minutes; the agent works on one branch and opens one pull request per task; it requires write access to operate, and session logs are meant to support your review, not replace it. GitHub also states plainly that the agent “can produce incorrect or insecure code,” so output must be reviewed and tested before use. As of October 28, 2026, GitHub’s cloud agent experience requires a paid Copilot plan, subject to organization policy; our site’s own GitHub Copilot Review covers plan pricing and tiers in detail.

Claude Code and the Claude Agent SDK (Anthropic)

Anthropic’s documentation positions Claude Code as a terminal-based coding agent, and the Claude Agent SDK as a library that lets developers “build production AI agents with Claude Code as a library,” exposing the same agent loop, built-in tools (read, write, edit files, run commands, search the web), permissions system, and session management that power Claude Code itself, programmable in Python or TypeScript. Anthropic’s docs list specific supported capabilities rather than marketing superlatives: hooks that run custom code at points in the agent’s lifecycle, subagents that can be spawned for focused subtasks, Model Context Protocol (MCP) connections to external tools and data, and configurable permissions that control which tool calls run automatically versus which require approval. This is a notably narrower, more mechanism-focused description than some competitors’ launch posts — Anthropic’s framing centers on the loop-plus-tools architecture rather than end-to-end autonomy claims.

OpenAI Codex

OpenAI’s current documentation describes Codex as “OpenAI’s coding agent for software development,” included in ChatGPT Plus, Pro, Business, Edu, and Enterprise plans, capable of writing code from a description, explaining unfamiliar codebases, reviewing code for bugs and edge cases, debugging failures, and automating workflows like refactors, test generation, and migrations. OpenAI’s original introduction of the cloud agent (May 2025) described it in more autonomous terms: a “cloud-based software engineering agent that can work on many tasks in parallel,” where each task runs in an isolated sandbox preloaded with the user’s repository, with internet access disabled by default during execution (a June 2025 update allowed enabling it). The agent reads and edits files, runs test harnesses, linters, and type checkers, iterates on failing tests, and on completion commits its changes so a human can review them, request revisions, or open a GitHub pull request. OpenAI states plainly that users must manually review and validate all agent-generated code before integrating or running it, and that users cannot course-correct the agent mid-task — only after it finishes a run.

Comparing the Four

Agent	Vendor	Runs In	Opens PRs	Human Review Point
Devin	Cognition	Sandboxed environment (shell, editor, browser)	Yes, per Cognition’s description	During task, via real-time progress and feedback
Copilot coding agent	GitHub (Microsoft)	Cloud sandbox or GitHub Actions runner	Yes, after review or on request	Before and after PR creation; logs for review
Claude Code / Agent SDK	Anthropic	Local terminal, CI, or custom app via SDK	Depends on how the integrator builds it	Configurable via permissions system
Codex cloud agent	OpenAI	Isolated cloud sandbox preloaded with the repo	Yes, after task completion	After the agent commits; manual review required before use

Vendor Productivity Claims vs. Independent Evidence

Every vendor above has, at some point, made a productivity or capability claim in its own marketing — faster resolution of issues, higher benchmark scores, fewer human hours per task. Treat any specific percentage or benchmark score from a vendor’s own blog post or press release as a vendor claim unless it has been independently reproduced by a third party using a published, auditable methodology. Benchmark suites like SWE-bench have known methodology sensitivities (which subset is used, whether a model is given the exact files to change, whether runs are cherry-picked), and different vendors have reported results on different subsets and conditions, which makes cross-vendor comparison unreliable without reading each methodology section carefully. We have not independently verified any vendor’s specific productivity multiplier in this piece, and none is repeated here as established fact.

The Real Risks

Letting a tool plan, edit, and commit code across a real codebase with limited supervision raises security and review questions that go well beyond what this explainer can cover responsibly. Every vendor above explicitly tells users to review and test agent output before relying on it, which is itself a signal about current reliability. For a detailed look at how often AI-generated code introduces vulnerabilities, how those risks map to the OWASP Top 10 for LLM Applications, and a practical review checklist for teams adopting these tools, see our companion piece, AI-Generated Code Security in 2026.

The Bottom Line

An autonomous coding agent isn’t a smarter autocomplete — it’s a system built around a plan-act-observe loop that uses real tools inside a real (usually sandboxed) environment, with the human reviewing outcomes rather than approving every keystroke. Devin, GitHub’s Copilot coding agent, Claude Code and the Claude Agent SDK, and OpenAI’s Codex cloud agent all fit that structural pattern, according to their own vendors’ documentation, even though they differ in where they run, how much a human can intervene mid-task, and how much marketing language surrounds their launch. The specific productivity numbers are the part to be skeptical of; the architectural shift toward tool-using, multi-step agents is the part that’s well documented and, at this point, not really in dispute.

FAQ

Is GitHub Copilot’s autocomplete the same thing as its coding agent?
No. Copilot’s inline autocomplete predicts code as you type with no planning loop; Copilot’s coding agent is a separate, cloud-based feature that researches a repo, plans changes, implements them, and can open a pull request.

Can these agents be trusted to merge code without a human?
Every vendor covered here explicitly states that output should be reviewed and tested before use, and most products require an explicit human action (merging a PR, approving a session) before code reaches production.

Is the Devin SWE-bench number (13.86%) still accurate today?
That figure comes from Cognition’s original March 2024 announcement on a specific 25% subset of SWE-bench, measured under specific conditions. We did not find an independently audited, current reproduction of it, so it should be read as a historical vendor claim, not a current, verified benchmark.

What’s the difference between Claude Code and the Claude Agent SDK?
Claude Code is the terminal application for interactive, daily use. The Claude Agent SDK is a library that lets developers embed the same underlying agent loop and tools inside their own Python or TypeScript applications.

Do these agents need internet access to work?
It varies. OpenAI’s Codex cloud agent disables internet access by default during a task (with an option to enable it), largely for security reasons; other agents’ network access depends on how the sandbox or environment is configured by the vendor or integrator.

Sources

Artificial Intelligence, Cybersecurity

AI-Generated Code Security in 2026: The Risks, the Evidence, and a Review Checklist for Teams

Posted on October 28, 2026October 28, 2026 by Filip Keser

AI coding assistants have become part of everyday development, and for many teams the security question has moved from “is this allowed?” to “how do we review it?” This guide pulls together public evidence on how often AI-generated code is insecure, maps the risks to the OWASP Top 10 for LLM Applications, and ends with a practical review checklist grounded in NIST’s secure development guidance.

At a Glance

Question	Short answer
How often is AI-written code insecure?	In Veracode’s 2025 test of 100+ models on 80 tasks, 45% of samples introduced an OWASP Top 10 vulnerability
Worst weaknesses in that test	Cross-site scripting (failed 86% of the time) and log injection (failed 88%)
Riskiest language in that test	Java, with a failure rate above 70%
Do newer or bigger models fix it?	Not according to Veracode: security did not improve with newer or larger models
Most relevant OWASP LLM risks	LLM05 Improper Output Handling, LLM06 Excessive Agency, LLM03 Supply Chain, LLM01 Prompt Injection
Process framework to anchor on	NIST SSDF (SP 800-218) plus its AI profile, SP 800-218A

Short Verdict

Treat AI-generated code exactly like code from a fast, confident junior developer who has never seen your threat model: useful, often correct, and frequently insecure in predictable ways. The evidence says model upgrades will not solve this on their own, so the fix is process. Keep a human reviewer accountable for every merge, run static analysis and dependency checks on every pull request, and limit what coding agents are allowed to do without approval.

What the Evidence Says

One of the most widely reported recent datasets is Veracode’s 2025 GenAI Code Security Report, released July 30, 2025. Veracode gave more than 100 large language models 80 curated code-completion tasks, each tied to a known weakness in MITRE’s CWE list, and checked whether the output was secure. In 45% of cases the model introduced a vulnerability from the OWASP Top 10; put another way, when a secure and an insecure approach were both available, the models chose the insecure one 45% of the time. Java fared worst, failing more than 70% of the time, while Python, C#, and JavaScript ranged from 38% to 45%. Two weakness classes stood out: models failed to defend against cross-site scripting (CWE-80) in 86% of relevant cases and against log injection (CWE-117) in 88%. Veracode also reported that newer models wrote more syntactically correct code without becoming more secure, and that larger models did not perform significantly better than smaller ones.

Two caveats keep this in proportion. These are vendor-run benchmark tasks, not a measurement of production codebases, and Veracode sells application security testing. Even so, the specific failures it reports, such as unescaped output and unsanitized log input, are exactly the kinds of flaws a review process can be designed to catch.

Mapping the Risks to the OWASP Top 10 for LLM Applications

OWASP’s 2025 list was written for applications built on language models rather than for coding assistants specifically, but several entries translate directly to AI-assisted development. The mapping below is our interpretation of how each risk shows up in a coding workflow.

OWASP risk (2025)	How it shows up in AI-assisted coding
LLM05 Improper Output Handling	Generated code is merged or executed without validation, carrying injection flaws straight into the codebase
LLM06 Excessive Agency	Coding agents with shell, file-write, or push permissions can make changes no one reviewed
LLM03 Supply Chain	Suggested packages and dependencies may be outdated, malicious, or not exist at all
LLM01 Prompt Injection	Untrusted text in issues, comments, or repository files can steer an agent toward harmful actions
LLM02 Sensitive Information Disclosure	Secrets or proprietary code pasted into prompts, or credentials hard-coded in suggestions
LLM09 Misinformation	Plausible but wrong API usage or security advice accepted without verification

The Process Anchor: NIST SSDF and SP 800-218A

NIST’s Secure Software Development Framework (SP 800-218) is the most widely referenced baseline for secure development practices. In July 2024 NIST published SP 800-218A, “Secure Software Development Practices for Generative AI and Dual-Use Foundation Models: An SSDF Community Profile,” which adds AI-specific practices and is meant to be used alongside the SSDF, not instead of it. Its stated audience is producers of AI models, producers of AI systems that use those models, and acquirers of those systems. For a team that only uses coding assistants, the practical takeaway is simpler: AI-written code goes through the same SSDF controls as any other code, with no exemptions for where it came from.

The Review Checklist

A named human owns every merge. The person who accepts AI-generated code is accountable for it exactly as if they had typed it.
Static analysis on every pull request. Run SAST with rules for the weaknesses AI code gets wrong most often, especially output encoding (XSS) and log injection.
Verify every new dependency. Confirm a suggested package exists, is the one you meant, is maintained, and passes your software composition analysis before it lands in a lockfile.
Scan for secrets. Block commits that contain keys or tokens, and keep secrets out of prompts.
Limit agent permissions. Give coding agents the least privilege they need, require approval before they push, merge, or run destructive commands, and keep logs of what they did.
Treat repository text as untrusted input to agents. Issue bodies, comments, and files from outside contributors can contain instructions; do not let an agent act on them unreviewed.
Require tests for generated logic. Ask for tests alongside code, and review the tests as critically as the code.
Track provenance. Label or note AI-assisted changes so you can find them quickly if a pattern of flaws turns up later.

Pros and Cons of Leaning on AI for Code

Pros: faster first drafts, quick boilerplate and tests, and agents that can take on routine fixes, which frees reviewers to focus on design and risk.
Cons: predictable security gaps that benchmark data says are not shrinking with newer models, new supply-chain and prompt-injection exposure through agents, and a risk that reviewers rubber-stamp code that looks clean.

Bottom Line

AI code generation is a productivity tool, not a security control. The best available evidence suggests close to half of AI-written samples carry a well-known weakness, and that waiting for better models is not a plan. Put AI-generated code through the same SSDF-style gates as everything else, add dependency verification and agent permission limits on top, and keep a human accountable for every merge. For a look at one of the most widely used assistants, see our GitHub Copilot review.

Frequently Asked Questions

Is AI-generated code less secure than human code? The benchmark data here measures AI output against secure-coding tasks, not against human developers, so it shows AI code is often insecure but does not directly compare it with people.
Which vulnerabilities do AI assistants introduce most? In Veracode’s 2025 test, cross-site scripting and log injection had the highest failure rates, at 86% and 88%.
Will a newer model fix this? Veracode found security did not improve with newer or larger models, so plan on review and scanning regardless of model.
What framework should we follow? NIST’s SSDF (SP 800-218), with the SP 800-218A profile for organizations that build or acquire AI systems.

Sources

Engineering, software

GitHub Copilot Review: Plans, AI Credits, and Which Tier a Developer Actually Needs in 2026

Posted on October 28, 2026 by Filip Keser

Get GitHub Copilot: Visit the official GitHub Copilot plans page →

At a Glance

Spec	Value
Free plan	Yes — 2,000 inline suggestions/month, limited chat and agent use
Starting paid price	Pro, $10/month
Individual tiers	Free, Pro ($10), Pro+ ($39), Max ($100) per month
Business / Enterprise	Not priced on the plans page — contact sales
Usage unit	GitHub AI Credits (1 credit = $0.01)
Best for	Developers already on GitHub who want AI completions, chat, and an agent that opens pull requests

Short Verdict

GitHub Copilot’s free tier is a genuine trial of the product, with 2,000 inline suggestions a month and limited chat. For anyone coding most days, Pro at $10 a month is the sensible starting point: it removes the suggestion cap and adds code review and the cloud agent that turns assigned issues into pull requests. Pro+ and Max mostly buy a bigger monthly pool of AI credits plus the ability to hand tasks to third-party coding agents, so they only make sense if you regularly run out of credits on Pro. The big change to understand in 2026 is that usage is now measured in dollar-denominated AI credits rather than a simple request count.

What GitHub Copilot Is

GitHub Copilot is GitHub’s AI coding assistant. It suggests code inline as you type, answers questions in a chat panel, runs an agent mode that can make multi-file changes, works from the command line through the Copilot CLI, and on paid plans can act as a cloud agent: you assign it an issue on GitHub and it works in the background and opens a pull request for you to review.

Pricing Breakdown

Plan	Price/month	Base credits	Flex allotment	Total monthly credit value	Inline suggestions
Free	$0	Limited chat and agent usage			2,000/month
Pro	$10	$10	$5	$15	Unlimited
Pro+	$39	$39	$31	$70	Unlimited
Max	$100	$100	$100	$200	Unlimited
Business / Enterprise	Contact sales; not priced on the plans page

GitHub now meters chat, agent, and other advanced features in GitHub AI Credits, with one credit worth $0.01. Each paid plan comes with base credits equal to its price plus a flex allotment on top, so Pro effectively includes $15 of monthly usage, Pro+ $70, and Max $200. The plans page we checked did not list annual pricing for any tier.

Features by Tier

The Free plan already includes the Copilot CLI, agent mode, MCP server support, and custom instructions, but not code review, the cloud agent, or app modernization. Pro adds Copilot code review on pull requests, the cloud agent, app modernization for Java and .NET projects, and support for repository instruction files. Pro+ and Max add delegation to third-party coding agents, such as Anthropic’s Claude and OpenAI Codex, which GitHub labels as a preview; beyond that, the two differ mainly in credit volume. Enterprise-grade security, IP indemnity, SAML SSO, usage metrics, and user management are not part of any individual plan and require Business or Enterprise. One caution: the plans page lists the same set of AI models across every tier but its FAQ says Free users get entry-level models, so check which models you can actually select before relying on a specific one.

Pros

The free tier is usable for evaluation and light coding without a credit card. Pro is inexpensive at $10 a month and includes the features that change day-to-day work: unlimited completions, PR code review, and a cloud agent that works directly inside GitHub issues and pull requests. Copilot sits inside the platform where many teams already host code, so there is no separate tool to connect. The credit system makes heavy usage possible on higher tiers without hard request caps.

Cons

Dollar-denominated credits are harder to predict than a flat request count, because how fast you spend them depends on which features and models you use. Business and Enterprise pricing is not published on the plans page, which makes team budgeting harder without a sales conversation. Third-party agent delegation is still a preview and is only on the two most expensive individual plans. The model-availability wording on the plans page is inconsistent, as noted above.

Who It’s a Good Fit For

Individual developers and freelancers who host their code on GitHub and want completions, chat, and an agent that can pick up issues and open pull requests. Pro covers most of them. Pro+ or Max fit developers who lean heavily on agents and regularly exhaust Pro’s $15 of monthly credit value.

Who Should Look Elsewhere

Teams that need SSO, usage metrics, or IP indemnity need Business or Enterprise and should get a quote before committing. Developers whose code lives outside GitHub lose the cloud agent and PR review integration, which are much of the paid plans’ value, so an editor-based AI assistant may fit better.

Bottom Line

Start on Free to see whether inline suggestions fit how you code, then move to Pro at $10 a month if you code regularly; it is the best value tier and includes the cloud agent and code review. Only step up to Pro+ or Max once Pro’s credit pool is clearly the bottleneck. Teams should treat Business and Enterprise as a sales conversation, since the plans page does not publish their prices.

Frequently Asked Questions

Is GitHub Copilot free? There is a free plan with 2,000 inline suggestions a month and limited chat and agent usage.
How much is Copilot Pro? $10 a month, which includes $15 of monthly AI credit value ($10 base plus a $5 flex allotment).
What is a GitHub AI Credit? The unit GitHub uses to meter advanced features; one credit equals $0.01.
How much do Business and Enterprise cost? The plans page does not list prices for them; GitHub directs teams to contact sales.

Sources

GitHub — Copilot plans and pricing

software, technology

Grammarly Review: Features, Pricing, and Whether Pro Is Worth It Over the Free Plan in 2026

Posted on October 26, 2026October 27, 2026 by Filip Keser

Grammarly has shifted from a grammar-checking browser extension to an AI writing platform, and its pricing now reflects that: the free plan includes a monthly AI-prompt allowance, not just spell-check. Pro multiplies that allowance twentyfold and adds the rewriting and plagiarism-detection tools most people associate with “real” Grammarly, but its $12-a-month headline price only applies if you pay for the full year upfront.

Get Grammarly: Visit the official Grammarly plans page →

At a Glance

Plan	Price	AI Prompts/Month	Best For
Free	$0/mo	100 per user	Basic mistake-checking and tone awareness
Pro	$12/mo billed annually ($144/yr); $20/mo quarterly; $30/mo monthly*	2,000 per member	Full rewrites, plagiarism checks, style guides, up to 149 members
Enterprise	Contact sales	Unlimited per member	SSO, SCIM, custom roles, audit logs, large organizations

*Grammarly’s own pricing page lists Pro at a flat $12 without specifying the billing cycle; the monthly/quarterly/annual breakdown above comes from a third-party pricing analysis and reflects Grammarly’s long-standing billing structure rather than a figure confirmed directly on the current official pricing page.

Short Verdict

Grammarly Free is still a genuinely useful spell- and grammar-checker with basic tone detection and a real, if modest, monthly AI allowance. Pro’s value case rests almost entirely on two things: full-sentence rewrites that go beyond flagging errors, and plagiarism detection, which Free doesn’t offer at all. If you write occasionally and don’t need either, Free remains a reasonable stopping point. If you’re drafting professionally every day, the jump to Pro’s 2,000 monthly AI prompts and rewrite tools pays for itself quickly — just pay annually, since the monthly plan costs 2.5 times as much per month.

What It Is

Grammarly is a writing assistant available as a browser extension, desktop app, mobile keyboard, and plugins for Microsoft Word and Google Docs. It checks grammar, spelling, and punctuation in real time, flags tone, and — on paid tiers — rewrites full sentences and paragraphs rather than just pointing out individual errors. It works across most text fields on the web, not only inside its own app.

Free vs. Pro: What Actually Changes

Tone: Free shows you your writing’s detected tone. Pro and Enterprise let you actively adjust it to a target tone.
Rewriting: Free sticks to flagging individual mistakes. Pro adds full-sentence rewrites, fluency suggestions for non-native English writers, inclusive-language checks, citation consistency checks, and AI-generated text detection.
Plagiarism detection: Not available on Free at all. Included on both Pro and Enterprise.
AI prompts: Free gets 100 per month; Pro gets 2,000 per member per month; Enterprise is unlimited per member.
Style guides and brand tones: Free has none. Pro allows one of each; Enterprise is unlimited — relevant mainly to teams maintaining consistent brand voice across writers.
Admin and security controls: Pro adds account roles/permissions and basic team analytics. Enterprise layers on SAML SSO, SCIM, custom roles, data loss prevention, an Audit Logs API, and session timeout controls.

Pro is listed as available to both individuals and “eligible teams” up to 149 members, which blurs what used to be a separate Business tier — Grammarly’s current pricing page shows only Free, Pro, and Enterprise, with no standalone Business plan listed.

Pros

Free plan includes a real monthly AI-prompt allowance, not just basic spell-check.
Works across most of the web through its browser extension, not locked to one writing app.
Pro’s annual price works out to $12/month — among the cheaper premium AI writing tools when paid yearly.
Enterprise’s unlimited AI prompts and SSO/SCIM support make it a realistic fit for large, security-conscious organizations.

Cons

Plagiarism detection, one of Grammarly’s signature features, is completely absent from the free plan.
Monthly billing on Pro costs $30/month versus $12/month paid annually — a 2.5x markup for flexibility.
No separate, clearly priced Business tier anymore; teams are funneled into either Pro or a sales conversation for Enterprise.
100 AI prompts a month on Free is easy to exhaust if you lean on tone adjustment or rewrite suggestions regularly.

Who It’s a Good Fit For

Students, casual bloggers, and anyone writing occasional emails will likely find Free sufficient for catching mechanical errors. Professional writers, marketers, and anyone submitting work where plagiarism checks or full-sentence rewrites matter should budget for Pro, paid annually to avoid the monthly-billing markup.

Who Should Look Elsewhere

Writers who mainly want a general-purpose AI drafting and editing assistant, rather than a grammar layer on top of writing they’ve already done, may get more value from a general AI writing tool like ChatGPT Plus (covered in this site’s AI writing assistant roundup) — Grammarly is built to refine existing text, not generate long-form drafts from a prompt.

Bottom Line

Grammarly’s free plan is more capable than it used to be thanks to its built-in AI allowance, but plagiarism detection and full-sentence rewriting still require Pro. At $12/month paid annually it’s a reasonable upgrade for regular writers — just avoid the $30/month billing option unless you genuinely need the flexibility.

How Grammarly Compares to ProWritingAid

The single biggest difference between the two is plagiarism detection: Grammarly includes it on Pro ($12/month billed annually) and Enterprise, while ProWritingAid doesn’t bundle plagiarism checking into any plan at all — it’s sold separately as pay-per-use Story Credits, even on its top Premium Pro tier. ProWritingAid’s entry paid tier, Premium, is cheaper than Grammarly Pro at $10/month billed yearly ($120/year) versus Grammarly’s $12/month ($144/year), and it removes Grammarly Free’s 100-AI-prompt ceiling with unlimited line-editing runs and rewrites (ProWritingAid calls these “Rephrases”). ProWritingAid’s Premium Pro tier, at $12/month billed yearly, matches Grammarly Pro’s price almost exactly, but spends that parity on community features — live workshops, critique sessions, cowriting sprints — rather than Grammarly’s plagiarism and team-admin tools. ProWritingAid also offers a one-time lifetime purchase ($399 for Premium, $699 for Premium Pro) that Grammarly doesn’t offer in any form; Grammarly is subscription-only. Free-tier limits differ too: Grammarly Free allows 100 AI prompts a month with no document-length cap, while ProWritingAid Free caps each editing report at 500 words.

Spec	Grammarly	ProWritingAid
Plagiarism detection	Included on Pro and Enterprise	Not included on any plan — sold separately
Entry paid price	$12/mo billed annually ($144/yr)	$10/mo billed yearly ($120/yr, Premium)
Free-tier limit	100 AI prompts/month, no length cap	500 words per editing report
One-time purchase option	None — subscription only	Lifetime: $399 (Premium) or $699 (Premium Pro)
Best for	Teams needing plagiarism checks and admin controls	Long-form writers wanting a one-time purchase and community features

Frequently Asked Questions

Is Grammarly free forever? Yes — the free plan never expires, including its 100 monthly AI prompts, but it never adds plagiarism detection or full-sentence rewrites no matter how long you use it.
Does Grammarly work with Microsoft Word and Google Docs? Yes — Grammarly ships as plugins for both, alongside its browser extension, desktop app, and mobile keyboard, on every plan including Free.
Is Grammarly worth it if I only need basic spelling and grammar checks? Probably not — Free already covers mechanical error-checking and tone detection, so there’s no need to pay unless you specifically want plagiarism detection or full-sentence rewrites.
Is Grammarly or ProWritingAid cheaper for plagiarism checking? Grammarly, by a clear margin — it’s bundled into the $12/month Pro plan, while ProWritingAid doesn’t include plagiarism checking in any subscription tier and charges for it separately.

Sources

platform, technology

Best Cloud GPU Platforms for AI Training in 2026: Lambda vs RunPod vs CoreWeave vs AWS

Posted on October 24, 2026October 28, 2026 by Filip Keser

Gartner now projects global data center power demand will rise 27% in 2026 alone, to 132 gigawatts (its separate forecast for electricity consumption is growth of about 26%), with AI-optimized servers — the GPU racks that train and run today’s models — the single biggest driver of that growth. Almost none of that capacity is being bought outright by the companies training AI models; it’s being rented by the hour from cloud GPU providers. Here’s how the four most-used options actually price an NVIDIA H100, the GPU most AI workloads still train on.

At a Glance

Provider	H100 On-Demand ($/GPU-hr)	B200 On-Demand ($/GPU-hr)	Pricing Model
Lambda	$2.49 (1x PCIe) – $3.49 (8x SXM)	$6.69 – $6.99	Per-GPU, on-demand or 3-year reserved
RunPod	$2.89 (PCIe) – $3.99 (SXM)	$7.99	Per-GPU, per-second billing (Pods)
CoreWeave	$4.25 (PCIe) – $4.76 (HGX/SXM)	Not published (contact sales)	À la carte: GPU, vCPU, and RAM priced separately
AWS (EC2 P5)	~$6.88 effective (8x H100 bundled)	Not generally available on P5	Full-instance on-demand, or reserved/savings plans

Best for: startups and independent researchers who want to rent raw GPU capacity by the hour without building or leasing a physical data center.

Short Verdict

On pure H100 price, Lambda and RunPod undercut CoreWeave and AWS by a wide margin — Lambda’s 1x PCIe on-demand rate is roughly a third of AWS’s effective per-GPU cost on a P5 instance. CoreWeave sits in the middle on list price but is built for large, often multi-year reserved clusters rather than single-GPU rentals, which is a different buying motion than the other three. AWS is the most expensive per GPU-hour, but that price bundles enterprise networking, compliance certifications, and integration with the rest of AWS that the smaller specialists don’t offer out of the box.

What This Market Actually Is

Cloud GPU rental (sometimes called GPU-as-a-service) lets a company train or run AI models on someone else’s physical hardware, billed by the GPU-hour instead of bought outright. It exists because a single NVIDIA H100 costs tens of thousands of dollars, a full 8-GPU server far more, and the data center space, power, and cooling to run one at scale is its own multi-year infrastructure project — exactly the kind of buildout Gartner’s 2026 forecast is measuring. Renting lets a team scale GPU access up or down with their actual training workload instead of carrying that capital cost themselves.

How the Four Providers Actually Price It

Lambda prices per GPU with no minimum commitment: a single H100 PCIe runs $2.49/hour on-demand, and an 8-GPU H100 SXM server works out to $3.49 per GPU-hour ($27.92/hour total). Lambda also sells 3-year reserved H100 capacity at $1.89 per GPU-hour for commitments of 64 to 32,000 GPUs — a steep discount, but only accessible at a scale most individual developers never reach. Its B200 pricing runs $6.69–$6.99 per GPU-hour depending on configuration, and it does not publish an on-demand H200 rate, listing that model as reserved-only with pricing by quote.

RunPod is priced per-GPU with per-second billing through its “Pods” product: H100 PCIe runs $2.89/hour and H100 SXM $3.99/hour, with A100 SXM and PCIe both at $1.79/hour. Its B200 rate is $7.99/hour, the highest of the four providers we could confirm a published number for. RunPod’s per-second billing (rather than per-hour minimums) makes it well suited to short, bursty jobs where you don’t want to pay for a full hour of idle GPU time.

CoreWeave prices à la carte: the GPU, vCPUs, and RAM are each billed separately rather than bundled into one instance price, so its $4.25/hour (H100 PCIe) and $4.76/hour (H100 HGX/SXM) GPU rates don’t include the compute and memory you’ll also be charged for. CoreWeave doesn’t publish a fixed B200 on-demand rate on its pricing page — it’s quote-only, which matches its positioning toward large AI labs negotiating dedicated cluster capacity rather than developers spinning up a single GPU.

AWS doesn’t sell individual H100s at all — its P5 family rents full 8-GPU instances. A p5.48xlarge (8x H100, 640GB total HBM3) runs $55.04/hour on-demand in US East, which works out to roughly $6.88 per GPU-hour when divided evenly across the 8 GPUs — though that figure bundles AWS’s networking, storage, and the rest of the instance, so it isn’t a clean apples-to-apples comparison with the GPU-only rates above. AWS also offers H200 GPUs on its P5e and P5en instance families, and reserved or savings-plan pricing can bring the effective rate down meaningfully below the on-demand figure for sustained usage.

Pros and Cons by Provider

Lambda pros: lowest on-demand H100 rates of the four; reserved pricing drops further at scale. Cons: reserved discounts only make sense at large GPU counts; H200 isn’t available on-demand.
RunPod pros: per-second billing avoids paying for idle time on short jobs; competitive A100 and H100 PCIe pricing. Cons: highest confirmed B200 rate of the four.
CoreWeave pros: built for large dedicated clusters, which suits serious AI-lab-scale training. Cons: à la carte pricing means the advertised GPU rate understates true cost; B200 pricing isn’t published at all.
AWS pros: deepest ecosystem integration, broadest compliance certifications, reserved/savings-plan options for sustained workloads. Cons: highest effective per-GPU cost of the four on a straight on-demand basis.

Who It’s a Good Fit For

Independent developers, researchers, and small AI startups training or fine-tuning models on a budget will generally find Lambda or RunPod’s on-demand per-GPU pricing cheaper and simpler than the alternatives. Teams already running production workloads on AWS, or that need AWS’s specific compliance certifications, will find the P5 family’s premium easier to justify once it’s weighed against everything else AWS already provides.

Who Should Look Elsewhere

Anyone needing a single GPU for a short job should think twice before CoreWeave, since its à la carte pricing and large-cluster orientation aren’t built for that use case. And if B200-class hardware is the actual requirement, confirm CoreWeave’s quote-only rate directly before assuming it’ll land anywhere near Lambda’s or RunPod’s published numbers.

Bottom Line

The AI boom’s data center buildout is mostly being financed by the hour, not the server rack, and that rental market has real price spread: Lambda and RunPod currently undercut CoreWeave and AWS by roughly 30–60% per H100 GPU-hour on-demand. Match the provider to the job size — small or bursty workloads favor Lambda’s or RunPod’s per-GPU pricing, while large, sustained training runs are where CoreWeave’s and AWS’s reserved and cluster-scale pricing start to close the gap.

Sources

Finance, software

ServiceNow (NOW) Stock: Business Overview, Latest Earnings, and Valuation in 2026

Posted on October 20, 2026October 27, 2026 by Filip Keser

ServiceNow carries the highest valuation multiple of any company in this series by a wide margin — a trailing P/E above 90 — which only makes sense once you look at its growth rate and how fast that premium multiple is expected to shrink as earnings catch up. Here’s the latest quarter, what’s driving the valuation, and what to watch when the next report lands.

This article is for informational purposes only and is not financial advice. Market data below is a snapshot as of October 19, 2026, sourced from ServiceNow’s own earnings release and public market data providers — prices and ratios will have moved by the time you read this. Always verify current figures and consult a licensed financial advisor before making investment decisions.

At a Glance (as of October 19, 2026)

Metric	Value
Ticker	NOW (NYSE)
Share price	~$145
Market cap	~$150.3 billion
P/E ratio (TTM / forward)	90.8 / 32.1
Dividend yield	None — ServiceNow does not pay a dividend
52-week range	$81.24 – $192.97
Analyst consensus	Strong Buy (49 analysts), average price target $152.23

Short Summary

ServiceNow’s trailing P/E of 90.8 looks extreme in isolation, but its forward P/E of 32.1 — less than half that — reflects a company growing subscription revenue at roughly 24% a year while rapidly expanding profitability. Importantly, this article’s figures are drawn from Q2 2026, the most recently reported quarter; ServiceNow is scheduled to report Q3 2026 results on October 28, 2026, which will update several of the numbers below.

What the Company Does

ServiceNow sells a cloud platform originally built for IT service management — tracking and automating internal IT requests and workflows — that has expanded into HR, customer service, security operations, and now AI-driven workflow automation across departments. It sells almost entirely on subscription, to large enterprises and government agencies, and is known for very high customer retention once a workflow is built on its platform.

Latest Earnings: Q2 2026 (Quarter Ended June 30, 2026)

Total revenue was $3.987 billion, up 24% year over year (22.5% in constant currency). Subscription revenue was $3.877 billion, up 24.5% (23% in constant currency). GAAP operating margin was a thin 4% ($162 million), while non-GAAP operating margin was 29.5% ($1.17 billion) — a large gap driven mainly by stock-based compensation. Remaining Performance Obligations (RPO) reached $29.0 billion, up 21%, and current RPO (the portion expected to convert to revenue within 12 months) was $13.20 billion, also up 21%. For Q3 2026, ServiceNow guided to subscription revenue of $3.975–$3.980 billion (up 20.5%) and current RPO growth of 19.5%. Full-year 2026 subscription revenue guidance stands at $15.76–$15.78 billion, up 22.5%.

Valuation Context

ServiceNow’s 90.8 trailing P/E is the highest multiple in this series, and its 11.34% trailing profit margin is the lowest — a combination that only looks reasonable because both figures are improving quickly. The 32.1 forward P/E implies the market expects earnings to roughly triple the trailing-twelve-month figure over the coming year, largely through operating leverage as GAAP operating margin guidance climbs toward 10% for full-year 2026 and non-GAAP margin toward 31.5%.

Growth Drivers

Subscription revenue growth above 24% is among the fastest of any large enterprise software company, let alone one already at a $150 billion market cap
Current RPO growth (21%) roughly tracking total revenue growth suggests the backlog isn’t decelerating ahead of recognized revenue
Non-GAAP operating margin guidance of 31.5% for the full year shows real operating leverage as the business scales
Platform expansion beyond IT service management into HR, customer service, and AI-driven workflow automation (its “AI Platform” push) broadens the total addressable market beyond ServiceNow’s original niche

Risks

A 90.8 trailing P/E and 32.1 forward P/E leave very little room for a growth disappointment — guidance already calls for deceleration from 24.5% to roughly 20.5% subscription growth in Q3
GAAP operating margin of just 4% (versus 29.5% non-GAAP) reflects heavy stock-based compensation, which is a real cost to existing shareholders even though it doesn’t hit cash flow the same way
Q3 2026 results, due October 28, 2026, will land after this article and could move several of the figures above meaningfully in either direction
At a $150 billion market cap, ServiceNow needs to keep finding large new workflow categories to sustain mid-20s percentage growth as its base gets larger

Bottom Line

ServiceNow’s headline P/E looks alarming until you account for how fast both revenue and margins are moving — the forward multiple tells a much more ordinary growth-software story than the trailing one does. The real test is whether Q3 2026 guidance (20.5% subscription growth, already a step down from Q2’s 24.5%) holds or slips further when the company reports on October 28. This is informational, not a recommendation to buy or sell; do your own research and talk to a financial advisor before acting on it.

Sources

Finance, software

Oracle (ORCL) Stock: Business Overview, Latest Earnings, and Valuation in 2026

Posted on October 20, 2026October 28, 2026 by Filip Keser

Oracle is the most dramatic chart in this series: the stock has fallen from a 52-week high of $304.28 to roughly $130, a decline of well over 50%, even as the company reports some of the fastest cloud growth rates of any company covered here. Understanding Oracle right now means understanding why the market and the company’s own growth numbers are telling such different stories.

This article is for informational purposes only and is not financial advice. Market data below is a snapshot as of October 19, 2026, sourced from Oracle’s own earnings release and public market data providers — prices and ratios will have moved by the time you read this. Always verify current figures and consult a licensed financial advisor before making investment decisions.

At a Glance (as of October 19, 2026)

Metric	Value
Ticker	ORCL (NYSE)
Share price	~$130
Market cap	~$392.9 billion
P/E ratio (TTM / forward)	20.3 / 15.2
Dividend yield	1.54% ($2.00/share annually)
52-week range	$114.50 – $304.28
Analyst consensus	Buy (43 analysts), average price target $237.36 — note this consensus predates the stock’s steep recent decline and may not yet reflect updated analyst views

Short Summary

Oracle’s cloud infrastructure business is growing faster than almost any large software company’s — OCI revenue was up 121% in its most recent reported quarter (Q1 fiscal 2027), and management’s guidance calls for total cloud revenue growth of 64% to 70% in constant currency in the next quarter. But the stock has lost more than half its value from its 52-week high, driven by investor concern over how Oracle is financing the enormous data center buildout behind that growth, including its exposure to AI infrastructure partner CoreWeave’s debt. This is a case where the fundamentals and the stock price are pulling in opposite directions, and both sides of that argument are backed by real numbers.

What the Company Does

Oracle’s business has two distinct halves. Its legacy database and applications business (Oracle Database, NetSuite, Fusion applications) is a mature, slow-growing but highly profitable license-and-support business. Its cloud business — Oracle Cloud Infrastructure (OCI) for raw compute/storage, plus SaaS applications — is the fast-growing half, and increasingly the half investors are pricing the stock around, because Oracle has positioned OCI as infrastructure for AI model training and inference, competing directly with AWS, Azure, and Google Cloud for that workload.

Latest Earnings: Q1 Fiscal 2027 (Quarter Ended August 2026)

Total revenue was $19.3 billion, up 30% year over year. Total cloud revenue (IaaS plus SaaS) was $11.6 billion, up 62%. OCI (cloud infrastructure, or IaaS) revenue specifically was $7.4 billion, up 121%, while cloud applications (SaaS) revenue was $4.2 billion, up 10%. Remaining Performance Obligations (RPO) — contracted future revenue not yet recognized — reached $664 billion, up $209 billion year over year. GAAP earnings per share were $1.56 (up 55%) and non-GAAP EPS was $1.92 (up 30%); GAAP operating income was $6.7 billion (up 57%). Oracle’s guidance in the release calls for Q2 fiscal 2027 total revenue growth of 30% to 34% and total cloud revenue growth of 64% to 70% in constant currency, and for fiscal 2027 total revenue of at least $90 billion.

Why the Stock Has Fallen Despite the Growth

Reporting since mid-2026 has focused less on Oracle’s growth rate and more on how it’s being funded. Oracle has committed to massive capital spending to build out data center capacity for its RPO backlog, financed partly through new debt issuance, and investors have grown concerned about the company’s balance sheet leverage and its financial exposure to AI infrastructure partners like CoreWeave, whose own debt load has drawn scrutiny. CNBC reported Oracle shares had their worst week since the 2001 dot-com bust in June 2026 on these concerns, and the stock broke through successive price support levels in October 2026 as the CoreWeave-linked debt worries resurfaced. In short: the market isn’t questioning whether Oracle’s cloud business is growing — it’s questioning whether the debt-funded buildout behind that growth is sustainable if AI infrastructure demand or financing conditions shift.

Growth Drivers

OCI revenue growth of 121% in Q1 fiscal 2027, and guidance for total cloud revenue growth of 64% to 70% in constant currency next quarter, are faster than Microsoft’s reported Azure growth of 43% in its latest quarter
$664 billion in RPO gives Oracle multi-year revenue visibility most software companies don’t have, assuming those contracts convert to recognized revenue as scheduled
The legacy database and applications business remains highly profitable and funds a chunk of the cloud buildout
Management’s published guidance — Q2 fiscal 2027 total revenue growth of 30% to 34% and fiscal 2027 total revenue of at least $90 billion — gives investors specific figures to measure execution against each quarter

Risks

The debt load behind the data center buildout, and Oracle’s financial links to AI infrastructure partners like CoreWeave, are the specific concerns that have driven the stock’s decline — this is a balance-sheet risk, not a demand risk, and it’s the one actually showing up in the share price
$664 billion in RPO is a backlog, not revenue — it depends on customers’ AI spending plans not changing and on Oracle actually building the capacity to deliver on those contracts
A 57%+ decline from the 52-week high means the stock carries significantly more volatility risk than the other companies in this series
The analyst consensus price target predates the steepest part of the decline, so it may not reflect how analysts are currently weighing the balance-sheet concerns

Bottom Line

Oracle is the clearest example in this series of a stock where the operating business and the market’s verdict on it have diverged sharply. The cloud growth numbers are genuinely strong by any software company’s standard. The decline is about how that growth is being financed, not whether it’s happening. That makes Oracle a meaningfully higher-risk, higher-uncertainty situation than the other companies covered here, in both directions. This is informational, not a recommendation to buy or sell; do your own research — including reading Oracle’s latest 10-Q and the most recent coverage of its financing arrangements — and talk to a financial advisor before acting on it.

Sources

Finance, software

Salesforce (CRM) Stock: Business Overview, Latest Earnings, and Valuation in 2026

Posted on October 20, 2026October 27, 2026 by Filip Keser

Salesforce’s pitch to investors has shifted noticeably in the past year: it’s no longer just a CRM subscription business, it’s trying to be the company selling AI “agents” that do sales, service, and marketing work autonomously. The latest quarter gives the clearest numbers yet on whether that pitch is translating into real revenue.

This article is for informational purposes only and is not financial advice. Market data below is a snapshot as of October 19, 2026, sourced from Salesforce’s own earnings release and public market data providers — prices and ratios will have moved by the time you read this. Always verify current figures and consult a licensed financial advisor before making investment decisions.

At a Glance (as of October 19, 2026)

Metric	Value
Ticker	CRM (NYSE)
Share price	~$242
Market cap	~$199.5 billion
P/E ratio (TTM / forward)	22.5 / 16.5
Dividend yield	0.73% ($1.76/share annually)
52-week range	$146.32 – $269.11
Analyst consensus	Buy (56 analysts), average price target $285.68

Short Summary

Salesforce’s core subscription business is still growing at a solid double-digit clip, and its newer AI and data products (Agentforce and Data 360) are growing far faster off a smaller base — their combined annual recurring revenue more than tripled year over year. The stock’s forward P/E of 16.5 is the cheapest of the big enterprise-software names in this series relative to its growth rate, which is part of why analysts remain broadly bullish despite the stock sitting well off its 52-week high.

What the Company Does

Salesforce sells cloud-based customer relationship management (CRM) software — Sales Cloud, Service Cloud, Marketing Cloud, and Slack — on a subscription basis to businesses of nearly every size. In the past two years it has layered on Data Cloud/Data 360 (a data platform for unifying customer data) and Agentforce (AI agents that can autonomously handle sales, service, and other workflows), and it acquired data-integration company Informatica in 2026, which now contributes directly to reported revenue.

Latest Earnings: Q2 Fiscal 2027 (Quarter Ended July 31, 2026)

Total revenue was $11.35 billion, up 11% year over year, including a $456 million contribution from the newly acquired Informatica. Subscription and support revenue was $10.82 billion, up 12% (11% in constant currency). GAAP operating margin was 20.5%; non-GAAP operating margin was 34.1%. The standout figure: combined Data 360 and Agentforce annual recurring revenue reached nearly $3.9 billion, up more than 210% year over year, with Agentforce ARR alone exceeding $1.5 billion, up more than 240%. Salesforce raised full-year FY2027 revenue guidance to $46.1–$46.4 billion, up 11–12% year over year.

Valuation Context

At 16.5 times forward earnings, Salesforce trades cheaper than Microsoft or ServiceNow despite posting faster-growing new product lines (Agentforce, Data 360) alongside its core CRM base. Its 21.99% profit margin is solid but trails Microsoft’s and Adobe’s, reflecting Salesforce’s heavier sales-and-marketing spend as a software company that sells primarily through a direct enterprise sales force.

Growth Drivers

Agentforce and Data 360 combined ARR more than tripled year over year, showing real customer adoption rather than just a product announcement
Core subscription and support revenue is still growing at 12%, a healthy rate for a company of Salesforce’s size
The Informatica acquisition adds a data-integration product line and immediate revenue contribution
Raised full-year guidance signals management confidence the growth trajectory holds through the rest of FY2027

Risks

Agentforce and Data 360 ARR, while growing fast, are still a small fraction of Salesforce’s roughly $40+ billion annual revenue run rate — the core CRM business still needs to hold up on its own
The stock trades roughly 10% below its 52-week high even after a strong quarter, suggesting the market hasn’t fully rewarded the AI narrative yet
Integrating Informatica carries the usual acquisition execution risk, on top of the reported revenue contribution
Enterprise software spending is sensitive to broader economic conditions, and Salesforce’s direct-sales model has historically shown more sensitivity to IT budget tightening than pure infrastructure plays

Bottom Line

Salesforce’s latest quarter is the clearest evidence yet that Agentforce and Data 360 are more than a slide in an investor presentation — their combined ARR tripling year over year is a real number, even if it’s still small relative to total revenue. Combined with a cheaper valuation than its large-cap enterprise-software peers, that’s the basis for the broadly bullish analyst consensus. Whether the newer products scale fast enough to matter at Salesforce’s size is the open question. This is informational, not a recommendation to buy or sell; do your own research and talk to a financial advisor before acting on it.

Sources

Finance, software

Adobe (ADBE) Stock: Business Overview, Latest Earnings, and Valuation in 2026

Posted on October 20, 2026October 27, 2026 by Filip Keser

Adobe sits in an unusual spot among large software companies: its most recent quarter was a genuine record, yet the stock trades near the cheapest valuation it’s had in years, closer to its 52-week low than its high. That gap between the business’s performance and the market’s price for it is the whole story of Adobe stock right now.

This article is for informational purposes only and is not financial advice. Market data below is a snapshot as of October 19, 2026, sourced from Adobe’s own earnings release and public market data providers — prices and ratios will have moved by the time you read this. Always verify current figures and consult a licensed financial advisor before making investment decisions.

At a Glance (as of October 19, 2026)

Metric	Value
Ticker	ADBE (Nasdaq)
Share price	~$247
Market cap	~$96.2 billion
P/E ratio (TTM / forward)	13.8 / 9.2
Dividend yield	None — Adobe does not pay a dividend
52-week range	$190.12 – $363.70
Analyst consensus	Hold (39 analysts), average price target $272.31

Short Summary

Adobe just reported its highest-ever quarterly revenue, with double-digit growth across its subscription base — and the stock is still down roughly a third from its 52-week high. The market’s “Hold” consensus reflects a real worry underneath the strong numbers: that generative AI tools could erode Adobe’s pricing power or let competitors replicate what Creative Cloud and the Document Cloud do, even while current results don’t show that happening yet.

What the Company Does

Adobe sells subscription software built around two customer groups, as it now reports them: Creative & Marketing Professionals (Creative Cloud apps like Photoshop, Premiere, and Illustrator, plus Adobe Experience Cloud marketing tools) and Business Professionals & Consumers (Document Cloud/Acrobat and consumer-facing tools). Nearly all of its revenue is recurring subscription revenue rather than one-time software sales.

Latest Earnings: Q3 Fiscal 2026 (Reported September 2026)

Total revenue was $6.76 billion, up 13% year over year (12% in constant currency) — a record quarter. Creative & Marketing Professionals subscription revenue was $4.65 billion, up 13%. Business Professionals & Consumers subscription revenue was $1.91 billion, up 16%. GAAP diluted EPS was $4.62 (versus $4.18 a year earlier); non-GAAP diluted EPS was $6.13 (versus $5.31). For Q4 FY2026, Adobe guided to $6.80–$6.85 billion in revenue, and raised full-year FY2026 revenue guidance to $26.576–$26.626 billion.

Valuation Context

Adobe’s forward P/E of 9.2 is unusually low for a company growing revenue at a double-digit clip with a 28.05% profit margin — a materially cheaper multiple than Microsoft, Salesforce, or ServiceNow carry in this series, despite comparable or better margins. That gap is almost entirely a sentiment discount tied to AI disruption fears rather than anything showing up in the actual numbers yet, which is exactly why the stock is worth watching rather than ignoring.

Growth Drivers

Record quarterly revenue with double-digit growth across both reporting segments, not just one
High profit margin (28.05%) and strong EPS growth (non-GAAP EPS up roughly 15% year over year)
Nearly all-subscription revenue model gives Adobe recurring, predictable cash flow
Management has continued raising full-year guidance through the year rather than cutting it

Risks

Generative AI image, video, and design tools are a direct competitive threat to Creative Cloud’s core use cases, even if that threat hasn’t shown up in revenue yet
The stock’s depressed valuation reflects a market that remains skeptical regardless of strong quarterly results, so good earnings alone haven’t been enough to re-rate the stock this year
No dividend means shareholder return depends entirely on share price appreciation and buybacks
A 39-analyst “Hold” consensus signals genuine disagreement about the stock’s direction, not a clear read in either direction

Bottom Line

Adobe’s business and its stock price are telling two different stories right now: the business just posted a record quarter with growth accelerating in both segments, while the stock trades at its cheapest multiple in years on AI disruption fears that haven’t yet appeared in the numbers. That disconnect is the entire investment debate — whether you read it as an opportunity or a warning depends on how much weight you put on current results versus a risk that hasn’t materialized yet. This is informational, not a recommendation to buy or sell; do your own research and talk to a financial advisor before acting on it.

Sources

Finance, software

Microsoft (MSFT) Stock: Business Overview, Latest Earnings, and Valuation in 2026

Posted on October 20, 2026October 28, 2026 by Filip Keser

Microsoft is the largest company in this series by a wide margin, and its stock story in 2026 is almost entirely a cloud-and-AI story: Azure grew 43% in the latest reported quarter, even as the company pours record amounts of capital into data centers. Here’s what the most recent earnings actually showed, how the stock is priced relative to that growth, and the risks worth weighing.

This article is for informational purposes only and is not financial advice. Market data below is a snapshot as of October 19, 2026, sourced from Microsoft’s own earnings release and public market data providers — prices and ratios will have moved by the time you read this. Always verify current figures and consult a licensed financial advisor before making investment decisions.

At a Glance (as of October 19, 2026)

Metric	Value
Ticker	MSFT (Nasdaq)
Share price	~$534
Market cap	~$3.96 trillion
P/E ratio (TTM / forward)	29.7 / 27.0
Dividend yield	0.73% ($3.92/share annually)
52-week range	$349.20 – $553.72
Analyst consensus	Strong Buy (56 analysts), average price target $599.24

Short Summary

Microsoft’s most recent quarter (Q4 fiscal 2026, ended June 30, 2026) showed strong cloud growth, led by Azure, which grew 43% year over year, with Microsoft Cloud revenue up 27% to $59.3 billion. The stock trades near the top of its 52-week range at roughly 27 times forward earnings — a premium multiple, but not an extreme one set against total revenue growth of 18%. The main debate among analysts isn’t whether the business is growing, it’s whether the enormous capital spending behind that growth will eventually compress margins.

What the Company Does

Microsoft reports results across three segments. Productivity and Business Processes covers Microsoft 365, LinkedIn, and Dynamics. Intelligent Cloud covers Azure, SQL Server, Windows Server, and other server products — the company’s fastest-growing segment and the one most levered to the AI buildout. More Personal Computing covers Windows, Xbox, Surface, and Bing/search advertising, and is the smallest and slowest-growing of the three.

Latest Earnings: Q4 Fiscal 2026 (Quarter Ended June 30, 2026)

Total revenue was $90.0 billion, up 18% year over year (17% in constant currency). Microsoft Cloud revenue — Azure, Microsoft 365 Commercial cloud, Dynamics 365, and LinkedIn combined — reached $59.3 billion, up 27%. Azure and other cloud services revenue grew 43% year over year. By segment: Productivity and Business Processes brought in $37.8 billion (up 14%), Intelligent Cloud brought in $39.3 billion (up 32%), and More Personal Computing brought in $12.9 billion (down 4%). GAAP operating income was $40.6 billion (up 18%), GAAP net income was $35.8 billion (up 31%), and GAAP diluted EPS was $4.81 (up 32%). For the full fiscal year 2026, revenue was $331.8 billion, up 18%. Microsoft is scheduled to publish its Q1 fiscal 2027 results (quarter ended September 30, 2026) after the market close on October 28, 2026, which will update these figures.

Valuation Context

At roughly 29.7 times trailing earnings and 27.0 times forward earnings, Microsoft trades at a premium to the broader market, but one that’s historically typical for the stock rather than unusually stretched. Profit margin stands at 40.31% on a trailing basis — among the highest of any company in this series — which gives Microsoft more room to absorb heavy AI infrastructure spending than a thinner-margin peer would have.

Growth Drivers

Azure and other cloud services revenue grew 43% year over year in Q4 fiscal 2026, as enterprises shift more infrastructure and AI workloads to the cloud
Copilot and other AI features are being layered into Microsoft 365, GitHub, Dynamics, and Windows, giving Microsoft multiple avenues to monetize AI beyond pure infrastructure
Productivity and Business Processes remains a durable, high-margin base business (up 14% to $37.8 billion in the quarter) even as Intelligent Cloud (up 32% to $39.3 billion) becomes the primary growth engine
LinkedIn and Dynamics continue to post steady growth inside the Productivity segment, diversifying revenue beyond Office and Windows

Risks

Capital expenditure on AI data centers is running at record levels across the entire hyperscaler industry, and any slowdown in AI demand would hit a business that’s spent heavily to build out capacity in advance of it
A premium valuation means the stock is more sensitive to any growth disappointment than a cheaper peer would be
More Personal Computing’s 4% revenue decline in the quarter shows the PC and consumer hardware business remains structurally slow
Microsoft, like other large tech platforms, continues to face ongoing antitrust and regulatory scrutiny in multiple jurisdictions

Bottom Line

Microsoft’s latest quarter gave bulls real evidence — Azure growth of 43% and Microsoft Cloud revenue up 27% to $59.3 billion — rather than just a promise about future AI monetization. The stock isn’t cheap, but its premium multiple sits alongside 18% revenue growth for fiscal 2026 and an operating margin that edged higher over the year. Whether that justifies the current price depends on your own view of how long hyperscaler AI capital spending can keep outrunning AI revenue — a question none of the data above answers on its own. This is informational, not a recommendation to buy or sell; do your own research and talk to a financial advisor before acting on it.

Sources

marketing, software, technology

Best AI Writing Assistant Tools in 2026: Jasper vs Copy.ai vs Grammarly vs ChatGPT Plus

Posted on October 17, 2026October 27, 2026 by Filip Keser

“AI writing assistant” covers four genuinely different products now: brand-voice marketing generators, chat-based copywriting workflows, an editing layer that sits on top of anything you type, and general-purpose chatbots pressed into writing duty. We compared Jasper, Copy.ai, Grammarly, and ChatGPT Plus on what they’re actually built for and what each one costs.

At a Glance

Tool	Price	Free Plan	Best For
Jasper	Pro: $69/seat/mo billed monthly or $59/seat/mo billed yearly; Business: custom pricing	No — 7-day free trial only	Marketing teams needing brand-voice-consistent content at scale
Copy.ai	Chat: $29/mo billed monthly or $24/mo billed yearly (5 seats); Growth: $1,000/mo+ (75 seats)	No — trial only	Teams wanting multi-model (OpenAI/Anthropic/Gemini) chat copywriting with workflow automation
Grammarly	Free: $0; Pro: $30/mo billed monthly or $12/mo billed yearly ($144/yr)	Yes — 100 AI prompts/month plus grammar & tone checks	Everyday writers who want an editing layer on top of anything they write
ChatGPT Plus	Plus: $20/month; Pro: usage-based tiers (no single published flat price)	Yes — capable free tier with usage limits	General-purpose writing, research, and brainstorming at the lowest cost per capability

A note on ChatGPT Pro: OpenAI’s current pricing page lists Pro as offering “a choice of 3 usage tiers” rather than one flat monthly price, and different usage tiers come with different costs. We’re not publishing a specific Pro dollar figure here because OpenAI’s own page doesn’t display one in a simple, single-number form — check chatgpt.com/pricing directly for current tier pricing if Pro is what you need.

Short Verdict

These four tools solve different problems well enough that “which is best” depends entirely on the job. Jasper and Copy.ai are both built for teams producing marketing content at volume with brand consistency and workflow automation — Jasper leans more toward a structured brand-voice/agent system, Copy.ai toward flexible multi-model chat and no-code workflows. Neither has a real free plan. Grammarly is the cheapest and most broadly useful for anyone who writes anything, because it layers onto existing writing rather than generating from scratch, and its free tier is genuinely usable. ChatGPT Plus is the best value if you need general-purpose AI writing help and don’t need marketing-specific brand controls or workflow automation — $20/month buys a capable all-purpose assistant that can draft, edit, and research.

Jasper: Best for Brand-Consistent Marketing Content

Jasper’s Pro plan runs $69/seat/month billed monthly, or $59/seat/month billed yearly with a 12-month commitment (both include a 7-day free trial). Pro covers one seat, the Canvas platform for on-brand content creation, agents for core marketing workflows, 2 Brand Voices, 5 Knowledge assets, and 3 Audiences. Business is custom-priced, requires a 12-month commitment and a sales conversation, and adds agents for more complex workflows (including GEO and translations), a no-code builder for custom AI agents, Jasper Grid for scaled content execution, unlimited Brand Voices/Knowledge/Audiences, API access, and enterprise admin controls. Some Business-tier features run on a separate credit system rather than being unlimited. There’s no permanent free plan — just the 7-day trial on Pro.

Copy.ai: Best for Multi-Model Chat Workflows

Copy.ai’s entry plan, Chat, costs $29/month billed monthly or $24/month billed annually ($288/year), covers 5 seats, and gives unlimited words and unlimited chat projects with access to OpenAI, Anthropic, and Gemini models in one interface. Above that, pricing jumps steeply into team-workflow territory: Growth is $1,000/month (75 seats, 20,000 workflow credits/month), Expansion is $2,000/month (150 seats), and Scale is $3,000/month (200 seats), with Enterprise above that at custom pricing. The gap between Chat and Growth is large enough that Copy.ai is really two different products: an affordable multi-model chat tool for small teams, and a workflow-automation platform priced for larger marketing operations. There’s no free plan, only a free trial.

Grammarly: Best Free Plan and Everyday Value

Grammarly’s Free plan costs $0 and includes 100 AI prompts per month plus its long-standing grammar, spelling, and tone-detection checks — a genuinely usable starting point, not a stripped teaser. Pro costs $30/month billed monthly, or $12/month billed annually ($144/year), and raises the AI prompt allowance to 2,000 per member per month while adding tone adjustment, full-sentence rewrites, inclusive-language suggestions, citation consistency, and both AI-generated-text and accidental-plagiarism detection. Enterprise is contact-sales pricing with unlimited AI prompts per member. Grammarly’s current lineup collapsed its old “Premium” and “Business” tiers into Pro, per its own FAQ. Of the four tools here, Grammarly is the only one built primarily to edit and improve writing you’ve already drafted, rather than to generate content from a prompt.

ChatGPT Plus: Best General-Purpose Value

ChatGPT’s Free tier costs $0 and includes unlimited text chats (subject to abuse guardrails) with limited access to uploads, image creation, voice, deep research, and memory. Plus costs $20/month and expands all of those limits, adds advanced reasoning models, projects, scheduled tasks, custom GPTs, and broader Codex and ChatGPT Work access across desktop, web, and mobile. Pro sits above Plus with a choice of usage tiers rather than one flat price, Pro-specific reasoning models, longer session limits, and an always-on agent feature OpenAI calls Dot. As a pure writing tool, ChatGPT lacks Jasper’s or Copy.ai’s brand-voice and workflow-automation features, but at $20/month for Plus, it’s the cheapest way to get a genuinely capable AI writing and research assistant with no marketing-specific overhead.

Pros and Cons by Tool

Jasper — Pro: structured brand-voice controls built for marketing teams. Con: no free plan, and per-seat pricing adds up for larger teams.
Copy.ai — Pro: access to multiple AI models in one subscription at a low entry price. Con: pricing jumps dramatically once you need more than 5 seats or real workflow automation.
Grammarly — Pro: the only genuinely useful free tier of the four, and the cheapest paid tier billed annually. Con: it edits and polishes rather than generating long-form content from scratch.
ChatGPT Plus — Pro: the best all-purpose capability per dollar, and a usable free tier to start. Con: no brand-voice memory, templates, or marketing-specific workflow tools built in.

Bottom Line

Pick based on the job, not the hype: Jasper or Copy.ai if you’re producing marketing content at volume and need brand consistency or workflow automation (Jasper for structured brand controls, Copy.ai for flexible multi-model chat at a lower entry price); Grammarly if you want a free or cheap editing layer on top of writing you’re already doing; ChatGPT Plus if you want one general-purpose assistant for drafting, research, and brainstorming at the lowest monthly cost.

Sources

platform, technology

Integrations, Connectors, and MCP: What They Are and Why MCP Matters

Posted on October 16, 2026 by Filip Keser

At a Glance

Term	What It Means
Integration / connector	A built or pre-built link between two apps so data or actions flow between them automatically
iPaaS	A platform (Zapier, Workato, Make) that ships many pre-built connectors instead of custom point-to-point code
MCP (Model Context Protocol)	An open standard, released by Anthropic on November 25, 2024, for connecting AI applications to external tools and data sources
MCP governance	Donated by Anthropic to the Agentic AI Foundation, a Linux Foundation directed fund, on December 9, 2025

Short Verdict

“Integrations” and “connectors” are the decades-old problem of getting software to talk to other software; MCP is a 2024 attempt to solve a newer, narrower version of that same problem specifically for AI assistants and agents. The two are related but not interchangeable — an iPaaS tool like Zapier connects apps to each other, while MCP standardizes how an AI model connects to tools and data in the first place. Both matter for the same underlying reason: bespoke, one-off integrations don’t scale, and a shared standard means something gets built once and reused everywhere.

Integrations and Connectors, in Plain Terms

An integration is simply a link that lets two pieces of software exchange data or trigger actions in each other — a new row in your CRM creating a task in your project-management tool, or a form submission landing in a spreadsheet. Historically, building these required custom, point-to-point code for every single app pair, which doesn’t scale once you have more than a handful of tools. That’s the gap an iPaaS (integration-platform-as-a-service) fills: as Zapier’s own explainer defines it, iPaaS is “a cloud-based software service solution that lets organizations connect different applications” across cloud, on-premises, and hybrid environments, typically through pre-built connectors and low/no-code tools rather than hand-coded integrations. Zapier itself is a familiar example — its current pricing runs from a Free plan (100 tasks/month, unlimited workflows) up through Professional at $19.99/month billed annually, Team at $69/month billed annually, and a custom Enterprise tier, per Zapier’s own pricing page. Workato, by contrast, markets itself as an “Enterprise iPaaS” aimed at larger organizations automating workflows like Salesforce-to-NetSuite quote-to-cash processes, serving both IT and what it calls “citizen integrator” business users, per its own documentation.

What MCP Actually Is

The Model Context Protocol was announced and open-sourced by Anthropic on November 25, 2024, created by Anthropic engineers David Soria Parra and Justin Spahr-Summers. Per Anthropic’s own announcement, even the most capable AI models are “cut off from data trapped in information silos and legacy systems,” and historically every new data source needed its own bespoke integration — which doesn’t scale any better for AI assistants than it ever did for regular software. MCP’s pitch is to replace that fragmentation with what Anthropic calls “one protocol” and a “universal, open standard” for connecting AI systems to data sources, tools, and workflows.

The current official definition, from the independently-governed modelcontextprotocol.io documentation site, puts it simply: MCP “is an open-source standard for connecting AI applications to external systems.” The docs use a specific, official analogy — not just press shorthand — stating directly: “Think of MCP like a USB-C port for AI applications. Just as USB-C provides a standardized way to connect electronic devices, MCP provides a standardized way to connect AI applications to external systems.”

How It’s Built: Hosts, Clients, and Servers

Per MCP’s official architecture specification, the protocol follows a client-host-server model built on JSON-RPC. The host is the application a person actually uses (Claude Desktop, for example), which creates and manages clients and enforces security policy and user consent. The client is created by the host, with a strict one-to-one relationship to a single server, handling protocol negotiation and keeping servers isolated from each other. The server exposes “resources, tools and prompts” — the protocol’s three core primitives — and can run locally or remotely. A key design principle stated directly in the spec: “Servers should not be able to read the whole conversation, nor ‘see into’ other servers” — the host keeps full conversation context, and servers only see what’s relevant to their own job. In practice, tools are actions the model can call, resources are contextual data the application can read, and prompts are reusable templated instructions — all negotiated when a session starts.

Why It Matters — and Who’s Adopted It

The official docs frame the benefit differently depending on audience: for developers, MCP “reduces development time and complexity” when building or integrating with an AI application; for AI applications themselves, it provides access to “an ecosystem of data sources, tools and apps”; for end users, it means more capable assistants that can access their data and take action on their behalf. The tagline the docs use for the ecosystem effect is “build once and integrate everywhere” — instead of every AI vendor building a custom Slack integration, a Google Drive integration, and a GitHub integration from scratch, one MCP server for each can work across any MCP-compatible AI application.

Adoption moved quickly after the November 2024 launch: Cursor added MCP server support in February 2025, Microsoft brought MCP into Copilot Studio and Cloudflare enabled customers to deploy remote MCP servers by around April 2025, and OpenAI added MCP support to its Agents SDK that same month, with modelcontextprotocol.io’s current documentation now listing ChatGPT among MCP-supporting AI assistants and linking to OpenAI’s own MCP developer docs. Visual Studio Code and Cursor are both listed as MCP-supporting development tools on the current official docs. One figure we’re deliberately not citing precisely: the number of community-built MCP servers now in existence. Estimates circulating across different third-party sources range anywhere from roughly 1,400 to over 11,000, depending on methodology and date — none of that is an Anthropic- or modelcontextprotocol.io-published figure, so treat any specific server count you see elsewhere as a rough, fast-moving estimate rather than a settled number.

The most significant recent change is governance, not adoption: on December 9, 2025, Anthropic donated MCP to the Agentic AI Foundation (AAIF), described as a directed fund under the Linux Foundation, with Anthropic, Block, and OpenAI as founding co-sponsors and Google, Microsoft, AWS, Cloudflare, and Bloomberg named as supporters. MCP’s existing maintainer structure and technical direction are stated to remain unchanged under this arrangement — the Linux Foundation’s role is custodial, not directive. This is independently corroborated by outside reporting beyond Anthropic’s own channels, which is part of why it’s credible as more than a one-source claim.

Bottom Line

Integrations and iPaaS tools solve how regular software talks to other software; MCP solves the newer, specific problem of how an AI assistant talks to your tools and data without a bespoke integration for every single one. Less than two years after its November 2024 launch, MCP has been adopted across a wide swath of the AI tooling landscape and transitioned to vendor-neutral, Linux Foundation-adjacent governance — a sign it’s being treated as infrastructure rather than a single vendor’s side project. If you’re building or buying AI tooling today, whether a connector supports MCP is a reasonable question to ask, in the same way “does this integrate with Zapier” became a reasonable question for SaaS tools a decade ago.

Sources

Anthropic — Introducing the Model Context Protocol (original Nov 25, 2024 announcement)
Model Context Protocol — official introduction (USB-C analogy, ecosystem benefits)
Model Context Protocol — official architecture specification
Zapier — What Is iPaaS?
Zapier — Pricing
Workato — What Is Workato
The Batch (DeepLearning.AI) — OpenAI adopts MCP
Microsoft — MCP in Copilot Studio

technology

How AI Is Reshaping Data Center Demand and Design

Posted on October 16, 2026 by Filip Keser

At a Glance

Metric	Figure
Global data center electricity use, 2024	~415 TWh (~1.5% of world electricity) — IEA
Projected global data center electricity use, 2030	~945 TWh, more than double 2024 — IEA
Typical AI-focused data center load	Roughly the electricity use of 100,000 households — IEA
Legacy enterprise rack power	~5–10 kW per rack
NVIDIA GB200 NVL72 rack power	Approximately 120 kW (vendor documentation ranges ~100–132 kW by configuration)
Practical air-cooling ceiling	Roughly 40–50 kW per rack
Combined Q3 2025 capex — Microsoft, Amazon, Alphabet, Meta	Over $114 billion for the single quarter

Short Verdict

AI isn’t just filling data centers with more servers — it’s forcing a redesign of what a data center is. Training and inference workloads concentrate far more electrical load into far less floor space than the web and cloud-computing era ever did, and that shift is rippling through every layer of the facility: how it’s powered, how it’s cooled, how dense its racks are, and increasingly, how much strain it puts on the local electrical grid. The numbers below are drawn from the IEA’s 2025 energy-and-AI analysis, hyperscaler earnings disclosures, and data-center industry research — and a few widely-quoted figures (exact next-generation rack power draw, specific 2026 capex totals) are flagged as approximate or unconfirmed rather than stated as fact.

Why AI Workloads Don’t Behave Like Ordinary Computing

A traditional enterprise or web-hosting server rack draws somewhere in the neighborhood of 5 to 10 kilowatts (kW) — low enough that a building’s existing electrical and cooling systems can usually absorb it without much fuss. An AI training or inference cluster is a different animal. A single NVIDIA GB200 NVL72 rack — 36 GB200 Superchips pairing 72 B200 GPUs with 36 Grace CPUs — draws approximately 120 kW, roughly 12 to 24 times a legacy rack’s draw packed into the same floor footprint. (Vendor documentation isn’t perfectly consistent here; depending on configuration, cited figures for this exact rack range from about 100 kW to 132 kW, so treat 120 kW as a representative midpoint rather than a fixed spec.) The successor GB300 NVL72 pushes that figure up to roughly 142 kW per rack, according to NVIDIA’s own reference architecture.

That density jump is the root cause of almost everything else in this article. Training large models means running thousands of GPUs continuously, at near-full utilization, for weeks or months at a stretch. Inference — actually serving a trained model’s responses to users — draws less per-query power but happens constantly, at scale, across a growing user base, so its aggregate electricity footprint is catching up with training’s. Either way, the facility has to supply, distribute, and remove far more power and heat per square foot than it was originally built for.

The Power Problem, in Real Numbers

The International Energy Agency’s Energy and AI report puts global data center electricity consumption at around 415 terawatt-hours (TWh) in 2024 — about 1.5% of total world electricity use. That demand has been growing roughly 12% a year since 2017, and the IEA names AI specifically as “the most important driver of this growth” going forward, projecting consumption more than doubling to around 945 TWh by 2030. The United States currently accounts for about 45% of global data center electricity use, China 25%, and Europe 15%. The IEA’s shorthand for scale: a typical AI-focused data center uses as much electricity as 100,000 households.

That demand has to come from somewhere, and increasingly it’s showing up as a line item on grid operators’ forecasts. PJM Interconnection — the grid operator covering a large swath of the mid-Atlantic and Midwest — projected in its 2025 forecast that peak electricity demand in its territory will climb from 160 GW to 210 GW by 2035, a 31% increase the forecast attributes “almost entirely” to data center buildout; large-load interconnection requests in PJM’s queue already total 66 GW through 2035. That’s pushed some hyperscalers toward unconventional power deals: Microsoft has contracted for output from the restarted Three Mile Island reactor (now renamed the Crane Clean Energy Center) under a 20-year agreement, and Google has a power-purchase arrangement tied to Kairos Power’s planned small modular reactors delivering power through the Tennessee Valley Authority. Exact capacity figures in some of these deals vary slightly across public reporting, but the direction is unambiguous: AI data centers are now significant enough electricity customers that hyperscalers are directly underwriting new power generation rather than simply buying off the existing grid.

Cooling: Why Air Is Running Out of Room

Conventional air cooling — chilled air pushed through a hot-aisle/cold-aisle layout, sometimes assisted by rear-door heat exchangers — works fine up to roughly 40 to 50 kW per rack, according to data-center engineering sources and the Uptime Institute’s own research. Past that point, the sheer volume of air (and fan power) needed to carry the heat away becomes impractical. A 120 kW GB200 rack is roughly two to three times past that ceiling, which is why liquid cooling has gone from a niche option to effectively mandatory for AI clusters at this scale.

Two liquid approaches dominate. Direct-to-chip (also called cold-plate) cooling runs a liquid coolant loop directly to plates mounted on the GPU and CPU packages, and comfortably handles the 100–150 kW per rack that current AI hardware generates — this is the approach built into NVIDIA’s GB200/GB300 reference designs. Immersion cooling, which submerges hardware entirely in a dielectric fluid, can handle similar or higher densities but has seen more limited deployment so far, mostly in specialized or experimental installations rather than as the default for new hyperscale builds. For context on just how much the industry baseline has shifted: the Uptime Institute’s surveys show the typical (not AI-specific) data center rack density was still under 8 kW as recently as 2024, rising to a reported 11 kW in 2026 — meaning even “normal” racks are climbing, while AI racks have leapt an order of magnitude past that baseline.

The Buildout: Capex and Gigawatt-Scale Campuses

The dollar figures behind this shift are large enough to show up directly in Big Tech earnings calls. In the third quarter of 2025 alone, the four largest hyperscalers reported combined capital expenditure — most of it data-center and AI-infrastructure related — of roughly $114 billion: Amazon around $36 billion in total corporate capex (AWS accounting for about $28 billion of that), Microsoft about $35 billion, Alphabet/Google about $24 billion, and Meta about $19 billion, with year-over-year growth rates ranging from roughly 44% to over 110% depending on the company. For the full 2025 fiscal year, Amazon guided to approximately $125 billion in cash capex, Alphabet raised its guidance to $91–93 billion, and Meta guided to $70–72 billion — all figures the companies disclosed on their own Q3 2025 earnings calls. (Various analyst projections for 2026 full-year industry capex circulate in trade press, but because those are forward estimates rather than confirmed actuals, we’ve left them out here.)

That spending is increasingly measured in gigawatts rather than square footage. Meta’s October 2025 Hyperion campus in Louisiana — a $27 billion joint venture with Blue Owl Capital — was announced with a first phase around 2 GW of capacity, with Mark Zuckerberg stating it could scale up to 5 GW over several years. When a data center’s binding constraint is described in power-grid units rather than real estate, that’s a reasonably clean signal of how central electricity supply has become to where and how these facilities get built.

Bottom Line

AI hasn’t just increased demand for data centers — it has changed what counts as a well-designed one. Rack power density that would have been unthinkable a decade ago is now standard for frontier AI hardware, air cooling has hit a physical ceiling that liquid cooling is stepping in to solve, and the resulting electricity demand is large enough to show up in grid operators’ decade-ahead planning and to push hyperscalers into financing new power generation directly. None of this is slowing down: combined hyperscaler capex is still growing by double-digit to triple-digit percentages year over year, and the IEA expects data-center electricity use to more than double again by 2030. Anyone evaluating where to site, build, or invest around AI infrastructure needs power and cooling capacity, not just chip availability, at the center of that decision.

Sources

IEA — Energy and AI, executive summary (global data center electricity use, 2024 baseline and 2030 projection)
Platformonomics — Follow the CAPEX: Q3 2025 Scoreboard (hyperscaler Q3 2025 actual capex and FY2025 guidance)
Data Center Dynamics — Meta’s $27B Hyperion joint venture with Blue Owl
Modo Energy — PJM’s 2025 demand forecast and data centers
Data Center Knowledge — AI rack density’s real limits: power, cooling, failure risk
Data Center Knowledge — Uptime Institute global data center survey (PUE and rack density history)
Upsite Technologies — Data center rack density trends
Introl — Liquid cooling vs. air: the 50kW GPU rack guide

Cookie Consent

GDPR vs CCPA vs ePrivacy: What WordPress Site Owners Actually Need to Know

Posted on October 12, 2026October 24, 2026 by Filip Keser

These aren’t three versions of the same rule — they’re two different legal traditions bolted together, plus a third that works almost backwards from the first two. The ePrivacy Directive controls the moment a cookie gets placed on a visitor’s device. GDPR controls everything that happens to the data after that cookie has collected it. CCPA/CPRA doesn’t require a cookie’s permission slip at all by default — it requires you to honor a visitor’s request to stop, after the fact. Which one applies to your WordPress site depends entirely on who’s visiting it, not where you or your server happen to be.

The Three Laws, in Plain Terms

ePrivacy Directive (EU/UK, 2002/58/EC) is the actual “cookie law” — the reason consent banners exist in the first place. It says you need prior opt-in consent before you set any cookie or similar tracking technology that isn’t strictly necessary for the site to function, full stop, regardless of your size or revenue. It’s a Directive, not a Regulation, which matters mechanically: each EU member state passed its own national law implementing it, so enforcement and fine structures vary somewhat country to country (Spain and France’s regulators, for instance, have historically been more cookie-banner-active than most). It’s enforced by national data protection authorities, and in most member states, violations get folded into GDPR’s penalty structure rather than carrying a separate fine schedule.

GDPR (EU, Regulation 2016/679) is the general data protection law — it governs what you’re allowed to do with personal data once you have it, cookie-derived or not. That includes having a valid legal basis for processing (consent is only one of six), giving people the right to access, correct, delete, or export their data, notifying regulators of serious breaches within 72 hours, and restricting how you move EU personal data outside the EU. A cookie consent banner is where GDPR and ePrivacy meet in practice: ePrivacy is why the banner has to appear and be opt-in before tracking starts, and GDPR governs everything the plugin, your analytics tool, or your ad network does with the data once someone clicks “accept.”

CCPA/CPRA (California, effective as amended 2023, with ongoing CPPA rulemaking through 2026) runs on a different model entirely: opt-out, not opt-in. A covered business can process and even sell personal information by default — it just has to give consumers clear, low-friction ways to say no, and to actually honor that “no” without retaliating (no charging a fee or degrading service because someone opted out). It only applies once your business crosses a specific size threshold; unlike GDPR, small sites are exempt by law, not just by enforcement priority. As of the CPPA’s most recent Consumer Price Index adjustment (effective January 1, 2025), that threshold is: annual gross revenue over $26,625,000, OR you buy, sell, or share the personal information of 100,000 or more California consumers or households a year, OR 50% or more of annual revenue comes from selling or sharing personal information.

Side by Side

Dimension	ePrivacy / GDPR (EU/UK)	CCPA/CPRA (California)
Trigger	Any EU/UK visitor reaching your site, regardless of your size or location.	Only once your business crosses the revenue/volume thresholds below.
Consent model	Opt-in — required before the cookie fires.	Opt-out — the default is “on” until a visitor tells you to stop.
What’s regulated	ePrivacy: placing a cookie/tracker. GDPR: everything done with the data afterward (legal basis, rights, breaches, transfers).	Sale/sharing of personal information, plus the same rights model (access, deletion, correction, opt-out, limiting sensitive-data use).
Small-site exemption	None — a 200-visit/month blog with Google Analytics is technically in scope.	Yes, by statute, below the revenue/volume thresholds.
Required mechanic	A prior-consent banner that blocks non-essential scripts until accepted.	A “Do Not Sell or Share”/”Your Privacy Choices” link, honoring GPC as a valid opt-out, with symmetrical accept/decline design (per 2025-2026 CPPA enforcement).
Maximum penalty	Up to €20M or 4% of global annual turnover (most serious Article 83 violations; not realistic exposure for a small site with a stale banner).	Up to $2,663 per violation ($7,988 for intentional or minor-involving violations); private right of action of $107–$799 per incident for certain breaches.

Why This Actually Matters for Your Site, Not Just in the Abstract

If your WordPress site can be reached by EU or UK visitors — which, unless you’ve geo-blocked the region, it can — the ePrivacy/GDPR combination applies the moment you set a non-essential cookie, no matter your traffic or revenue. That’s the one with no small-business door to walk through. CCPA/CPRA is the one most WordPress site owners in this series’ audience won’t actually be legally required to comply with yet, because most personal blogs, niche review sites, and small WooCommerce stores don’t clear $26.6 million in revenue or handle 100,000+ Californians’ data a year. But two things make it worth building for anyway: first, a lot of consent plugins (see our plugin roundup — Complianz in particular) handle GDPR, CCPA, and a dozen other regimes in the same free tier, so there’s rarely a reason to configure for GDPR only; second, CCPA’s thresholds are revenue-based, and a site that starts small doesn’t always stay that way.

The Other State Laws You’ve Probably Heard Of

CCPA isn’t the only U.S. state privacy law anymore — it’s just the oldest and best-known. As of 2026, twenty U.S. states have comprehensive consumer privacy laws in effect, including three (Indiana, Kentucky, and Rhode Island) that took effect January 1, 2026. Most of the newer ones — Colorado, Connecticut, Virginia, Utah, Oregon, Texas, and the rest — largely follow Virginia’s template rather than California’s or the EU’s: opt-out by default, revenue/volume thresholds, and (increasingly) a requirement to honor the Global Privacy Control signal specifically. Twelve states now require GPC compliance by law: California, Colorado, Connecticut, Delaware, Maryland, Minnesota, Montana, Nebraska, New Hampshire, New Jersey, Oregon, and Texas. Practically, if your consent plugin already honors GPC for CCPA, you’re most of the way to compliant with the other eleven states’ GPC requirement too — it’s one signal, not twelve separate integrations.

What’s Actually Changing Right Now

Two developments are worth knowing about. First, the long-proposed EU ePrivacy Regulation — which would have replaced the 2002 Directive outright — was formally withdrawn by the European Commission (approved July 16, 2025; published October 6, 2025). The current ePrivacy Directive and GDPR remain the binding law exactly as described above; nothing in this withdrawal changes what your site needs to do today.

Second, and now resolved at the Council stage: on October 21, 2026, the Council of the EU formally adopted its negotiating position on the EU’s “Digital Omnibus” package, settling months of uncertainty over whether cookie consent would move into the GDPR. It won’t. The Council’s text drops the proposed GDPR Articles 88a and 88b entirely and keeps cookie rules inside the ePrivacy Directive, via an amended Article 5(3). That amended article lists six situations where a site won’t need visitor consent before setting a cookie: transmitting a communication, providing a service the visitor explicitly asked for, first-party audience measurement, media audience measurement, maintaining or restoring technical security, and measuring the effectiveness of contextual advertising. It also shortens the mandatory wait before re-prompting someone who refused from six months to four, and moves oversight to GDPR data protection authorities. The browser-level “set your consent once” signal that would have cut down repeat banners did not make it into the Council’s text, despite a public push from privacy groups including noyb and BEUC. None of this is law yet: it’s a mandate for negotiations with the European Parliament, which hasn’t adopted its own position. Don’t expect any change to the banner on your WordPress site in 2026, and possibly not in 2027 either — the current ePrivacy Directive and GDPR described above remain what applies today. (Legal status last verified October 24, 2026.)

Bottom Line

Think of it less as three competing laws and more as two layers plus one outlier: ePrivacy is the door (can you set the cookie at all, and did you ask first), GDPR is the house (what you’re allowed to do with the data once you’re in), and CCPA/CPRA is a different building altogether that assumes entry is fine by default and regulates the exit instead. A WordPress site reachable from the EU/UK needs to satisfy the door-and-house combination regardless of size; a site that also crosses CCPA’s revenue or volume thresholds needs the opt-out mechanics on top of that. Most consent plugins worth using (see our roundup) are built to handle all of this — and the dozen-plus U.S. state laws behind it — from one configuration screen, which is the practical reason to set one up correctly once rather than chase each law individually.

For the practical “now what” — do I need a policy page, a banner, or both — see our companion piece, Do You Need a Cookie Policy on Your WordPress Site? And if you haven’t picked a tool yet, start with our plugin roundup.

Sources

eur-lex.europa.eu — Directive 2002/58/EC (ePrivacy Directive) and Regulation (EU) 2016/679 (GDPR), including Article 83 fine tiers
European Commission — formal withdrawal of the proposed ePrivacy Regulation (approved July 16, 2025; published October 6, 2025)
cppa.ca.gov — “Updated Monetary Thresholds in CCPA” (CPI adjustment effective January 1, 2025): revenue exemption, administrative fine, and private-right-of-action figures
cppa.ca.gov enforcement announcements — American Honda Motor Co. (March 2025) and Todd Snyder (May 2025) cookie/opt-out enforcement actions
clym.io and multistate.us — 2026 U.S. state comprehensive privacy law tracker and 12-state Global Privacy Control requirement list
Council of the EU — press release on its Digital Omnibus negotiating mandate (adopted October 21, 2026; published October 22, 2026), with coverage from Agence Europe, nicfab.eu, and ppc.land’s reporting on Council document 13886/26
Background on earlier positions: EDRi — analysis of the Digital Omnibus Council compromise text; PPC Land — EU Council drops cookie signal after Google lobbying (June 2026); praxikon.com — Digital Omnibus tracker

software online review

Google AI

Posted on December 18, 2025October 27, 2026 by Filip Keser

https://one.google.com/

https://one.google.com/about/

https://one.google.com/about/google-ai-plans/

https://gemini.google.com/

Gemini 3 Pro is Google’s most advanced AI model. It is designed to handle complex tasks that require advanced reasoning and understanding of different types of data. It is currently available in preview for developers and through the Google AI Pro plan.

Key features and capabilities:

Complex tasks: Gemini 3 Pro is optimized for complex tasks that require broad general knowledge and advanced reasoning across various data types, such as text, images, and video.
Creative generation: The model excels at creative writing and developing complex, multifaceted concepts.
Advanced reasoning: It is considered the most intelligent Google model to date, with improved logical reasoning, analysis, and coding capabilities.
Research assistance: It assists users in summarizing hours of work into minutes by providing detailed reports on topics by analyzing hundreds of web pages in real-time.
Multimodality: It has advanced visual and spatial reasoning capabilities (such as the Gemini 3 Pro Image model).

Availability:

Gemini 3 Pro is currently in preview and is available through:

Gemini API: Developers can access the model through the Google AI Studio and Vertex AI platforms to build applications.
Google AI Pro subscription: Users who subscribe to the Google AI Pro plan get extended access to Gemini 3 Pro features, including the “Deep Research” feature.

The model was launched in November 2025. Demand was so high that Google had to temporarily adjust the system to ensure availability. Pricing is calculated per million tokens, and details are available on the API pricing page.

https://jules.google/

Jules is Google’s autonomous, asynchronous AI coding agent designed to help software developers automate complex tasks like fixing bugs, writing tests, and implementing new features.

Unlike traditional “co-pilots” that suggest code as you type, Jules acts like an independent collaborator that clones your codebase into a secure virtual machine (VM) to perform work in the background.

Key Capabilities and Features (2025 Updates)

Autonomous Workflow: Tasks are submitted via prompt, and Jules plans, executes, and verifies the changes independently, eventually opening a pull request.
Asynchronous Development: Developers can assign tasks to Jules and continue working on other projects while it runs in a cloud environment.
Gemini-Powered Intelligence: As of late 2025, Jules utilizes advanced models like Gemini 2.5 Pro and has been updated with integrations for Gemini 3 for improved reasoning and transparency.
Critic-Augmented Generation: A “critic” feature provides an adversarial review of Jules’ proposed changes before completion to ensure high code quality.
Proactive Assistance: A new Suggested Tasks feature automatically scans code to propose improvements or schedule routine updates without being prompted.
Audio Changelogs: It can generate audible summaries of recent commits to help developers catch up on project history.

How to Use Jules

Web Interface: You can sign in and manage repositories at jules.google.com.
Command Line (CLI): Use Jules Tools to interact with the agent directly from your terminal, allowing for parallel task runs and local diff viewing.
Jules API: Developers can programmatically integrate Jules into custom workflows, CI/CD pipelines, or tools like Slack and Linear.
GitHub Integration: Tasks can be assigned directly by adding a jules label to an issue in a connected GitHub repository.

Pricing and Availability

Jules is currently in Public Beta. It is available globally where Gemini is supported and offers structured tiers:

Free Tier: Accessible to all users for basic exploration.
Paid Tiers: Higher usage limits are available via Google AI Pro and Ultra subscriptions.

https://antigravity.google/

In 2025, “Google Antigravity” primarily refers to a professional software development platform, though it can also refer to a classic search engine Easter egg.

1. Google Antigravity (Agentic IDE)

Launched on November 18, 2025, Google Antigravity is an “agent-first” AI-powered Integrated Development Environment (IDE). Antigravity uses autonomous agents to plan, execute, and verify entire development tasks. Standard coding assistants suggest code snippets.

Key Components:
- Agent Manager: This is an interface for orchestrating multiple background agents. The agents work across different workspaces.
- Editor View: This is a fully-featured IDE (forked from Visual Studio Code) for coding with AI-powered tab completion and inline commands.
- Antigravity Browser: This browser allows agents to navigate, test, and verify web applications.
Core Features:
- Artifacts: Agents produce deliverables like implementation plans, code diffs, and browser recordings. These allow for easy verification.
- Model Optionality: It is powered primarily by Gemini 3, but also supports other models. These include Anthropic’s Claude Sonnet 4.5 and OpenAI’s GPT-OSS.
- Feedback Loops: Users can leave comments directly on artifacts to guide agent iteration. This is similar to “Google Docs-style” comments.
Availability: It is currently in Public Preview for individual users with personal Gmail accounts. There is no charge. Higher rate limits are available for Google AI Pro and Ultra subscribers.

2. Google Antigravity (Easter Egg)

This web trick mimics the lack of gravity on the Google search page. It is often hosted by third-party sites like Mr. Doob.

How to trigger: Searching “Google Gravity” or “Google Antigravity” and clicking “I’m Feeling Lucky” typically causes the search bar and buttons to fall to the bottom of the screen or float around.
Interaction: Users can click and “throw” the various page elements across the screen.

google antigravity vs google jules

In 2025, Google offers two distinct agentic coding tools:

Antigravity and Jules. Both use Gemini 3 models for coding automation, but they differ in their environment and interaction style.

Quick Comparison (2025)

Feature	Google Antigravity	Google Jules
Primary Format	Standalone AI-first IDE (fork of VS Code)	Background/Asynchronous Coding Agent
User Interaction	Synchronous/Interactive: Code alongside agents in real-time.	Asynchronous: Assign a task and return later.
Integration	Local environment; works like Cursor or Windsurf.	Integrated with GitHub repositories and works in a cloud VM.
Best For	Active development, “vibe coding,” and multi-agent orchestration.	Routine maintenance, bug fixing, and long-running documentation tasks.

Google Antigravity: The AI-First IDE

Launched in November 2025, Antigravity is an “agent-first” development platform designed as a direct competitor to Cursor.

Key Strength: Orchestration. It allows multiple agent threads to run simultaneously, such as one agent refactoring a file while another writes unit tests.
Browser Control: It integrates Chrome, allowing agents to “see” rendered HTML, click buttons, and run front-end tests autonomously.
Status: Currently in public preview; it supports Gemini 3 Pro and Claude 3.5 models.

Google Jules: The Asynchronous Agent

Jules is a specialist “subcontractor” that handles bounded tasks in the background.

Key Strength: Autonomy. Jules runs in a secure cloud environment (VM), meaning it can work on a task for hours without requiring the user’s session to stay active.
GitHub Focused: It is primarily used to open branches, fix GitHub issues, and submit pull requests automatically.
Availability: Now out of beta and available via Jules.google or as a VS Code extension.

Pricing & Access

Both tools are part of the Google AI Pro/Ultra plans (typically bundled with Google One subscriptions):

Jules: Offers a free tier; paid tiers provide higher concurrency (e.g., 15 tasks at once).
Antigravity: Available for free during its initial launch period, with premium rate limits tied to the Google AI Pro plan.

https://geminicli.com/

https://codeassist.google/

https://developer.android.com/studio