The AI Landscape in 2026: Where the Big Players Stand and What It Means for Your Strategy.

The Model Layer: Who Is Winning and Where

Anthropic (Claude)

Claude is the strongest model for software development. This is not a marginal difference; in our daily usage across engagements, Claude consistently produces better code, follows complex instructions more reliably, and handles large codebases with more coherence than the alternatives. For the agentic engineering workflows that define Level 3-4 AI-assisted development, where the model needs to read a codebase, understand architecture decisions, write code that fits the existing patterns, and iterate based on test results - Claude is the clear leader.

Beyond code, Claude's reasoning capability and instruction-following make it the strongest general-purpose model for the kind of structured, context-heavy work that characterises professional AI adoption. Writing detailed assessments, analysing complex documents, producing nuanced recommendations: the output quality is consistently higher.

Where Anthropic is weaker: Distribution and ecosystem. Anthropic does not have a cloud platform, an office suite, or an enterprise sales force. Its route to market is the API, partnerships (AWS Bedrock, Google Cloud), and developer adoption. For organisations that want a single vendor relationship for AI infrastructure, Anthropic alone is not the answer; it needs to be consumed through a platform partner.

The opportunity: Anthropic's model quality advantage is real but not permanent. The window in which Claude is meaningfully ahead is the window in which teams should be building capability and practices. When the models converge, and they will, the teams with the strongest practices will retain their advantage. The teams waiting for "the right model" will still be waiting.

OpenAI (GPT, Codex)

OpenAI defined the category and remains the most widely recognised name in AI. GPT-4 and its successors are excellent general-purpose models. Codex, their code-focused offering, is strong and powers GitHub Copilot's inline suggestions.

Where OpenAI wins: Brand recognition, enterprise adoption, and the broadest third-party ecosystem. More tools integrate with OpenAI's API than any other provider. For organisations that need a model that works with everything, from CRM integrations to customer support tools and analytics platforms, OpenAI has the widest compatibility.

Where OpenAI is weaker: In our hands-on experience, the models have not been leading the frontier for code generation in 2026. GPT-4 and its successors are capable, but Claude produces better output for complex software engineering tasks: more coherent multi-file changes, better adherence to existing code patterns, more reliable instruction-following for nuanced specifications. The gap is not enormous, but it is consistent across dozens of engagements.

The opportunity: OpenAI's enterprise relationships and API ecosystem make it the default choice for many organisations. For teams whose primary AI use case is not software engineering (customer support, content generation, data analysis) OpenAI remains a strong choice. For engineering-heavy AI adoption, we recommend evaluating Claude directly.

Google (Gemini)

Google has both excellent models and, critically, its own TPU silicon. This is a structural advantage that is underappreciated in most AI strategy discussions.

Every other major AI provider depends on NVIDIA GPUs for training and inference. NVIDIA's pricing (the "NVIDIA tax") is a significant cost driver for AI infrastructure. Google can bypass this entirely by running on its own TPU hardware. The implication for customers: Google can offer competitive pricing on AI inference because its cost structure is fundamentally different from providers who pay NVIDIA margins.

Where Google wins: The combination of strong models, proprietary silicon, and deep integration with the Google Cloud ecosystem. For organisations already on Google Cloud, Gemini is the path of least resistance, integrated into Vertex AI, BigQuery, and the broader GCP suite. The pricing advantage from TPU infrastructure will become more significant as AI usage scales and inference costs become a material line item.

Google also has the strongest integration story for organisations that use Google Workspace. Gemini embedded in Gmail, Docs, Sheets, and Meet is a different proposition from a standalone AI tool; it is AI woven into the productivity tools your team already uses daily.

Where Google is weaker: Developer mindshare. Despite strong models, Gemini has not captured the developer community the way Claude and GPT have. The API ecosystem is smaller, the third-party tool integrations are fewer, and the developer experience, while improving, lags behind Anthropic's developer-focused approach. For software engineering use cases specifically, Gemini is capable but not the first choice for most of the engineering teams we work with.

The opportunity: Google is the provider most likely to win on economics at scale. For organisations with large AI inference workloads, particularly those already on GCP, the TPU cost advantage and native integration make Google a compelling long-term choice, even if Claude or GPT is the better model today.

The Platform Layer: Where You Run Your AI

The model you choose and the platform you run it on are separate decisions, and the platform decision often matters more for enterprise adoption.

AWS Bedrock gives you access to Claude, Llama, Mistral, and others through AWS's security and compliance framework. For organisations already on AWS, which is the majority of mid-market UK tech companies, Bedrock is the simplest path to Level 2 AI security. Your data stays in your AWS environment, processed under your existing agreements, with the security controls you already have in place.

Azure AI provides access to OpenAI models through Microsoft's enterprise infrastructure. The integration with Microsoft 365, Active Directory, and the Azure compliance framework makes it the natural choice for Microsoft-oriented organisations. The Copilot integrations across Office, Teams, and GitHub create a coherent AI experience within the Microsoft ecosystem.

Google Cloud (Vertex AI) offers Gemini natively plus third-party models, with the TPU cost advantage for Google's own models. The integration with BigQuery and Google Workspace makes it compelling for data-heavy AI use cases and Google-oriented organisations.

The practical recommendation for most mid-market companies: use the cloud platform you are already on. The cost and complexity of switching cloud providers to access a marginally better AI model almost never justifies the migration. If you are on AWS, use Bedrock. If you are on Azure, use Azure AI. If you are on GCP, use Vertex AI. The model quality differences between providers are real but smaller than the operational cost of maintaining AI infrastructure on a platform your team does not know.

