GitHub Copilot CLI: Model Selection Routing Issues Explained

Introduction: Is Your GitHub Copilot CLI Ignoring Your Model Choice?

Hey guys, ever tried to explicitly tell your GitHub Copilot CLI which amazing AI model you want to use, only to suspect it's secretly doing its own thing? You're not alone! Today, we're diving deep into a pretty significant bug that's been spotted in the GitHub Copilot CLI, specifically concerning its model selection routing. Imagine you're at a restaurant, you order the "Spicy Haiku Shrimp," but the chef keeps sending out the "Rich Sonnet Lobster." Delicious, maybe, but not what you asked for, right? That's precisely what seems to be happening with our beloved Copilot CLI. Users are finding that even when they specify a particular AI model using the --model flag – whether it's the speedy claude-haiku-4.5, the powerful claude-sonnet-4.5, or even the advanced gpt-5 – the CLI might actually be routing their requests to completely different, default models behind the scenes. This isn't just a minor glitch; it's a core functionality breakdown that impacts everything from performance expectations to accessing specific AI capabilities. Our investigation, stemming from observations by a diligent user, ellertsmari, on December 6, 2025, with CLI Version 0.0.358 on a Linux environment, uncovered a clear discrepancy. The CLI advertises multiple model options, giving us the impression of choice and control, but our tests strongly suggest that these selections are often ignored. For instance, many Claude model selections seem to consistently default to Claude 3.5 Sonnet, while gpt-5 requests appear to be routed to gpt-4.1. This means the backend isn't truly implementing the model-specific routing it promises, leading to a frustrating experience where your specified AI assistant isn't actually the one answering your queries. This article will walk you through how we discovered this model routing bug, what it means for your workflow, and what steps could be taken to fix this crucial issue, ensuring that when you ask for a specific AI, that's exactly what you get. We're talking about transparency, control, and getting the most out of your premium AI tools, so stick around as we unravel this mystery!

Deep Dive: How We Uncovered the GitHub Copilot CLI Model Routing Bug

So, you might be asking, "How in the world did someone figure out that the GitHub Copilot CLI wasn't using the right AI models?" Well, folks, it wasn't magic, but rather a bit of good old-fashioned detective work! Our investigation into the model routing bug started with a suspicion: why were different Claude models giving eerily similar responses? This kind of anomaly often points to a deeper issue, and in the world of software, it usually means something isn't routing correctly. To get to the bottom of this, we leveraged a combination of standard developer tools and creative testing, meticulously gathering evidence to confirm our hypothesis that the ---model flag wasn't behaving as advertised. The goal was simple: try to select various AI models via the CLI and then ask the AI itself which model it was. If the AI consistently reported a different model than what was selected, or if multiple selections reported the same model, we'd have our smoking gun. This systematic approach allowed us to move beyond anecdotal observations and build a concrete case, highlighting a critical flaw in the Copilot CLI's interaction with its backend AI services. Understanding the journey of a request – from your command line, through the CLI, to the GitHub Copilot API, and finally to the underlying LLM – was paramount. We carefully monitored network traffic, analyzed system logs, and directly interrogated the AI to get its self-reported identity. This wasn't just about pointing out a problem; it was about providing robust, verifiable evidence that could help the GitHub Copilot team pinpoint and resolve the discrepancy. It's all about ensuring that when you choose an AI model for your coding tasks, you're actually getting the specific capabilities and performance profile you're expecting, and not just a default option. This methodology is crucial for maintaining trust and ensuring the reliability of powerful developer tools like the GitHub Copilot CLI.

The Tools of the Trade: Our Digital Detective Kit

To conduct this thorough investigation, we relied on a few key tools. First off, we naturally used the GitHub Copilot CLI itself (version 0.0.358), which was the subject of our scrutiny. Then, to peek behind the curtain and understand what was happening at the network level, we employed curl. This command-line tool is indispensable for making HTTP requests, allowing us to interact directly with the GitHub Copilot API endpoint and observe how parameters, especially our chosen model, were being handled. Beyond that, we engaged in detailed process monitoring and log analysis, which basically means we kept a close eye on what the CLI was doing internally and sifted through its log files for any clues about its operational decisions, like which model it thought it was using. Finally, and perhaps most ingeniously, we used direct model identity verification by simply asking the LLMs themselves, "What model are you?" This direct approach cut through any potential logging or routing obfuscation by getting the answer straight from the horse's mouth, so to speak. These tools, working in tandem, painted a clear picture of the underlying model routing bug.

