The Rise of Multi-Model Engineering: Is IBM Bob Already Built for the Next Phase?

For several years, developers compared AI coding models based on benchmarks, personal experiments, context-window size, coding quality, speed, and price. The central question was simple: which model is best for coding?

In 2026, that question is becoming less useful. Not because one model has won, but because model selection is moving away from the developer and into the platform. I see this across product announcements, documentation, technical blogs, open-source projects, videos, and hands-on developer workflows.

This post compares what their public documentation actually supports. Where I go beyond the documentation, I say so. Product capabilities and factual statements were checked against publicly available primary sources on 30 July 2026.

Short Executive Summary

AI coding platforms are moving beyond the question of which individual model is best.

The important shift in 2026 is that model selection and agent coordination are increasingly becoming platform responsibilities.

The main findings of this article are:

• IBM Bob is one of the clearest documented examples of built-in cross-provider model orchestration. IBM describes Bob as selecting from Granite, Claude, Mistral, and specialized models according to criteria such as accuracy, performance, latency, and cost.
• GitHub Copilot combines automatic model selection with repository-native access to coding agents such as Copilot, Claude, and Codex. GitHub currently provides more visible information about the model selected by its router.
• Gemini CLI demonstrates task-based, fallback, and experimental local routing primarily within Google’s own model ecosystem.
• Claude Code emphasizes configurable models, subagents, and external gateway-based routing rather than one native cross-provider router.
• OpenAI Codex emphasizes a flexible coding-agent harness, parallel agents, and configurable inference endpoints.

My conclusion is that IBM Bob appears architecturally advanced in treating managed cross-provider orchestration as a core product capability. However, this does not prove that Bob always selects the best model, provides the lowest customer cost, or offers the strongest transparency.

The broader market shift is from:

Which coding model should I use?

to:

Which orchestration platform should select, coordinate, and govern the models and agents for me?

This reduces model-level dependency, but it can create a new dependency on the orchestration platform itself.

Something Changed in AI-Assisted Development

I did not start this article as a theoretical market comparison. The idea came from my own work with IBM Bob, Claude Code, Codex, GitHub Copilot, Gemini, and local models. I increasingly noticed that I was no longer choosing one permanent coding assistant. I was combining different tools for planning, implementation, and review. That practical observation led me to the central question of this post: will the orchestration platform become more important than the individual model?

AI development platforms and developers are increasingly combining several models and agents for different parts of the software development lifecycle.

I also see this shift in my own practical work with tools such as:

• IBM Bob
• Claude Code
• OpenAI Codex
• GitHub Copilot
• Gemini CLI

These tools are no longer always treated as direct alternatives.

Developers use them together.

One agent may analyze a repository and create a plan. Another may implement the change. A third may review the result. In other workflows, the platform selects the underlying model automatically without asking the developer to make that decision.

This changes the central question.

It is no longer only:

Which coding model should I use?

The more important question is becoming:

Which platform should select, coordinate, and govern the models and agents used for my software-engineering task?

My current conclusion is that the market is moving in this direction.

However, several different concepts are often mixed together:

• Manual model selection
• Automatic model routing
• Multi-agent execution
• Cross-provider orchestration

They are related, but they are not the same.

Table of contents

1. Model Pickers, Model Routers, and Agent Orchestration
2. From One Main Model to an Orchestration Layer
3. IBM Bob: Multi-Model Orchestration by Design
4. GitHub Copilot: Model Routing and Agent Choice on the Repository Platform
5. Google Gemini CLI: Routing Within the Gemini Ecosystem
6. OpenAI Codex: Multi-Agent Execution Around an OpenAI-Centered Stack
7. Claude Code: Model Selection, Subagents, and Gateway-Based Routing
8. The Community Is Already Building Multi-Vendor Workflows
9. The Economic Trade-Off: Cost, Control, and a New Form of Lock-In
10. What Changes for Developers?
11. Is IBM Bob Architecturally Ahead?
12. Where I Think This Goes Next
13. My View
14. Current Capability Comparison
15. Sources and Evidence

1. Model Pickers, Model Routers, and Agent Orchestration

Before comparing the platforms, it is useful to separate several concepts that are often mixed together. The visual below shows the three main approaches.

Figure 1: Manual model selection, automatic model routing, and multi-agent orchestration solve different problems. The diagram is a conceptual overview, not a representation of one specific product.

1.1 Manual Model Selection

With manual model selection, the developer chooses the model directly.

For example, the developer may select:

• A fast model for a simple change,
• A reasoning model for architecture or debugging,
• A coding-focused model for implementation.

The platform provides the available models, but the developer makes the routing decision.

This requires the developer to understand:

• Which model is suitable for which task,
• The expected quality,
• The latency,
• The usage limits,
• The cost.

In this approach, the developer effectively acts as the model router.

1.2 Automatic Model Routing

With automatic model routing, the platform selects the model.

The routing decision may consider factors such as:

• Task complexity
• Model availability
• Latency
• Expected quality
• Reliability
• Cost
• Policy restrictions

The developer describes the task, while the platform decides which model should process it.

This can reduce decision fatigue and unnecessary use of expensive reasoning models.

However, it also creates a transparency question:

Can the developer see which model was selected and why?

The answer differs between platforms.

1.3 Fallback Routing

Fallback routing is a more limited form of model routing. It does not necessarily select the best model for the task. Instead, it selects another model when the preferred model is unavailable because of:

• Quota limits
• Service errors
• Capacity constraints
• Regional availability
• Policy restrictions

This distinction matters: Task-based routing attempts to match a model to the work. Fallback routing mainly keeps the service operational.

1.4 Multi-Agent Orchestration

Multi-agent orchestration goes beyond selecting a model.

Different agents perform different roles in a workflow.

For example:

• A planning agent analyzes the repository and creates a plan
• An implementation agent changes the code
• A testing agent executes validation
• A review agent evaluates the result

An agent normally combines:

• One or more models
• Instructions
• Tools
• Permissions
• Context management
• An execution loop
• Workflow logic

A model produces an inference.

An agent uses a model as one component of a larger software-engineering process.

1.5 Multi-Model Is Not the Same as Multi-Agent

A platform can support several models without supporting several cooperating agents.

It can also run several agents while using the same underlying model for all of them.

These are separate architectural dimensions:

The most advanced platforms increasingly combine all four.

2. From One Main Model to an Orchestration Layer

To understand the current shift, it helps to look at the simplified development path of AI coding assistants.

This is historical context, not a precise timeline for every product.

2.1 One Assistant and One Primary Model

Earlier AI coding assistants were commonly experienced as a connection between one development tool and one primary model.

The interaction was relatively simple:

Developer → Coding Assistant → Primary Model

Typical capabilities included:

• Code completion
• Code explanation
• Generation of small functions
• Simple refactoring
• Repository chat

The product was often evaluated mainly through the perceived quality of its underlying model.

The central questions were:

• Which model writes better code?
• Which model understands more context?
• Which model produces fewer errors?
• Which model is faster?
• Which model is cheaper?

This encouraged developers to think in terms of one winner.

2.2 The Model Picker Phase

The next step was not yet automatic orchestration.

Platforms began offering access to several models inside the same interface.

The developer could choose between models optimized for different priorities, such as:

• Speed
• Reasoning
• Coding
• Larger context
• Lower cost

This increased flexibility, but it also moved a new responsibility to the developer.

The developer now had to decide:

Which model should I select for this task?

The platform offered the portfolio, but the user still managed the selection.

2.3 The Automatic Routing Phase

The next architectural step is to move that decision into the platform.

Instead of asking the developer to choose a model for every task, the platform can evaluate the work and select a suitable model automatically.

The question changes from:

Which model do I want to use?

to:

Which platform do I trust to select the model for me?

This is not only a user-interface change.

It moves responsibility for model selection, cost optimization, reliability, and governance into the orchestration layer.

2.4 From Models to Complete Agents

The transition does not stop at model selection.

Platforms coordinate complete agents that can:

• Analyze repositories
• Create plans
• Edit files
• Run terminal commands
• Execute tests
• Review changes
• Apply security or governance checks

At this point, the underlying model becomes only one component of the system.

The product becomes the layer that manages:

• Models
• Agents
• Tools
• Context
• Policies
• Execution
• Cost

This is the transition examined in the rest of this post: model and agent selection are increasingly becoming part of the platform.