Small Models and Self-Hosted: The Overlooked Opportunity

Most AI strategies focus exclusively on frontier models: GPT-4, Claude Opus, Gemini Ultra. These are the most capable models, but they are not always the right choice. Smaller models and self-hosted deployments fill a set of use cases that frontier models serve poorly or expensively.

Where Small Models Win

Always-on, unlimited use. Frontier model APIs charge per token. For use cases that require continuous AI processing (monitoring, filtering, classification, real-time analysis) the cost of frontier APIs scales linearly and can become prohibitive. A small model running on your own infrastructure has a fixed cost regardless of volume. For high-throughput, targeted tasks, the economics are dramatically better.

Agentic task execution. This is where small models are increasingly compelling. For agentic workflows such as automated code review, test generation, documentation, log analysis, and data validation, you often do not need frontier-level reasoning. You need a model that is fast, cheap, reliable, and good enough at a specific task. A small model fine-tuned for code review will outperform a general-purpose frontier model at code review, at a fraction of the cost, with no rate limits.

Domain-specific fine-tuning. This is the most underappreciated capability of small models. A general-purpose frontier model knows a little about everything. A small model fine-tuned on your domain data (your codebase, your documentation, your industry terminology, your customer interactions) can achieve near-frontier capability in that narrow domain. The fine-tuning investment is modest (days, not months) and the result is a model that understands your specific context better than any general-purpose alternative.

Simple workflow integration. Not every AI use case requires a conversation with a frontier model. Summarising a support ticket, classifying an email, extracting data from an invoice, generating a commit message: these are tasks where a small, fast model integrated into an existing workflow produces better outcomes than routing through a frontier API. The latency is lower, the cost is lower, and the integration is simpler.

The Architectures That Make It Work

Small models have improved dramatically in 2025-2026, driven by two architectural innovations:

Mixture of Experts (MoE). MoE architectures use multiple specialised sub-networks ("experts") and route each input to the most relevant experts. The result is a model that behaves like a large model on any given task but only activates a fraction of its parameters, dramatically reducing inference cost and latency. Models like Mixtral demonstrated that MoE architectures can deliver near-frontier quality at a fraction of the compute cost.

Quantisation. Reducing the numerical precision of model weights, from 32-bit to 8-bit or even 4-bit, shrinks model size and inference cost with surprisingly modest quality loss. A well-quantised 70-billion parameter model can run on hardware that would not support the full-precision version, making self-hosted deployment feasible for organisations that cannot justify dedicated GPU clusters.

Combined, these techniques mean that a self-hosted model running on modest hardware can handle targeted tasks (code review, classification, summarisation, domain-specific Q&A) with quality that would have required frontier models eighteen months ago.

The Availability Argument

There is a practical consideration that most AI strategies overlook: availability.

We have seen significant availability issues with frontier model APIs: outages that last hours, rate limiting during peak usage, degraded performance during high-demand periods. For teams that have built AI deeply into their development workflow, an API outage is not an inconvenience; it is a productivity cliff. Engineers who have restructured their working practices around AI-assisted development cannot simply revert to writing code manually when the API goes down.

Self-hosted models do not have this problem. They are available when your infrastructure is available, which is under your control. For organisations where AI tooling is mission-critical, where a four-hour outage means a missed sprint commitment or a delayed deployment, a self-hosted model for core workflows provides a resilience that API-dependent tools cannot.

This does not mean abandoning frontier APIs. The practical approach is a tiered strategy: frontier models for the tasks that require frontier capability (complex reasoning, novel code generation, nuanced analysis), and self-hosted or small models for the high-volume, targeted tasks where availability, cost, and latency matter more than peak intelligence.

Vendor Concentration Risk

This is the dimension that most AI strategies ignore and that we assess explicitly in our AI readiness reviews.

If your critical AI capability depends entirely on a single provider, you have a concentration risk. What happens if that provider:

• Raises API prices by 50 per cent? (OpenAI has changed pricing multiple times.)
• Changes their terms of service to restrict your use case?
• Suffers a sustained outage during your critical deployment window?
• Gets acquired by a company with different priorities?
• Deprecates the model version your system depends on?

These are not hypothetical risks. Every one of these has happened to at least one major AI provider in the past eighteen months. The mitigation is not to avoid AI adoption; it is to architect your AI capability with portability in mind.

Context engineering helps here. If your AI workflow is built around structured specifications, project context files, and automated quality gates rather than provider-specific prompts and API features, switching providers is a configuration change, not a rewrite. The practices described in our AI development maturity spectrum are inherently portable: the specifications you write for Claude work for GPT. The context files you build for Cursor work for Claude Code. The automated tests that verify AI output do not care which model generated it.

The tiered approach helps here too. Using frontier models for complex tasks and self-hosted models for routine tasks means that a frontier API outage degrades your capability rather than eliminating it. Your team can still work, just at reduced capacity for the most complex tasks.

Related Reading

• Cursor vs Claude Code vs Copilot - which AI coding tool should your team standardise on
• What Is Vibe Coding? And Why It's Not Enough, the AI development maturity spectrum
• How Mid-Market CEOs Can Deploy AI at Speed, the five-level AI security framework
• AI Readiness Assessment - what investors should actually measure
• What We Actually Assess in an AI Readiness Review, the seven dimensions including vendor concentration risk
• AI Enablement Services: strategy, assessment, and capability building
• AI Bootcamp - intensive training on AI-assisted development