Cracking the Code: The API Endpoint Uncovered

During our deep dive, one crucial piece of information emerged: the specific API endpoint that the GitHub Copilot CLI uses to communicate with the backend AI services. This endpoint is like the central nervous system for all model requests. We found it to be https://api.individual.githubcopilot.com/chat/completions. This URL is where your CLI sends all your queries, along with any parameters you specify, such as the --model flag. It operates using a POST method, which is standard for sending data to a server, and requires authentication via a Bearer token, which is linked to your GitHub credentials. Understanding this specific endpoint was absolutely vital because it allowed us to hypothesize where the breakdown might be occurring. Is the CLI sending the wrong information to this endpoint, or is the endpoint itself failing to properly interpret and route the model choice? Identifying this communication channel was the first big step in understanding the flow, or rather, the misdirection of information regarding AI model selection.

The Glaring Issue: Model Identity Mismatch in GitHub Copilot CLI

Alright, guys, here's where the rubber meets the road and we see the undeniable proof of the model routing bug. Our core finding, and frankly, the most alarming, is a significant model identity mismatch. This isn't just a minor hiccup; it clearly demonstrates that the GitHub Copilot CLI isn't properly routing requests to the AI models you select. We put various CLI model options to the test, using a very simple, yet effective, prompt: "What model are you? Answer with only the model name, nothing else." This direct approach bypasses any assumptions and gets a self-reported identity from the Large Language Model (LLM) itself. What we found was eye-opening and confirms that the model selection parameter is consistently being overlooked or misinterpreted by the backend system. Imagine you're trying to use a specific, high-performance Claude model for a complex coding task, expecting its unique capabilities, but instead, you're silently routed to a different, potentially less optimized model. This scenario not only leads to unexpected results but also undermines the very purpose of having a model selection feature. Users pick models based on specific criteria like speed, cost, or a particular strength (e.g., Haiku for quick drafts, Sonnet for detailed analysis). When the actual model doesn't match the selected one, all those expectations are shattered. It's like buying a specific tool for a job, only to find a different, less suitable tool in the box. This discrepancy means users aren't getting the AI capabilities they're paying for or expecting, leading to wasted time, potentially subpar output, and a general erosion of trust in the tool's advertised features. The backend simply isn't honoring the --model flag, which is a fundamental flaw in the Copilot CLI's routing logic. This isn't just about technical correctness; it's about delivering on the promise of a powerful, customizable AI assistant.

The Proof is in the Pudding: Test Results Unveiled

To solidify our claims about the GitHub Copilot CLI model routing bug, we compiled a clear table showcasing the results of our direct queries. This table graphically illustrates the discrepancy between what users think they're selecting and what the AI models are actually reporting. Let's break down these findings, guys, because they truly highlight the core of the problem:

CLI Flag	Advertised Name	Actual Model Response	Usage Logged As
--model claude-sonnet-4.5	Claude Sonnet 4.5	claude-3-5-sonnet-20241022	claude-sonnet-4.5
--model claude-haiku-4.5	Claude Haiku 4.5	Claude 3.5 Sonnet	claude-haiku-4.5
--model claude-sonnet-4	Claude Sonnet 4	Claude 3.5 Sonnet	claude-sonnet-4
--model gpt-5	GPT-5	gpt-4.1	gpt-5

What's immediately striking here is how consistently the "Actual Model Response" differs from the "Advertised Name." When we asked for claude-haiku-4.5 or claude-sonnet-4, we received responses indicating Claude 3.5 Sonnet. This is a clear indicator that the request isn't being routed to the specific Claude versions or tiers. Similarly, if you were excited to try out gpt-5, our tests showed the system defaulting to gpt-4.1. The "Usage Logged As" column is also quite interesting; it shows that the CLI internally records your chosen model, but this internal logging doesn't translate to correct backend routing. This means the CLI client thinks it's doing its job, but the server-side implementation for model selection seems to be overriding or ignoring that preference. It's a classic case of client-side expectations not matching server-side reality, confirming a significant model routing bug within the GitHub Copilot CLI. This data is crucial for anyone trying to understand why their AI outputs might not be aligning with their chosen model's expected behavior.

The Core Problem: GitHub Copilot CLI's Model Routing Failure