The developer no longer needs to manage every model directly. Instead, the developer chooses the platform that manages the model portfolio.

3. IBM Bob: Multi-Model Orchestration by Design

IBM Bob is one of the clearest current examples of an AI development platform that treats multi-model orchestration as a built-in product capability.

Instead of asking the developer to select an underlying model for every task, IBM describes Bob as dynamically matching tasks to models according to criteria such as:

• Accuracy
• Performance
• Latency
• Cost

IBM publicly identifies a model portfolio that includes:

• IBM Granite models
• Anthropic Claude
• Mistral models
• Specialized fine-tuned models for code reasoning
• Security-focused models
• Next-edit prediction models

IBM also explains that simpler tasks can be routed to lighter models, while more complex work can be assigned to more capable models.

The stated objective is to improve results while avoiding unnecessary model cost.

Primary source: IBM Newsroom, 28 April 2026 — Introducing IBM Bob

3.1 What Is Publicly Documented

Based on IBM’s public description, the following statements are supportable:

• Bob uses more than one model family.
• Bob includes models from more than one provider.
• Model selection is managed inside the platform.
• Routing can consider accuracy, performance, latency, and cost.
• Smaller models can be used for simpler work.
• More capable models can be used for more complex work.
• Specialized models can support specific software-engineering functions.

This means Bob is more than a user-facing model picker.

The developer interacts with Bob, while the platform manages the underlying model portfolio.

Figure 2: Conceptual representation of IBM Bob based on IBM’s public product descriptions. The diagram illustrates the documented model portfolio and orchestration concept. It does not represent IBM’s undisclosed internal routing implementation.

3.2 Model Routing and Agent Orchestration Are Two Different Layers

IBM expanded Bob’s architecture further in July 2026 with capabilities including:

• Subagents
• Parallel model-native tool calling
• Bobalytics for usage and cost visibility
• Specialized modernization workflows

Primary source: IBM Newsroom, 9 July 2026 — IBM Bob multi-agent capabilities

This introduces two related but separate orchestration layers.

Model routing

Model routing determines which inference capability should process a task.

Examples include:

• A smaller model for a straightforward edit,
• A stronger reasoning model for complex analysis,
• A specialized model for security-related work.

Agent orchestration

Agent orchestration determines which agent or subagent should perform a specific role.

Examples include:

• Repository analysis
• Planning
• Implementation
• Modernization
• Security review
• Validation

A subagent can work in an isolated context and return only the relevant result to the main workflow.

This can reduce context growth because exploratory searches, file reads, and intermediate tool traces do not all need to remain in the main agent context.

It may also reduce cost, although the exact effect depends on the workflow, model usage, and implementation.

3.3 What IBM Does Not Publicly Disclose

IBM documents the overall orchestration concept, but not the complete internal routing implementation.

The publicly available sources do not clearly explain:

• The exact classifier used to determine task complexity
• Which exact model handles every individual operation
• Whether a model can change during one task
• How quality and cost are weighted against each other
• Whether multiple models validate the same result
• The frequency and logic of fallback routing
• The full list of models active at a given time
• Which models IBM operates directly
• Which models are accessed through external provider infrastructure
• The internal cost of each model call
• Whether users receive a complete model-level audit trail

Therefore, I cannot state:

IBM Bob always selects the best available model for every task.

That conclusion would not be independently verifiable from the public documentation.

The supportable statement is:

IBM Bob is designed to select a suitable model based on criteria such as accuracy, performance, latency, and cost.

There is an important difference between a documented optimization objective and independently demonstrated optimal routing.

3.4 Convenience, Control, and Transparency

Automatic orchestration can remove significant complexity from the developer workflow.

The developer does not need to continuously compare:

• Model benchmarks
• Provider-specific limits
• Latency
• Pricing
• Task-specific model strengths

However, this abstraction creates new questions:

• Which model generated this code?
• Which provider processed the repository context?
• Was a smaller model selected mainly because of cost?
• Was the result validated by another model or agent?
• Where did the model execute?
• What did the individual operation cost?
• Why did the router make this decision?

IBM provides usage, productivity, quality, governance, consumption, and cost information through Bobalytics.

However, based on the public documentation I reviewed, it is not clear whether users receive a complete per-operation routing trace that identifies every model, provider, decision criterion, and validation step.

IBM does make two related claims that deserve to be stated fairly.

• First, IBM describes BobShell as creating self-documenting agentic processes, so that actions remain traceable from start to finish.
• Second, IBM describes pass-through pricing alongside usage visibility, so that organizations can connect AI spend to outcomes.

Both claims matter. Neither of them answers the narrower question I am asking here. Action-level traceability is not the same as a model-level routing record, and pass-through pricing describes how a cost is billed, not which model the router chose or why. Those are the details I could not establish from the public sources.

Primary source: IBM Newsroom, 28 April 2026 — Introducing IBM Bob

This creates a central trade-off:

The orchestration platform reduces operational complexity, but the developer may receive less direct control and less visibility into the underlying execution path.

3.5 My Interpretation

The following is my interpretation, not an official statement from IBM.

In my view, Bob’s architectural advantage is not that IBM owns one model that must be the best for every software-engineering task.

Its advantage is that IBM can combine:

• Its own Granite models
• External frontier models
• Open and open-weight models
• Specialized models
• Task-specific agents
• Enterprise governance

This gives IBM the ability to change the model portfolio behind a relatively stable developer interface.

A newer or stronger model can potentially be introduced without requiring developers to redesign their complete workflow.

This is why I see Bob less as a single-model coding assistant and more as an orchestration platform for software engineering.

4. GitHub Copilot: Model Routing and Agent Choice on the Repository Platform

GitHub Copilot is moving in the same general direction as IBM Bob, but through a different product architecture.

GitHub now combines at least three distinct capabilities:

• Access to several models
• Automatic model selection
• Execution of complete coding agents through Agent HQ

These capabilities should not be treated as identical.

Figure 3: Example of GitHub Copilot in Visual Studio Code. The available model and agent controls depend on the plan, extension version, and organizational configuration.

4.1 Automatic Model Selection

GitHub documents an Auto model-selection system that evaluates both model conditions and task requirements.

According to GitHub, the routing process considers factors such as:

• Task complexity
• Model availability
• Model health
• Reliability
• Latency
• Cost or premium-request efficiency

Higher-capability reasoning models can be reserved for difficult work, while simpler requests can be assigned to faster or less expensive models.

GitHub also documents that model switching is handled at natural cache boundaries rather than continuously during every conversation step.

This matters because switching models can invalidate cached context and increase cost.

Primary source: GitHub Docs — Auto model selection

The development during 2026 shows a clear product direction:

• 17 April 2026: Auto model selection became available in Copilot CLI.
• 20 May 2026: task-based Auto routing became available in Visual Studio Code.
• 24 June 2026: Auto became the only model-selection experience for Copilot Free and Student plans.
• 1 July 2026: enterprise administrators gained the ability to make Auto the default for new conversations.

For a growing group of Copilot users, manual model selection is therefore no longer the normal default.

However, this does not mean that manual control has disappeared from every Copilot plan and interface.

The available level of control depends on:

• The Copilot plan
• The interface
• Organization policy
• The selected workflow

4.2 GitHub Exposes the Selected Model

GitHub provides more model-level visibility than many managed routing platforms.

Depending on the interface, users can see which model Auto selected:

• By hovering over a Copilot Chat response
• In Copilot CLI output
• At the end of a cloud-agent response
• Next to the Auto indicator in supported interfaces

This does not reveal the complete routing logic.

It does, however, answer one important question:

Which model produced this response?

That is different from knowing:

• Why the model was selected
• How alternatives were evaluated
• Whether another model validated the output
• How cost and quality were weighted

The distinction is therefore:

• Model visibility shows the result of the routing decision,
• Routing transparency explains how and why that decision was made.

GitHub provides the first more clearly than the second.

4.3 Agent HQ Is Not the Same as Model Routing

GitHub Agent HQ moves beyond selecting foundation models.

GitHub introduced coding agents from competing providers, including:

• GitHub Copilot
• Anthropic Claude
• OpenAI Codex
• Custom agents

One qualification is important here. When GitHub introduced Claude and Codex on Agent HQ in February 2026, both were released as a public preview and required a Copilot Pro+ or Copilot Enterprise subscription.

Agent choice is therefore a plan-dependent capability rather than a universal Copilot feature. That matters for the comparison in this post: availability and architecture are not the same thing.

These agents can operate within GitHub and supported development environments while keeping work connected to:

• Issues
• Branches
• Commits
• Pull requests
• Reviews
• Repository history

GitHub can also let users assign the same issue to more than one agent and compare the resulting approaches.

Primary source: GitHub Blog, 4 February 2026 — Pick your agent

This is not simply model routing.

A model router asks:

Which model should process this inference?

Agent HQ asks:

Which coding agent should perform this software-engineering task?

A coding agent includes more than a model. It may include:

• Its own system instructions,
• Execution loop,
• Tool access,
• Repository interaction,
• Permissions,
• Planning behavior,
• Review workflow.

The same platform can therefore support both:

• Automatic model selection
• Explicit agent selection

4.4 GitHub’s Strategic Advantage

GitHub approaches orchestration from the repository and collaboration layer.

It already manages:

• Source code
• Issues
• Pull requests
• Code review
• Permissions
• Development history
• Continuous integration workflows

This gives GitHub an important advantage.

Different agents can work inside the same repository context without requiring the developer to manually copy specifications and results between separate products.

The orchestration layer is therefore closely connected to the software-delivery system of record.

4.5 IBM Bob and GitHub Copilot Are Converging

IBM Bob and GitHub Copilot now overlap in several important areas.

This table compares public product capabilities. It is not a quality ranking.

The important conclusion is not that both platforms are identical.

They are converging from different starting points.

IBM Bob starts from:

• Enterprise orchestration,
• Model portfolio management,
• Governance,
• Modernization,
• Specialized workflows.

GitHub starts from:

• Repositories,
• Collaboration,
• Pull requests,
• Developer workflow,
• Agent choice.

A precise conclusion is:

IBM positioned cross-provider multi-model orchestration as a central part of Bob’s product architecture. GitHub is rapidly converging through automatic model selection and repository-native access to competing coding agents.

4.6 What GitHub Does Not Fully Disclose

GitHub exposes more than the selected model. In a June 2026 engineering post, GitHub describes its routing component by name: HyDRA, a routing model that weighs factors such as reasoning depth, code complexity, debugging difficulty, and tool orchestration needs. HyDRA first identifies the models that can meet the quality bar for the task, and then selects among them.

That is more disclosure than most managed routing platforms offer. It is still not a complete account of the decision process.

The available documentation does not fully reveal:

• The exact complexity classifier
• All weighting factors
• The complete ranking logic
• The evaluation of competing models
• The detailed cost function
• Whether model quality is continuously measured per repository
• Whether routing policies differ by language or project
• The full fallback sequence
• Whether another model validates the result

Therefore, the fact that GitHub displays the selected model should not be confused with complete router transparency.

GitHub provides useful operational visibility, but not a full explanation of the internal decision process.

5. Google Gemini CLI: Routing Within the Gemini Ecosystem

Google Gemini CLI also shows how model selection is moving from a manual decision toward a platform capability.

However, its documented architecture differs from IBM Bob.

IBM describes a portfolio that includes models from several providers.

Gemini CLI primarily routes between models inside Google’s Gemini ecosystem.

That distinction is important.

5.1 Product Status Update

Before describing the architecture, one important change needs to be stated.

Google announced on 19 May 2026 that Gemini CLI and the Gemini Code Assist IDE extensions would stop serving requests on 18 June 2026 for Google AI Pro, Google AI Ultra, and free individual users. These tiers are now served by Antigravity CLI instead. Organizations using Gemini CLI through a Gemini Code Assist Standard or Enterprise license, or through paid Gemini API access, keep unchanged access.

This section therefore describes a documented routing architecture that remains useful as an engineering example. It no longer describes the default Google CLI experience for the affected individual-user tiers after 18 June 2026.

I have kept the section because the routing concepts are still relevant, and because the transition itself is a useful example of the dependency I describe in section 9.

Primary source: Google Developers Blog, 19 May 2026 —    An important update: Transitioning Gemini CLI to Antigravity CLI

5.2 Auto Model Selection

Gemini CLI supports an Auto setting that allows the platform to choose a model according to the task and the available model capabilities.

This reduces the need for the developer to manually select a model for every interaction.

The general pattern is:

• Simpler work can use a faster model
• More demanding work can use a higher-capability model
• The platform can react to model availability

The developer still works inside one primary provider ecosystem, but the exact model can become less visible as a manual decision.

Primary source: Gemini CLI Docs — Model selection

5.3 Plan Mode and Task-Specific Model Use

Google documents that Plan Mode can use higher-reasoning Pro models for planning and architectural work.

This is an example of task-specific model use.

The platform can distinguish between different phases of a software-engineering workflow, such as:

• Exploration
• Planning
• Implementation
• Validation

A planning task may require stronger reasoning than a simple code edit.

This does not necessarily mean that every operation is dynamically routed through a complex general-purpose router.

It does show that Google is assigning different model capabilities to different software-engineering activities.

Primary source: Google Developers Blog, 11 March 2026 — Plan Mode in Gemini CLI

5.4 Task-Based Routing and Fallback Routing

Gemini CLI also supports availability-based routing.

The documented ModelAvailabilityService monitors model health and availability.

If a selected model cannot be used because of conditions such as:

• Quota limits
• Capacity constraints
• Server errors
• Temporary service problems

Gemini CLI can move to a fallback model.

Some internal utility operations can also use a fallback chain between Gemini models.

This introduces two different routing purposes.

Task-based routing attempts to match capability to work.

Fallback routing mainly maintains service continuity.

Both are valid forms of routing, but they should not be treated as the same mechanism.

Primary source: Gemini CLI Docs — Model routing

5.5 Experimental Local Routing with Gemma

One particularly interesting feature is experimental local model routing.

Gemini CLI can use a locally running Gemma model to make the routing decision.

This means the local model can evaluate a request and help determine which hosted Gemini model should receive it.

The important distinction is:

The routing decision can run locally, while the actual coding or reasoning task may still run on a hosted model.

Local routing does not automatically make the complete workflow local.

It can, however, influence:

• Routing cost
• Latency
• Privacy exposure
• Resilience
• Control over classification logic

Google presents local routing partly as a way to reduce hosted-model usage for the routing decision itself.

This is architecturally significant.

It separates the router from the models that execute the main task.

When platforms begin optimizing the cost, latency, and privacy exposure of the routing decision itself, model routing has become infrastructure.

Figure 4: A local model can make the routing decision while the selected model and the main task remain hosted. Local routing therefore does not make the complete workflow local.

Primary source:            Gemini CLI Docs — Local model routing

5.6 What Gemini CLI Does Not Currently Demonstrate

Based on the current public documentation, I did not find evidence that Gemini CLI automatically routes normal coding tasks across commercial model families from:

• Google
• Anthropic
• OpenAI
• IBM
• Mistral

The documented architecture primarily uses Gemini models, with Gemma optionally supporting the routing decision.

Therefore, Gemini CLI should not be described as equivalent to IBM Bob’s documented cross-provider model portfolio.

A precise description is:

Gemini CLI provides automatic, task-related, fallback, and experimental local routing primarily within Google’s own model ecosystem.

5.7 Why the Local Router Matters

The local Gemma router may appear to be a small implementation detail. In my view, it signals a broader architectural direction. The software-engineering task and the routing decision do not need to run in the same place or use the same model.

A future platform could use:

• A local model for classification
• A local model for data filtering
• A hosted model for complex reasoning
• Another model for implementation
• A policy engine for provider restrictions

Once the routing decision becomes a separate component that can be optimized for privacy, latency, and cost, model routing has become infrastructure.

6. OpenAI Codex: Multi-Agent Execution Around an OpenAI-Centered Stack

OpenAI’s development of Codex in 2026 focuses strongly on agent execution, parallel work, and supervision.

The current architecture is best understood through two layers:

• the Codex app as a control surface for agent work,
• the Codex harness as the execution loop around models and tools.

These capabilities are significant, but they are not the same as automatic cross-provider model routing.

Figure 5: Example of the Codex interface in Visual Studio Code. The screenshot illustrates the user interface, not automatic cross-provider routing.

6.1 The Codex App as a Multi-Agent Control Surface

OpenAI introduced the Codex app as a command center for managing several coding agents and long-running software-engineering tasks.