Alright, let's get down to brass tacks, folks, because this is the heart of the GitHub Copilot CLI model routing bug. The central issue isn't just a misidentification; it's a fundamental failure in the system's ability to route your requests to the specific AI model you’ve chosen. Despite the CLI accepting your selection of various models through the --model flag, it consistently fails to route to them. Instead of honoring your explicit choice, the backend appears to completely ignore the model parameter you've provided and defaults to a predefined set of models. This is a critical design flaw because the entire purpose of offering different AI models is to allow users to leverage their unique strengths, speeds, and cost efficiencies. When this routing mechanism breaks down, the feature becomes purely cosmetic, offering an illusion of control rather than actual functionality. Here’s a simplified look at what’s actually happening versus what should be happening:

User Selects           Actual Route
────────────────────   ──────────────────────────────────
claude-sonnet-4.5   →  Claude 3.5 Sonnet (claude-3-5-sonnet-20241022)
claude-haiku-4.5    →  Claude 3.5 Sonnet (claude-3-5-sonnet-20241022)
claude-sonnet-4     →  Claude 3.5 Sonnet (claude-3-5-sonnet-20241022)
gpt-5               →  GPT-4.1

This diagram makes it abundantly clear: your specific model selection isn't reaching its intended destination. Whether you're aiming for the swiftness of Haiku or the advanced reasoning of GPT-5, the system is throwing you a curveball and serving up a different AI model. This implies several critical problems: the model selection parameter isn't correctly translated or forwarded to the various backend AI services; all Claude options, regardless of their advertised version, are currently yielding identical responses, stripping away the nuanced choice users expect; and most importantly, users are simply unable to access the specific, powerful models they have explicitly requested. This isn't just an inconvenience; it's a core feature not working as intended, and it’s vital for the GitHub Copilot CLI to address this to ensure users truly benefit from the diverse AI models it promises to offer.

What the Logs Revealed: Unmasking the Routing Defaults

To further confirm our suspicions about the GitHub Copilot CLI model routing bug, we delved into the deep, dark world of system logs. Logs are like the flight recorder of a software application; they document everything that happens behind the scenes. In our investigation, we zeroed in on the Copilot CLI's session logs, specifically from ~/.copilot/logs/session-1dd74f7a-1c01-478c-8484-fb9005ee994f.log. And what we found was pretty telling, guys. The logs consistently showed an [INFO] message stating: "Using default model: claude-sonnet-4.5". This line appeared regardless of which Claude model we tried to select using the --model flag! This is a powerful piece of evidence because it directly contradicts the idea that your selection is being honored. It signals that somewhere early in the request pipeline, before it even hits the deeper routing logic, a default is being imposed. Furthermore, the logs consistently indicated that all requests were routing to the exact same API endpoint: https://api.individual.githubcopilot.com/chat/completions. This uniformity in the API endpoint usage, combined with the "Using default model" message, strongly suggests that the backend is either not receiving the specific model parameter from the CLI, or it's actively ignoring it and processing all requests through a single, undifferentiated path. This means that while the GitHub Copilot CLI client might be preparing a request for claude-haiku-4.5, the server-side logic is defaulting to claude-sonnet-4.5 or Claude 3.5 Sonnet for all Claude-related queries and gpt-4.1 for GPT-related ones. This log evidence is crucial because it offers an internal confirmation of the external behavior we observed, painting a clearer picture of where the model routing bug lies within the GitHub Copilot CLI's infrastructure. It's a strong indicator that the system isn't just misidentifying models; it's explicitly defaulting them at an early stage.

Real-World Tests: See the GitHub Copilot CLI Model Routing Bug for Yourself

Now, let's walk through the actual test commands and their outputs, which vividly illustrate the GitHub Copilot CLI model routing bug in action. These aren't just theoretical observations; these are direct interactions with the CLI that show a clear discrepancy between what's requested and what's delivered. We executed a series of commands, each explicitly calling for a different AI model using the --model flag, and for each, we asked the AI the simplest question possible: "What model are you?" The consistency of the unexpected answers across these tests leaves little room for doubt about the routing failure. It’s essential for developers to see this evidence firsthand, as it affects their daily interactions with the tool. Understanding these outputs helps confirm that the issue isn't user error but a systemic problem within the Copilot CLI's backend integration. It also highlights how users might be unknowingly using a different AI than intended, impacting their workflow and the quality of their AI-generated suggestions.

Test 1: Claude Sonnet 4.5 – The Expected and the Actual

When we specifically asked the GitHub Copilot CLI to use claude-sonnet-4.5, expecting the latest iteration of the Sonnet series, here's what happened:

$ echo "What model are you? Answer with only the model name, nothing else." | \
  copilot --model claude-sonnet-4.5