Developers can use it to:

• Run work in parallel
• Maintain separate agent threads
• Review changes
• Supervise long-running tasks
• Coordinate work across projects
• Keep different tasks isolated

This is a clear example of multi-agent software development.

The primary orchestration question is:

Which agent should work on which task?

That is different from asking:

Which underlying model should process one inference?

Primary source: OpenAI, 2 February 2026 — Introducing the Codex app

6.2 The Codex Harness

OpenAI has also documented the Codex agent loop and harness.

The harness coordinates several components:

• The user request
• System and developer instructions
• The selected model
• Tool calls
• Local commands
• File modifications
• Context management
• Execution state

The model is therefore only one component of the complete Codex workflow.

A simplified view is:

Developer task
      │
      ▼
Codex harness
      │
      ├── Instructions
      ├── Model
      ├── Tools
      ├── Terminal
      ├── Files
      └── Context
      │
      ▼
Software-engineering result

Primary source:            OpenAI, 23 January 2026 — Unrolling the Codex agent loop

6.3 Model and Endpoint Flexibility

OpenAI documents that Codex CLI uses the Responses API for model inference.

The endpoint can be configured for compatible environments, including examples such as:

• OpenAI-hosted models
• Azure-hosted Responses API endpoints
• Local            gpt-oss            models through Ollama
• Local models through LM Studio

This makes the Codex harness technically flexible.

It means developers can potentially choose where the inference endpoint runs and which compatible model endpoint is used.

However, endpoint flexibility does not automatically create an intelligent model router.

A configured endpoint normally defines where Codex sends the request. A model router dynamically decides which model or provider should receive each task. These are different capabilities.

6.4 Configurable Models Are Not Automatic Routing

The distinction can be summarized as follows:

The public Codex documentation supports the first three capabilities.

I did not find official evidence that the standard Codex product automatically routes individual coding tasks between commercial models from providers such as:

• OpenAI
• Anthropic
• Google
• IBM
• Mistral

Therefore, Codex should not currently be described as equivalent to IBM Bob’s documented cross-provider model portfolio.

6.5 What Codex Does Not Publicly Document

The available public sources do not describe:

• A built-in router that selects among competing model providers
• Task-complexity-based switching between commercial vendors
• Automatic cost optimization across provider models
• Provider-level fallback routing
• Per-task evaluation of Claude, Gemini, Granite, and OpenAI models
• A complete routing audit trail

This does not mean that such mechanisms cannot exist internally or appear later.

It means they are not part of the publicly documented standard architecture I could verify.

6.6 Codex’s Architectural Strength

Codex’s current strength is different.

It combines:

• A strong coding-agent execution loop
• Repository and file operations
• Terminal access
• Parallel agents
• Long-running tasks
• Model and endpoint flexibility

This makes Codex a capable execution platform.

Its architectural focus is currently closer to:

A flexible harness for running coding agents around an OpenAI-centered model stack.

IBM Bob’s documented focus is closer to:

A managed orchestration layer that selects from a cross-provider model portfolio.

Both approaches move beyond simple code completion, but they solve different orchestration problems.

6.7 My Interpretation

In my view, Codex is especially strong when the developer wants direct control over the coding-agent execution environment.

The developer can choose:

• The task
• The agent thread
• The project
• The model configuration
• The endpoint
• The local or hosted execution setup

Bob abstracts more of the underlying model selection.

Codex currently exposes more of the execution harness, while Bob emphasizes managed model orchestration.

This creates a useful contrast:

Codex gives the developer a flexible agent runtime. Bob gives the developer a managed model and agent portfolio.

7. Claude Code: Model Selection, Subagents, and Gateway-Based Routing

Claude Code provides several building blocks for advanced model and agent orchestration.

These include:

• Manual model selection
• Specialized subagents
• Separate model configuration for delegated work
• Parallel agent execution
• Enterprise deployment through supported cloud platforms
• LLM gateway integration

These capabilities make Claude Code flexible.

However, they should not be confused with one native, fully automatic cross-provider router.

Figure 6: Example of Claude Code in Visual Studio Code. Model and subagent behavior depend on the local and organizational configuration.

7.1 Manual Model Selection

Claude Code allows the developer to select the model used for a session.

The model can be configured through the command line or through Claude Code settings.

For example, the developer can choose between Claude model variants according to priorities such as:

• Reasoning capability
• Speed
• Cost
• Task complexity

This is primarily manual or configuration-based model selection.

The developer or administrator defines the model rather than Claude Code necessarily routing every task automatically.

Primary source: Anthropic Docs — Claude Code CLI reference

7.2 Specialized Subagents

Claude Code can delegate work to specialized subagents.

A subagent can be configured with its own:

• System prompt
• Role
• Tool permissions
• Context
• Model
• Execution instructions

This allows one Claude Code workflow to divide work between specialized roles.

For example:

• A planning subagent can analyze architecture,
• A research subagent can inspect repository context,
• An implementation subagent can modify code,
• A review subagent can validate the result.

The main session can delegate the work and receive a focused result without keeping every intermediate step in the main context.

This is multi-agent orchestration.

It does not necessarily mean that the subagents use models from different commercial providers.

7.3 Model Configuration per Agent

A subagent can use a different configured Claude model from the main session.

This creates a form of role-based model assignment.

For example:

• A more capable model may be assigned to difficult planning,
• A faster model may be assigned to routine exploration,
• Another configuration may be used for review.

This is important because it allows the workflow to optimize capability and cost at the agent-role level.

However, the model assignment is generally based on configuration.

That differs from a platform-level router that independently evaluates every task and dynamically selects from a portfolio of providers.

7.4 Enterprise Hosting Is Not Cross-Provider Model Routing

Claude Code can be used through different supported hosting and authentication paths, including:

• The Anthropic API
• Amazon Bedrock
• Google Vertex AI
• Enterprise proxy or gateway infrastructure

These options change:

• Where the Claude model is accessed
• How authentication is managed
• How usage is billed
• Which organizational controls apply

They do not necessarily change the underlying model family.

Running Claude through Amazon Bedrock or Google Vertex AI still means using Claude models through another hosting and governance path.

Therefore, deployment-provider choice should not be confused with model-provider diversity.

7.5 LLM Gateways

Anthropic documents integration with LLM gateway solutions.

A gateway can provide capabilities such as:

• Centralized authentication
• Usage tracking
• Budget controls
• Rate limits
• Audit logging
• Load balancing
• Fallbacks
• Model routing
• Switching providers without changing Claude Code itself

Primary source: Anthropic Docs — LLM gateway configuration

The gateway sits between Claude Code and the inference endpoint:

Claude Code
     │
     ▼
Enterprise LLM gateway
     │
     ├── Authentication
     ├── Usage tracking
     ├── Cost controls
     ├── Audit logging
     ├── Fallbacks
     └── Model or provider routing
     │
     ▼
Configured model endpoint

This makes cross-provider routing technically possible in a custom architecture.

However, the routing is then primarily implemented by the gateway configuration.

It is not necessarily a native Claude Code decision.

This distinction matters:

Claude Code can participate in a cross-provider routed environment, but the external gateway may be the component performing the routing.

Anthropic also notes that third-party gateway software is not necessarily maintained, endorsed, or audited by Anthropic. The security and correctness of that layer therefore need separate evaluation.

7.6 Native Capability Versus External Orchestration

The difference can be summarized as follows:

Claude Code provides several components needed for a multi-model workflow.

But the platform does not need to own every orchestration decision itself.

Organizations can add their own gateway and routing policies.

This gives them more control, but it also creates more implementation and governance work.

7.7 What Is Not Publicly Demonstrated

Based on the public documentation I reviewed, I did not find evidence that standard Claude Code automatically performs all of the following itself:

• Classify every coding task by complexity
• Compare Claude, Codex, Gemini, Granite, and Mistral models
• Select the best commercial provider dynamically
• Optimize provider cost for each operation
• Provide a native cross-provider routing audit trail

That does not mean such a workflow cannot be built.

It means the routing would normally require:

• Explicit model configuration
• Subagent configuration
• An external gateway
• A custom orchestration layer

7.8 Claude Code’s Architectural Strength

Claude Code’s strength is its composability.

It provides:

• A capable coding-agent loop
• Direct terminal and file interaction
• Configurable models
• Specialized subagents
• Tool permissions
• Enterprise deployment options
• Gateway compatibility

This makes Claude Code suitable as both:

• A complete coding agent
• One component inside a larger orchestration system

A precise description is:

Claude Code is a flexible Claude-centered agent environment that supports specialized subagents and can participate in externally routed multi-model architectures through configurable gateways.

7.9 Comparison with IBM Bob

IBM Bob and Claude Code place responsibility in different locations.

IBM Bob

IBM manages:

• The model portfolio
• Cross-provider selection
• Internal routing
• Integrated agent workflows

Claude Code

The developer or organization can manage:

• The selected Claude model
• Subagent roles
• Model assignment
• Hosting route
• Gateway configuration
• External routing policy

The practical trade-off is:

Bob provides more managed abstraction. Claude Code provides more composability and infrastructure-level control.

Neither approach is automatically better for every team.

The appropriate choice depends on whether the organization prefers:

• A managed orchestration platform
• Or a configurable agent and gateway architecture

8. The Community Is Already Building Multi-Vendor Workflows

Official platforms are not the only place where multi-model and multi-agent orchestration is emerging.

Developers are also assembling their own workflows from separate coding agents and tools.

A common pattern looks like this:

Figure 7: Example of a manually coordinated multi-vendor workflow. The agent roles are illustrative and are not fixed recommendations for specific products.

A developer may, for example, use:

• One agent for planning
• Another agent for implementation
• Another tool inside the IDE
• A separate agent for review

The tools can come from different providers.

Examples may include combinations of:

• Claude Code,
• OpenAI Codex,
• GitHub Copilot,
• Gemini CLI,
• IBM Bob,
• local models.

8.1 This Is an Observed Pattern, Not a Proven Best Practice

I want to be precise here.

There is no universal evidence that one named product should always perform one fixed role.

For example, I cannot state that:

• Claude Code is always the best planner
• Codex is always the best implementation agent
• Copilot is always the best reviewer
• Gemini is always the best repository analyst
• IBM Bob is always the best architect

These role assignments are usually based on:

• Personal experience
• Model behavior at a specific point in time
• Project type
• Language
• Tool integration
• Cost
• Usage limits
• Individual preference

The important pattern is not the permanent assignment of one product to one role.

The important pattern is the division of software-engineering work between specialized agents.

8.2 The Handoff Problem

When separate tools are used, context does not automatically move between them.

One agent may know:

• The repository structure
• The architecture discussion
• The rejected alternatives
• The implementation constraints
• The current task state

The next agent may know none of this.

Developers therefore need an explicit handoff mechanism.

Typical handoff artifacts include:

• Markdown files
• Specifications
• Git commits
• Issue descriptions
• Pull requests
• Architecture decision records
• Task lists
• Test reports

A handoff file can act as a shared, tool-independent contract between agents.

8.3 My Shared HANDOFF.md Pattern

In my own work, I explored a simple shared handoff file for coordinating several agentic IDEs and coding agents.

The basic idea is:

The repository contains the current task state in a format that every tool can read.

A useful handoff file can include:

• Objective
• Current status
• Completed work
• Open decisions
• Constraints
• Changed files
• Test status
• Unresolved risks
• Recommended next steps

A simplified example:

# Current Objective
Implement the repository search feature.
# Completed
- Added API endpoint
- Added basic unit tests
- Updated configuration
# Open Work
- Add error handling
- Validate access control
- Add integration test
# Constraints
- Do not change the public API
- Keep the workflow local-first
# Recommended Next Step
Review the implementation and add the missing integration test.

This approach has several advantages:

• It is independent of one vendor
• It remains inside the repository
• It can be versioned with Git
• It is readable by humans
• It is readable by different agents
• It creates a lightweight audit trail

8.4 The Handoff File Is Not Full Orchestration

A shared handoff file helps transfer state, but it does not solve every orchestration problem.

It does not automatically provide:

• Agent scheduling
• Conflict detection
• Permission management
• Cost optimization
• Model routing
• Parallel task coordination
• Rollback
• Execution monitoring

It is a coordination artifact, not a complete orchestration platform.

This distinction matters

HANDOFF.md
=
shared state and coordination

Orchestration platform
=
routing, execution, policies, monitoring, and coordination

8.5 Manual Multi-Vendor Workflows Create Operational Overhead

Combining several tools can provide flexibility, but it also introduces friction.

The developer may need to manage:

• Several subscriptions
• Several command-line tools
• Different authentication methods
• Different context formats
• Duplicated repository analysis
• Inconsistent instructions
• Repeated setup
• Conflicting changes
• Manual review of overlapping results

This means the developer becomes the orchestration layer.

The work is not only software engineering.

It also includes:

• Deciding which agent should act
• Transferring context
• Checking consistency
• Resolving conflicts
• Monitoring cost
• Verifying completion

8.6 Why Integrated Platforms Are Attractive

Platforms such as IBM Bob or GitHub Agent HQ can reduce some of this coordination work.

They can provide:

• Shared repository context
• Common execution history
• Integrated permissions
• Centralized policies
• Agent coordination
• Model selection
• Usage reporting
• Cost visibility

The platform manages more of the handoff internally.

That is the key difference between:

• Manually combining several independent tools,
• Using one integrated orchestration layer.

8.7 Why Custom Workflows Will Still Remain Relevant

Integrated platforms will not replace every custom workflow.

Developers may still prefer their own orchestration when they need:

• Local models
• Strict data sovereignty
• Provider independence
• Reproducible evaluation
• Custom routing rules
• Direct cost control
• Specialized internal tools
• Transparent execution paths

A custom workflow provides more control.

An integrated platform provides more convenience.

The architectural decision is therefore not simply:

Which agent is best?

It is:

Which coordination model provides the right balance between control, transparency, cost, and operational effort?

9. The Economic Trade-Off: Cost, Control, and a New Form of Lock-In

Multi-model and multi-agent engineering can reduce dependency on one model provider.

However, it does not remove cost, complexity, or lock-in.

It changes where they appear.

9.1 Reducing Dependency on One Model

Using several models or agents can reduce dependency on:

• One provider’s release cycle
• One pricing strategy
• One context limit
• One availability level
• One model’s strengths and weaknesses
• One product roadmap

If one model becomes unavailable, more expensive, or less suitable for a task, another model may be used instead.

This creates resilience at the model layer.

It can also allow developers to use different capabilities for different tasks, such as:

• A reasoning model for architecture
• A faster model for simple edits
• A local model for sensitive classification
• A specialized agent for review or security

However, this flexibility introduces additional operational work.

9.2 The Cost of Using Several Independent Tools

A manually assembled multi-vendor workflow may require several commercial relationships.

A developer or team may pay for combinations of:

• IBM Bob
• Claude Code
• OpenAI Codex or ChatGPT
• GitHub Copilot
• Gemini
• Direct model APIs
• Local hardware
• Cloud infrastructure

The real cost is not only the subscription price.

It can also include:

• API consumption
• Premium requests
• Rate-limit upgrades
• Local compute
• Storage
• Networking
• Duplicated repository analysis
• Context transfer
• Orchestration scripts
• Maintenance
• Evaluation
• Governance
• Developer time

This means a workflow that uses several tools may be technically flexible but economically fragmented.

9.3 The Developer Becomes the Router

When several independent coding agents are used, the developer often manages the orchestration manually.

The developer decides:

• Which tool receives the task
• Which model should be used
• How context is transferred
• When another agent should review the result
• Whether outputs conflict
• Which subscription or API budget should be consumed

This can provide direct control.

It also creates coordination overhead.

A lower model price does not necessarily produce a lower total workflow cost if the developer spends additional time managing the process.

9.4 Integrated Orchestration as a Commercial Model

An integrated platform attempts to hide much of this complexity behind one interface.

A simplified structure is:

Developer → Orchestration Platform → Managed Portfolio of Models and Agents

The platform may provide:

• One user experience
• One authentication model
• One governance layer
• Shared context
• Standardized workflows
• Central usage reporting
• Integrated cost management
• Automatic model selection

The customer pays for access to the orchestration capability rather than managing every model relationship separately.

This can reduce operational effort.

However, it also means the platform controls more of the execution path.

9.5 From Model Lock-In to Orchestration Lock-In

Figure 8: Multi-model platforms may reduce dependency on one underlying model while increasing dependency on the orchestration platform that manages models, agents, context, policies, and billing.