claude-3-5-sonnet-20241022

Usage by model:
    claude-sonnet-4.5    13.6k input, 15 output, 0 cache read, 0 cache write (Est. 1 Premium request)

Notice, guys, the direct response from the model: claude-3-5-sonnet-20241022. While this is a Sonnet model, it's not the claude-sonnet-4.5 that was explicitly requested. It’s a specific version of Claude 3.5 Sonnet. This immediately tells us that even when targeting a Sonnet variant, the routing isn't precise. The CLI logs the usage as claude-sonnet-4.5, indicating an internal record, but the actual AI model responding is subtly different. This small but significant discrepancy sets the stage for the broader model routing bug.

Test 2: Claude Haiku 4.5 – Where is the Speed?

Next up, we wanted to see if the faster, more agile claude-haiku-4.5 AI model was being correctly selected. Haiku models are often chosen for quick, less complex tasks where speed is paramount.

$ echo "What model are you? Answer with only the model name, nothing else." | \
  copilot --model claude-haiku-4.5

Claude 3.5 Sonnet

Usage by model:
    claude-haiku-4.5     13.5k input, 12 output, 0 cache read, 0 cache write (Est. 0.33 Premium requests)

And boom! The response was clear: Claude 3.5 Sonnet. This is a major red flag. We asked for Haiku, a model known for its efficiency and speed, but received a Sonnet model, which, while powerful, has a different performance profile. This test strongly underscores the model routing bug because it shows a complete failure to differentiate between two distinct AI models within the Claude family. Users expecting Haiku's quick turnarounds would instead be getting Sonnet's more deliberate, resource-intensive processing.

Test 3: Claude Sonnet 4 – The Older Brother's Fate

What about the slightly older, but still capable, claude-sonnet-4? Surely, if there's specific routing, this model should be distinguishable.

$ echo "What model are you? Answer with only the model name, nothing else." | \
  copilot --model claude-sonnet-4

Claude 3.5 Sonnet

Usage by model:
    claude-sonnet-4      13.4k input, 12 output, 0 cache read, 0 cache write (Est. 1 Premium request)

Again, the same response: Claude 3.5 Sonnet. This result, in conjunction with Test 2, reveals a disturbing pattern. All attempts to select different Claude AI models lead back to Claude 3.5 Sonnet. This isn't a fluke; it's a consistent symptom of the underlying model routing bug within the GitHub Copilot CLI. It clearly shows that the distinct Claude model choices offered in the CLI are effectively non-functional.

Test 4: GPT-5 – The Next-Gen That Isn't Quite There

Finally, for those eager to tap into the cutting-edge capabilities of gpt-5, our test revealed a similar story of misdirection:

$ echo "What model are you? Answer with only the model name, nothing else." | \
  copilot --model gpt-5

gpt-4.1

Usage by model:
    gpt-5                10.0k input, 80 output, 0 cache read, 0 cache write (Est. 1 Premium request)

Even when explicitly requesting gpt-5, the AI model that responded identified itself as gpt-4.1. This is another clear instance of the model routing bug affecting a completely different family of AI models. It demonstrates that the problem isn't confined to Claude models but is a broader system-wide issue within the GitHub Copilot CLI's backend integration. Users who select gpt-5 are likely expecting certain advancements or features that gpt-4.1 might not possess, leading to unfulfilled expectations and potential frustration.

Why This Matters: Impact on You and the GitHub Copilot Service

Okay, guys, let's talk about the real-world consequences of this GitHub Copilot CLI model routing bug. This isn't just a technical curiosity; it has significant implications for both you, the developer, and for the GitHub Copilot service itself. When a core feature like AI model selection isn't working as intended, it ripples through the entire user experience and the platform's integrity. It affects everything from productivity and performance to the fundamental trust users place in their development tools. We're talking about a feature that, on the surface, promises a customizable, powerful AI assistant, but under the hood, it's delivering a one-size-fits-all solution regardless of your specific needs. Understanding these impacts is crucial for appreciating the urgency of a fix and why this isn't just a minor issue to be swept under the rug. It speaks to the promise of sophisticated AI tooling versus the reality of a broken implementation, and it's a conversation worth having with transparency and a focus on resolution.

For Our Awesome Users: Unmet Expectations and Lost Control