Traditional model lock-in means that a workflow depends heavily on one provider or model family.

A multi-model platform can reduce that dependency because the underlying models may be replaceable.

However, the stable dependency may move upward into the orchestration layer.

The customer can become dependent on:

• Routing logic
• Agent workflows
• Proprietary skills
• Repository integrations
• Governance policies
• Stored context
• Audit functions
• Billing rules
• Evaluation systems
• Platform-specific metadata

The underlying model may change without affecting the developer workflow.

That is useful.

But it also means that replacing the orchestration platform may become more difficult than replacing a single model.

9.6 Three Forms of Lock-In

It is useful to distinguish three different dependencies.

A platform can reduce one type of lock-in while increasing another.

For example:

• Cross-provider routing can reduce model lock-in
• Proprietary agent workflows can increase agent lock-in
• Centralized context and governance can increase orchestration lock-in

A Practical Example

The Gemini CLI transition shows how this works in practice.

Gemini CLI supported task-related model selection, availability-based fallback routing, and experimental local routing. The underlying Gemini model family did not disappear when access changed for the affected Gemini CLI user tiers on 18 June 2026. What changed was the orchestration layer around them.

For affected developers, the models remained available through other paths. The tool that selected, routed, and executed around those models did not. Access depended on the license type rather than on the model.

This is orchestration dependency rather than model dependency. It also shows that the orchestration layer is not automatically more stable than the models it manages. It can be replaced, rebranded, or restricted to a different customer segment.

Primary source: Google Developers Blog, 19 May 2026 —    An important update: Transitioning Gemini CLI to Antigravity CLI

The correct question is therefore not:

Does this platform remove vendor lock-in?

The better question is:

Which form of dependency does this architecture reduce, and which new dependency does it introduce?

9.7 Cost Is Becoming a Runtime Input

Another important development is that cost is moving from financial reporting into execution logic.

Previously, the simplified pattern was:

Run the model → Measure the cost afterwards

Increasingly, the pattern becomes:

Analyze the task → Estimate required capability → Select a model → Execute

Cost can influence:

• Model selection
• Fallback behavior
• Subagent configuration
• Context size
• Execution location
• Whether a local or hosted model is used

GitHub documents that Auto selection can avoid unnecessary use of more expensive reasoning models.

IBM states that Bob includes cost as one factor in model orchestration and provides consumption visibility through Bobalytics.

Google’s experimental local Gemma router is partly intended to reduce hosted-model usage for the routing decision itself.

Cost is therefore no longer only an invoice-level concern.

It becomes part of runtime engineering.

9.8 Cost Optimization Is Not Automatically Customer Optimization

A platform may optimize internal inference cost.

That does not automatically mean that the savings are fully visible to the customer.

The platform may use:

• Smaller models
• Caching
• Provider discounts
• Batch processing
• Internal hosting
• Routing policies

The user may receive:

• Lower subscription prices
• More included usage
• Better latency
• Or no direct visibility into the savings

This creates another transparency question:

Is the router optimizing for the customer’s outcome, the platform’s operating margin, or both?

Without detailed routing and billing information, this cannot always be independently evaluated.

9.9 The Architectural Trade-Off

The economic decision can be summarized as follows:

There is no universally best option.

The appropriate architecture depends on priorities such as:

• Cost
• Privacy
• Transparency
• Governance
• Provider independence
• Operational effort
• Integration depth

The central trade-off is:

More abstraction can reduce operational complexity, but it can also reduce control and increase dependency on the orchestration layer.

10. What Changes for Developers?

As model and agent selection moves into the platform, the developer’s responsibility changes.

This is not a strict industry timeline. It is a simplified progression that reflects how AI-assisted development workflows are evolving.

Figure 9: As platforms take over model and agent selection, the developer’s role shifts toward governing execution and validating evidence.

10.1 Earlier: The Developer Selected and Operated the Model

In an earlier workflow, the developer typically:

• Wrote the prompt
• Selected the model
• Interpreted the response
• Transferred the result into the development environment
• Decided whether another model should be consulted

The developer remained responsible for most orchestration decisions.

10.2 Next: The Developer Coordinated Several Tools

As more coding agents became available, many developers began combining them manually.

The developer then had to:

• Choose the model or agent
• Divide the task
• Transfer context
• Compare results
• Resolve conflicts
• Review the implementation
• Manage several subscriptions or usage limits

In this phase, the developer effectively became the orchestration layer.

10.3 Now: The Platform Can Select Models and Agents

In automated workflows, the developer describes the objective and constraints, while the platform may:

• Select the model
• Delegate work to agents or subagents
• Manage context
• Execute tools
• Track usage
• Apply governance policies
• Coordinate review steps

The developer’s role moves from operating every model directly toward supervising the software-engineering process.

A simplified progression is:

Prompt operator → Tool coordinator → Workflow supervisor

This does not mean the developer becomes less important.

It means the required skills change.

10.4 Model Knowledge Still Matters

Automatic routing does not make model knowledge irrelevant.

Developers may still need manual control for:

• Sensitive code
• Regulated environments
• Reproducible evaluations
• Local execution
• Difficult architectural decisions
• Performance-sensitive workloads
• Cost-controlled pipelines
• Incidents and debugging
• Provider-specific limitations

A routing system can make a reasonable default decision.

It cannot remove the need for technical judgment.

10.5 The New Core Skills

As more orchestration becomes automated, developers need to focus more on:

• Defining the objective
• Stating constraints
• Supplying relevant context
• Setting permissions
• Describing acceptance criteria
• Validating tests
• Reviewing changes
• Checking security
• Understanding risk
• Evaluating cost
• Inspecting the execution trace

These skills are less about asking a model for code and more about governing a software-engineering workflow.

10.6 Review Becomes More Important, Not Less

More automation increases the amount of work a system can perform.

It also increases the potential impact of a wrong decision.

An agent may:

• Modify several files
• Execute terminal commands
• Introduce dependencies
• Change infrastructure
• Update tests
• Create pull requests

The developer must therefore review not only the final code, but also:

• The plan
• The assumptions
• The tools used
• The files changed
• The test evidence
• The unresolved risks

The more autonomous the workflow becomes, the more important evidence-based review becomes.

10.7 Developers Need Visibility Into the Orchestration Layer

When the platform selects models and agents, developers need answers to new questions:

• Which model was used?
• Which agent performed the change?
• Which tools were executed?
• Which files were read or modified?
• Which external provider received context?
• What did the operation cost?
• Which policies were applied?
• Why was this route selected?
• Was the result reviewed by another agent?

Without this visibility, the developer is asked to accept the result without understanding the execution path.

That may be acceptable for low-risk tasks.

It is much more difficult for production, enterprise, or regulated work.

10.8 The Developer Becomes the Governor of the Workflow

The long-term role is not simply “prompt engineer.”

It is closer to:

A developer who defines the task, governs the execution, and validates the evidence.

The platform may select the model.

The platform may coordinate the agents.

The developer remains accountable for the software outcome.

11. Is IBM Bob Architecturally Ahead?

The answer depends on the capability being evaluated.

IBM Bob is not the only platform with:

• Multiple models
• Automatic model selection
• Subagents
• Parallel execution
• Usage reporting

• GitHub Copilot has documented task-aware model routing and repository-native access to coding agents from several providers.
• Gemini CLI provides routing within Google’s model ecosystem and supports experimental local routing decisions. See the product status update in Section 5.
• Claude Code provides configurable models, specialized subagents, and gateway integration.
• OpenAI Codex provides a flexible coding-agent harness and parallel agent execution.

Therefore, a general statement such as:

IBM Bob is ahead of every other AI coding platform would be too broad and not supportable.

A better assessment is to compare the platforms against explicit architectural criteria.

11.1 Cross-Provider Model Orchestration

IBM publicly describes Bob as using a managed portfolio that includes:

• IBM Granite
• Anthropic Claude
• Mistral models
• Specialized models

The routing is presented as an internal platform capability rather than a workflow the developer must assemble.

Against this specific criterion, Bob has a strong and clearly documented architectural position.

IBM Bob is one of the clearest examples of built-in cross-provider model orchestration in an AI software-development platform.

This does not prove that Bob always selects the objectively best model.

It means that cross-provider selection is part of the documented product design.

11.2 Automatic Abstraction of Model Choice