For you, the dedicated developers relying on GitHub Copilot CLI to boost your productivity, this model routing bug is genuinely frustrating. First and foremost, your model selection is being ignored. Imagine trying to fine-tune your AI assistant for a specific task – say, using a lightweight Claude Haiku for quick code completion or a robust GPT-5 for complex architectural suggestions – only for the system to repeatedly send you to a default. This means you're losing critical control over your AI. Secondly, your performance expectations are unmet. If you select a "Haiku" model, you're likely doing so because you prioritize speed and efficiency. But if you're actually getting a "Sonnet" model, which is typically more thorough but slower, your workflow gets bottlenecked, and your deadlines might be impacted. This isn't just about speed; it's also about capability mismatch. Each AI model has its unique strengths and weaknesses. You might choose a particular model for its superior code generation in a specific language, or its better understanding of complex algorithms. When the CLI routes you to a different model, you're not getting those unique capabilities, effectively making your selection meaningless. Lastly, this bug means no feature control. The advertised ability to switch between AI models to optimize for speed, cost, or specific problem-solving is fundamentally broken. You're stuck with whatever default the backend provides, robbing you of the agency and flexibility that modern AI tools are supposed to offer. This can lead to inefficient use of resources, unexpected outputs, and a general feeling that your AI assistant isn't truly working for you.

For the GitHub Copilot Service: Integrity and Trust at Stake

From the perspective of the GitHub Copilot service and its developers, this model routing bug presents several significant challenges. The most apparent is a routing logic failure. The backend simply isn't processing requests based on the model selection parameter passed from the CLI, which points to a gap in the API's implementation or configuration. This effectively means a core feature is not functional. The model selection capability, while present and advertised in the CLI's UI and documentation, completely fails on the backend. This discrepancy can lead to a considerable support burden. As more users discover that their chosen AI model isn't being used, the volume of bug reports and support requests will inevitably increase, diverting valuable engineering resources. Furthermore, the user experience suffers, impacting satisfaction and potentially leading to churn if developers feel the tool isn't living up to its promises. In the long run, consistent issues like this can erode trust and brand reputation. In a competitive landscape of AI developer tools, delivering on advertised features is paramount. A broken AI model selection feature suggests a lack of robust testing or oversight, which could undermine the perceived reliability and quality of the entire GitHub Copilot CLI offering. Fixing this isn't just about squashing a bug; it's about restoring confidence and ensuring the platform's integrity.

Unraveling the Mystery: Possible Explanations for the GitHub Copilot CLI Model Routing Bug

Alright, tech enthusiasts, let's play detective and brainstorm some potential reasons why this GitHub Copilot CLI model routing bug is happening. When a feature like AI model selection fails so consistently, it usually points to a few common culprits in the software development process. Understanding these possibilities isn't just academic; it helps pinpoint where the fix needs to occur, whether it's on the client-side (the CLI itself) or the server-side (the backend AI services and their API). This isn't about blaming; it's about systematically diagnosing the problem to ensure a robust solution for the GitHub Copilot CLI.

1. Model Routing Not Implemented: This is perhaps the simplest explanation. It's possible that while the GitHub Copilot CLI was designed to accept a --model flag, the backend API or its underlying AI model routing infrastructure simply hasn't implemented the logic to process this parameter. Essentially, the UI is ahead of the server-side capabilities. The backend might have a default model it always uses, regardless of what the CLI sends.
2. Request Parameter Not Passed Correctly: Another possibility is that the GitHub Copilot CLI client itself might not be properly formatting or including the model selection parameter in the POST request it sends to the /chat/completions API endpoint. If the parameter isn't sent, or if it's malformed, the backend wouldn't even know which AI model you intended to use. This would lead to the backend falling back to its default.
3. Hardcoded Default Model on the Backend: It could be that the backend API endpoint itself has a hardcoded default model that takes precedence over any dynamic parameter. Even if the CLI sends the model parameter correctly, the server might be programmed to simply ignore it and always use, for example, Claude 3.5 Sonnet for all Claude requests and gpt-4.1 for all GPT requests. This is a common shortcut during development that sometimes makes it to production.
4. Backend Misconfiguration or Missing Routing Rules: Lastly, the issue could stem from misconfigured routing rules or a complete absence of them. The backend system responsible for mapping a requested AI model name (like claude-haiku-4.5) to the actual, physical backend endpoint or instance of that model might be incorrect or missing entirely. This would result in requests being sent to the wrong or default AI services.

Each of these scenarios points to a specific layer where the model routing bug might reside, guiding the path towards a comprehensive and effective solution for the GitHub Copilot CLI.

Our Call to Action: Recommendations for a GitHub Copilot CLI Model Routing Fix