Bob reduces the need for developers to manage the underlying model portfolio directly. The user interacts with Bob, while IBM can change or optimize the models behind the interface.

This can provide:

• Lower decision overhead
• A stable user experience
• Easier adoption of new models
• Centralized governance
• Integrated usage management

Against this criterion, Bob may be ahead of tools that still require the developer or administrator to configure most model decisions manually.

However, abstraction also reduces direct visibility into the execution path.

11.3 Transparency

Public IBM information does not clearly show that Bob users receive a complete per-operation record of:

• The selected model
• The provider
• The routing reason
• The cost of the individual call
• Validation by another model
• Fallback behavior

GitHub documents clearer post-routing model visibility in supported interfaces.

Against this criterion, Bob cannot currently be described as ahead. GitHub documents both the selected model per response and the name and general inputs of its routing component. IBM documents action-level traceability through BobShell and cost visibility through Bobalytics, but I did not find an equivalent public description of the routing component itself.

A platform can have sophisticated routing while still exposing limited routing evidence to the user.

11.4 Repository and Collaboration Integration

GitHub has a structural advantage because its orchestration capabilities are connected directly to:

• Repositories
• Issues
• Branches
• Pull requests
• Reviews
• Permissions
• Software-delivery history

Agent HQ can place different agents inside the repository workflow.

Against this criterion, GitHub has a particularly strong position.

IBM Bob approaches the problem more from:

• Enterprise software engineering
• Modernization
• Governance
• Managed model orchestration
• Specialized development workflows

The platforms start from different system boundaries.

11.5 User Control and Extensibility

Claude Code and Codex provide substantial control over areas such as:

• Agent configuration
• Model selection
• Subagent roles
• Endpoints
• Gateways
• Local or hosted execution

A managed platform such as Bob may expose less of this infrastructure-level control because more decisions are handled internally.

Against this criterion, Bob is not automatically ahead.

The result depends on whether the user values:

• Managed abstraction
• Or direct configuration

11.6 Governance and Enterprise Operation

IBM’s enterprise position may provide an advantage in areas such as:

• Centralized governance
• Usage visibility
• Modernization workflows
• Policy control
• Model portfolio management
• Enterprise support

However, governance quality cannot be inferred only from a product announcement.

It needs to be evaluated through:

• Available controls
• Audit detail
• Deployment options
• Data-processing terms
• Administrative visibility
• Operational evidence

The current documentation shows a strong direction, but not every implementation detail.

11.7 Cost Optimization

IBM explicitly identifies cost as one routing factor and provides consumption visibility through Bobalytics.

This suggests that cost optimization is part of Bob’s architecture.

However, the public sources do not expose enough detail to determine:

• The exact savings
• The cost per routed task
• Whether savings are passed to the user
• How quality is balanced against operating cost

Therefore, cost-aware routing is a documented capability, but superior customer economics are not independently proven.

11.8 Evaluation Summary

This table is an architectural interpretation of public documentation.

It is not a benchmark of coding quality.

11.9 My Answer

My answer is therefore more specific than simply saying that Bob is ahead.

IBM Bob appears architecturally ahead in treating managed cross-provider model orchestration as a central product capability.

At the same time:

• GitHub has a stronger repository-native position
• GitHub documents more selected-model visibility
• Claude Code offers strong composability
• Codex offers a flexible agent execution environment
• Gemini demonstrates interesting local and within-family routing patterns

The competition is not settled because the platforms are optimizing for different control points.

IBM Bob’s main advantage is not ownership of one dominant model.

Its potential advantage is ownership of the orchestration layer that can continuously change the model portfolio behind the developer experience.

12. Where I Think This Goes Next

This section is my forecast.

It is based on the product direction described in the previous sections, but it does not describe confirmed future functionality.

12.1 The Model Picker Becomes a Secondary Control

Manual model selection will probably remain available for advanced users.

However, automatic selection is likely to become the default for many normal software-engineering tasks.

The model picker may become an expert control for situations such as:

• Reproducible evaluation
• Regulated development
• Local execution
• Model-specific testing
• Cost-sensitive workflows
• Debugging routing behavior

For many routine tasks, the platform will choose the model automatically.

The user will select the platform, policy, or workflow rather than the individual model.

12.2 Routing Becomes Risk-Aware

Current routing documentation often emphasizes:

• Task complexity
• Availability
• Latency
• Reliability
• Cost

Future routing systems will likely also consider risk.

Possible inputs include:

• Repository sensitivity
• Production impact
• Security classification
• Regulatory requirements
• Change size
• Data access
• Test coverage
• Rollback complexity

A CSS adjustment and a production database migration should not necessarily use the same model, agent, permissions, or review process.

The routing decision may therefore include both:

• Capability selection
• Risk governance

12.3 Local Models Handle Sensitive Preprocessing

Local models may perform early-stage tasks such as:

• Request classification
• Repository summarization
• Secret detection
• Data filtering
• Policy checks
• Routing decisions

Only the necessary context may then be sent to a hosted model.

This could reduce:

• External data exposure
• Hosted inference cost
• Unnecessary context transfer

Google’s experimental local Gemma routing is one early example of separating the routing component from the hosted task model.

However, local preprocessing does not automatically make the complete workflow private.

The final privacy outcome still depends on:

• What data leaves the environment
• Which provider receives it
• Retention
• Logging
• Tool execution
• Telemetry

12.4 Agent Roles Become Standard Platform Capabilities

Software-engineering agent roles are becoming recognizable.

Examples include:

• Planner
• Repository analyst
• Implementer
• Tester
• Reviewer
• Security analyst
• Modernization specialist

Today, many developers define these roles manually through:

• Prompts
• Subagent files
• Skills
• Custom instructions
• Workflow scripts

In the future, these roles may become standardized capabilities inside development platforms.

The important competition may then shift from:

Which model is best?

to:

Which platform provides the most reliable software-engineering roles and coordination?

12.5 Auditability Becomes a Competitive Feature

When the developer no longer selects every model or agent directly, the orchestration platform needs to explain the execution path.

Developers and organizations will increasingly ask:

• Which model was used?
• Which provider processed the context?
• Which agent performed the change?
• Which tools were executed?
• Which files were accessed?
• Why was this route selected?
• What did the operation cost?
• Which policy allowed it?
• Was the result reviewed by another model or agent?

GitHub already exposes the selected model in supported Auto workflows.

IBM provides broader usage and cost visibility through Bobalytics.

The next step is likely to be a more complete model- and agent-level audit trail.

12.6 Evaluation Becomes Part of Routing

Future routers may not rely only on fixed rules.

They may continuously evaluate results based on evidence such as:

• Test success
• Failed builds
• Review findings
• Security issues
• Rollback frequency
• Code quality
• Task completion
• Cost per successful outcome

A platform could learn that:

• One model performs better for a specific repository
• Another model is more reliable for a language
• One agent produces smaller changes
• Another agent performs better in debugging
• One combination provides better results per cost unit

The router could then update its decisions over time.

At that point, routing becomes a continuous evaluation system.

12.7 The Orchestration Layer Becomes the Stable Product

Models will continue to change quickly.

A platform may replace:

• One model version
• One provider
• One specialized capability
• One agent implementation

The developer workflow may remain stable.

This suggests a broader product shift:

The model becomes replaceable infrastructure, while the orchestration layer becomes the long-term developer relationship.

That does not mean the model becomes unimportant.

It means that the model may no longer be the main product boundary visible to the developer.

13. My View

In my view, the most important development in AI-assisted software engineering is not that one coding model has won.

It is that the individual model is becoming less visible to the developer.

The platform increasingly decides:

• Which model should process the task
• Which agent should perform the work
• Which tools should be used
• How context should be managed
• How cost and policy should influence execution
• How the result should be reviewed

This changes the product boundary.

The model remains technically important, but the orchestration layer becomes the stable interface between the developer and a changing portfolio of models and agents.

13.1 Why IBM Bob Is Interesting to Me

IBM Bob is interesting because IBM does not need to position one Granite model as the best model for every software-engineering task.

Instead, IBM can combine:

• Granite models
• External frontier models
• Open or open-weight models
• Specialized models
• Agents and subagents
• Enterprise governance

The model portfolio can evolve while the developer continues to work through the same platform.

That is a meaningful architectural advantage.

However, it is not automatically a complete competitive advantage.

A managed orchestration platform must also demonstrate:

• Routing quality
• Model-level transparency
• Provider visibility
• Cost transparency
• Governance
• Auditability
• Reliable engineering outcomes

13.2 The Trade-Off

The central trade-off is:

Convenience and optimization versus control and transparency.

A platform such as Bob can reduce the need to build and maintain a custom workflow across Claude Code, Codex, local models, and other tools.

At the same time, the developer delegates more decisions to an internal routing and orchestration layer.

That requires trust.

The more decisions the platform makes, the more evidence it should provide about:

• What was selected
• Why it was selected
• Where it executed
• What data was processed
• What the operation cost
• How the result was validated

13.3 My Conclusion

For me, the question is no longer only:

Which coding model should I use?

The more important question is:

Which orchestration layer do I want to work inside, and how much control, evidence, and transparency does it provide?

The competition in AI developer tooling is therefore no longer only about who builds the strongest model.

It is about who builds the most effective, adaptable, transparent, and trustworthy orchestration platform.

14. Current Capability Comparison

The following table compares orchestration capabilities, not coding quality.

The categories describe different technical dimensions:

• Cross-provider portfolio: the platform can use models or agents from more than one model provider.
• Automatic model routing: the platform selects a model without requiring a manual choice for every task.
• Selected-model visibility: the user can see which model produced a response.
• Multi-agent execution: several agents or subagents can perform separate roles or tasks.
• External routing support: the platform can participate in routing controlled by a gateway, endpoint, or custom infrastructure.
• Local routing or inference: documented support exists for local routing decisions or local model execution.

This comparison shows that the platforms are converging, but they are not converging on exactly the same architecture.

• IBM Bob emphasizes managed cross-provider orchestration, enterprise workflows, and abstraction of model choice.
• GitHub Copilot combines automatic model selection with repository-native access to competing coding agents.
• Gemini CLI demonstrates task-based, fallback, and experimental local routing primarily within Google’s model ecosystem.
• Claude Code emphasizes configurable models, subagents, and gateway-based extensibility.
• OpenAI Codex emphasizes a flexible coding-agent harness, parallel execution, and configurable inference endpoints.

The table is a technical interpretation of publicly available documentation.

It is not:

• An independent benchmark
• A model-quality ranking
• A pricing comparison
• A claim that one platform is best for every developer

15. Sources and Evidence

This article separates three types of evidence:

1. Current product evidence from 2026
   Used to describe the present capabilities of IBM Bob, GitHub Copilot, Gemini CLI, Claude Code, and OpenAI Codex.
2. Historical sources published before 2026
   Used only to explain how AI coding assistants developed over time. They are not used as primary evidence for the current 2026 product state.
3. Personal observations and implementation experience
   Used for my interpretation of community workflows, shared handoff patterns, and the practical use of several coding agents.

Product capabilities can change quickly. The links below reflect the public documentation reviewed on 30 July 2026.

15.1 IBM Bob — Current 2026 Product Evidence

• IBM Newsroom, 28 April 2026 — Introducing IBM Bob
  Used for IBM’s description of multi-model orchestration, model families, routing criteria, BobShell action-level traceability, pass-through pricing, and the use of smaller or more capable models for different tasks.
• IBM Newsroom, 9 July 2026 — IBM advances enterprise AI software development with multi-agent capabilities
  Used for Bob subagents, parallel model-native tool calling, modernization workflows, and Bobalytics.
• IBM Announcement, 9 July 2026 — IBM Bob expands with premium packages, new architecture, and greater enterprise control
  Used as additional evidence for Bob’s architecture, enterprise controls, packages, usage visibility, and governance direction.

15.2 GitHub Copilot — Current 2026 Product Evidence

• GitHub Docs — Auto model selection
  Used for task-aware routing, model availability, model health, cost efficiency, cache boundaries, and selected-model visibility.
• GitHub Docs — Supported AI models in GitHub Copilot
  Used to verify the model portfolio available through GitHub Copilot.
• GitHub Blog, 4 February 2026 — Pick your agent: Use Claude and Codex on Agent HQ
  Used for Claude and Codex as coding agents inside GitHub Agent HQ.
• GitHub Changelog, 17 April 2026 — Copilot CLI supports Auto model selection
  Used for the introduction of Auto model selection in Copilot CLI.
• GitHub Changelog, 20 May 2026 — Auto model selection routes based on the task in VS Code
  Used for task-based model routing and selected-model visibility in Visual Studio Code.
• GitHub Changelog, 24 June 2026 — Changes to model selection for Free and Student plans
  Used for Auto becoming the only model-selection experience for selected plans.
• GitHub Changelog, 1 July 2026 — Enterprises can default to Auto model selection
  Used for organization-level Auto defaults.
• GitHub Engineering, June 2026 — Getting more from each token: How Copilot improves context handling and model routing
  Used for the name of GitHub’s routing component and its documented routing inputs, quality filtering, and model-selection process.

15.3 Google Gemini CLI — Current 2026 Product Evidence

• Google Developers Blog, 11 March 2026 — Plan Mode in Gemini CLI
  Used for Plan Mode and the use of stronger reasoning models for planning and architectural tasks.
• Gemini CLI Documentation — Model selection
  Used for Gemini CLI model-selection options and Auto behavior.
• Gemini CLI Documentation — Model routing
  Used for availability monitoring, fallback routing, internal routing behavior, and experimental local Gemma routing.
• Google Developers Blog, 19 May 2026 — An important update: Transitioning Gemini CLI to Antigravity CLI
  Used for the change in Gemini CLI availability for affected individual-user tiers and the continued access paths through enterprise licenses and paid API usage.

15.4 OpenAI Codex — Current 2026 Product Evidence

• OpenAI, 23 January 2026 — Unrolling the Codex agent loop
  Used for the Codex harness, Responses API integration, tools, context management, and configurable endpoints.
• OpenAI, 2 February 2026 — Introducing the Codex app
  Used for parallel agents, long-running tasks, and the Codex app as a multi-agent control surface.
• OpenAI, 4 February 2026 — Unlocking the Codex harness
  Used as additional technical background on the Codex execution environment and harness extensibility.

15.5 Claude Code — Current Product Documentation

• Anthropic Docs — Claude Code model configuration
  Used for model selection and configuration within Claude Code.
• Anthropic Docs — Claude Code subagents
  Used for specialized subagents, separate instructions, tools, context, and model configuration.
• Anthropic Docs — Claude Code LLM gateway configuration
  Used for centralized authentication, cost controls, audit logging, fallback behavior, and gateway-based model or provider routing.
• Anthropic Docs — Claude Code settings
  Used for administrator and workspace configuration of Claude Code behavior.

15.6 My Previous Work and Practical Context

• Coordinating Multiple Agentic IDEs with a Shared Handoff File
  Used for my practical experience with HANDOFF.md as a tool-independent coordination artifact.
• AI Coding Assistants, Agentic IDEs, and Privacy: From Chatbots to Operational Systems
  Used as background for the relationship between model routing, cloud processing, local execution, data sovereignty, and transparency.

15.7 Historical Sources

Sources published before 2026 are used only where the article describes the historical development from:

• One primary coding model
• To manual model selection
• To model and agent orchestration

They are not used as primary evidence for the current 2026 product capabilities.

15.8 Evidence Limitations

The public documentation does not expose every internal implementation detail.

In particular, the sources do not provide a complete and independently verifiable account of:

• Every routing rule
• Every active model
• Every provider endpoint
• Model-level internal cost
• All fallback behavior
• All validation steps
• The exact reason for every routing decision.

Where the article goes beyond documented product facts, the text is explicitly framed as:

• My observation
• My interpretation
• Or my forecast

Note:  This post reflects my own ideas, implementation work, and experience. AI was used as a writing, discussion, research, and structured-thinking aid to help organize and clarify the arguments, but not to define the conclusions.

#MultiModelEngineering, #AICoding, #AICodingAssistants, #AgenticAI, #AgenticIDE, #ModelRouting, #AIAgents, #MultiAgentSystems, #AIOrchestration, #SoftwareEngineering, #DeveloperTools, #IBMBob, #GitHubCopilot, #ClaudeCode, #OpenAICodex, #GeminiCLI, #EnterpriseAI, #AIEngineering, #LLMOrchestration, #FutureOfSoftwareDevelopment