Alright, developers and GitHub team, now that we've thoroughly dissected the GitHub Copilot CLI model routing bug, it's time to talk solutions. Addressing this critical issue isn't just about restoring a broken feature; it's about upholding the integrity of the GitHub Copilot CLI as a powerful, customizable AI assistant. We’ve got some clear recommendations that can guide the path to a robust and lasting fix, ensuring that when users select an AI model, they actually get the AI model they're asking for. This isn't rocket science, but it requires systematic investigation and implementation to get the model selection feature working as advertised.

1. Immediate Action: Investigate Backend Routing Logic: The very first step is to dive deep into the backend systems. The GitHub Copilot team needs to verify, with utmost urgency, that the model selection parameter sent from the CLI is not only being received but also processed correctly by the API and its internal routing mechanisms. This initial investigation can quickly confirm whether the issue lies in parsing the parameter, in the routing rules, or in the availability of the target models.
2. Fix Model Routing for All Advertised Models: This is the core fix. The routing logic must be updated to properly direct requests based on the user's explicit --model selection. This means:
   • Requests for claude-haiku-4.5 must route to the actual Claude Haiku 4.5 AI model.
   • Requests for claude-sonnet-4.5 must go to Claude Sonnet 4.5.
   • Requests for claude-sonnet-4 must be directed to Claude Sonnet 4.
   • Requests for gpt-5 must accurately route to GPT-5.
   • And, crucially, all other advertised AI models (like gpt-5.1, gpt-5.1-codex-mini, gpt-5.1-codex, as seen in the CLI help output) need to route to their respective backends. This ensures that the feature delivers on its promise across the board.
3. Verify Model Parameter Transfer End-to-End: A two-pronged approach here. First, confirm that the GitHub Copilot CLI client is indeed sending the correct model parameter within the POST request to the /chat/completions endpoint. Second, confirm that the backend is successfully receiving and parsing this parameter. Finally, verify that this parsed parameter is actually being used to make routing decisions, rather than being overlooked.
4. Enhance Logging and Debugging Capabilities: To prevent future occurrences and speed up diagnostics, it’s highly recommended to add server-side logging that explicitly records which model was requested by the user versus which model was actually used for processing the request. This provides invaluable telemetry for identifying where the routing chain breaks down.
5. Update Testing Procedures with Comprehensive End-to-End Tests: Finally, integrate robust automated tests into the development pipeline. These tests should verify that each model option routes to the correct backend and that the AI model actually responds as expected. This means testing the entire flow: CLI selection → API request → correct model response, ensuring long-term stability and preventing regressions of this model routing bug.

Implementing these recommendations will not only resolve the current model routing bug but also strengthen the overall reliability and user confidence in the GitHub Copilot CLI, making it the truly powerful and versatile AI assistant it's designed to be.

What's Next? The Path Forward for GitHub Copilot CLI's Model Selection

So, there you have it, guys. Our deep dive into the GitHub Copilot CLI has unequivocally exposed a significant routing bug: the backend simply isn't honoring your AI model selections. This isn't just a minor annoyance; it's a core feature failure that impacts how developers interact with their AI assistant, limiting their control and potentially hindering their productivity. We've shown through direct testing, log analysis, and system behavior observation that despite the CLI offering a seemingly wide array of model choices—from various Claude versions like claude-sonnet-4.5 and claude-haiku-4.5 to the advanced gpt-5—the system consistently defaults to other models, primarily Claude 3.5 Sonnet and gpt-4.1. This means the promise of a customizable, high-performance AI coding assistant isn't fully being delivered, and users are essentially getting a generic experience when they expect a tailored one.

The severity of this issue is undoubtedly high. A tool's inability to perform its advertised functions directly undermines user trust and the utility of the feature itself. As of our report on December 6, 2025, the status remains pending GitHub investigation. We sincerely hope that this detailed analysis, complete with direct evidence and actionable recommendations, will empower the GitHub team to swiftly identify the root cause and implement the necessary fixes.

For the GitHub Copilot CLI to truly shine and fulfill its potential as an indispensable tool for developers, the model selection feature must work reliably. Users deserve the ability to consciously choose the AI model best suited for their specific task, whether it's for speed, cost-effectiveness, or specialized capabilities. This isn't just about fixing a bug; it's about enhancing the developer experience, maintaining the integrity of the service, and ensuring that when you ask your AI assistant for gpt-5, you get gpt-5, and not its predecessor. Let's work towards a future where the GitHub Copilot CLI not only understands your code but also understands your explicit choice of intelligence.