GitHub Copilot CLI combines model families for a second opinion

[ebndev]

Discover how Rubber Duck provides a different perspective to GitHub Copilot CLI.

When you ask a coding agent to build a data pipeline, it may not use the best structure. But what if the agent got a second opinion before it executed the plan?

Today, in GitHub Copilot CLI, we're introducing Rubber Duck in experimental mode. Rubber Duck leverages a second model from a different AI family to act as an independent reviewer, assessing the agent's plans and work at the moments where feedback matters most.

To catch different kinds of errors, a different perspective matters. Our evaluations show that Claude Sonnet + Rubber Duck makes up 74.7% of the performance gap between Sonnet and Opus alone, achieving better results for tackling difficult multi-file and long-running tasks. Use /experimental in Copilot CLI to access Rubber Duck alongside our other experimental features.

The problem: Confident mistakes can compound

Today’s coding agents follow a clear loop. First, the agent assesses the task, then drafts a plan, implements, tests, and iterates if necessary. It's a powerful flow that works well, but it has blind spots. Any decision an agent makes early on, especially in the planning stage, is the foundation you’re building upon. Assumptions and inefficiencies become dependencies, and by the time you notice, you may have to fix more than just the small mistake at the start.

Using self-reflection and having the agent review its own output before moving forward is a proven technique. However, a model reviewing its own work is still bounded by its own training biases: the same training data and techniques, the same blind spots.

Rubber Duck adds a second perspective

Rubber Duck is a focused review agent, powered by a model from a complementary family to your primary Copilot session. When you've selected a Claude model from the model picker to use as your orchestrator, Rubber Duck will be GPT-5.4. As we experiment with Rubber Duck, we are exploring other model families for the orchestrator and for the Rubber Duck. The job of Rubber Duck is to check the agent's work and surface a short, focused list of high-value concerns: details that the primary agent may have missed, assumptions worth questioning, and edge cases to consider.

When does the cross-family review help?

We evaluated Rubber Duck on SWE-Bench Pro, a benchmark of large, difficult, real-world coding problems drawn from open-source repositories. Here's what we found:

Claude Sonnet 4.6 paired with Rubber Duck running GPT-5.4 achieved a resolution rate approaching Claude Opus 4.6 running alone, closing 74.7% of the performance gap between Sonnet and Opus.

We noticed that Rubber Duck tends to help more with difficult problems, ones that span 3+ files and would normally take 70+ steps. On these problems, Sonnet + Rubber Duck scores 3.8% higher than the Sonnet baseline, and 4.8% higher on the hardest problems identified across three trials. Here are a few examples of what Rubber Duck finds:

• Architectural catch (OpenLibrary/async scheduler): Rubber Duck caught that the proposed scheduler would start and immediately exit, running zero jobs—and that even if fixed, one of the scheduled tasks was itself an infinite loop.

• One-liner bug, big impact (OpenLibrary/Solr): Rubber Duck caught a loop that silently overwrote the same dict key on every iteration. Three of four Solr facet categories were being dropped from every search query, with no error thrown.

• Cross-file conflict (NodeBB/email confirmation): Rubber Duck caught three files that all read from a Redis key which the new code stopped writing. The confirmation UI and cleanup paths would have been silently broken on deploy.

When does Rubber Duck activate?

GitHub Copilot can call Rubber Duck automatically, both proactively and reactively, and it can be triggered by a user at any time to critique and revise its work.

For complex work, GitHub Copilot may seek a critique automatically at the checkpoints where feedback has the highest return:

1. After drafting a plan: This is where we expect developers will see the biggest wins, because catching a suboptimal decision early avoids compounding errors downstream.
2. After a complex implementation: This is when a second set of eyes on complex code can help catch edge cases.
3. After writing tests, before executing them: This is a chance to catch gaps in test coverage or flawed assertions, before self-reinforcing that “everything passes.”

The agent can also seek a critique reactively if it gets stuck in a loop or can't make progress. Consulting Rubber Duck can break the logjam.

As a user, you can request a critique at any point. Copilot will query Rubber Duck, reason over the feedback, and show you what changed and why.

We made a key design choice: the agent invokes Rubber Duck sparingly, targeting the moments where the signal is highest, without getting in the way. For the technically curious: Rubber Duck is invoked through Copilot's existing task tool—the same infrastructure used for other subagents.

For now, we are enabling Rubber Duck for all Claude family models (Opus, Sonnet, and Haiku) used as orchestrators in the model picker. We are already exploring other model families for the Rubber Duck to pair with GPT-5.4 as the orchestrator.

Getting started

Rubber Duck is available today in experimental mode.

To start using it, install GitHub Copilot CLI, and run the /experimental slash command. Rubber Duck will be available when you select any Claude model from the model picker and have access enabled to GPT-5.4. You'll see critiques surface in two ways:

• Automatically, when Copilot decides a checkpoint warrants a second opinion: after planning, after complex implementations, or after writing tests.
• On demand, whenever you ask. Just tell Copilot to critique its work, and it will invoke Rubber Duck, incorporate the feedback, and show you exactly what changed.

Where Rubber Duck helps most:

• Complex refactors and architectural changes
• High-stakes tasks where a miss is costly
• Ensuring comprehensive test coverage
• Any time you want a second opinion on a plan before committing to it

Rubber Duck in GitHub Copilot CLI is now available in experimental mode.

🌟Leave a comment!

Join the discussion and leave feedback in the comments below!

[asafd1]

How is quota affected by rubber duck? Does this consume additional premium requests?

[inteist]

How is quota affected by rubber duck? Does this consume additional premium requests?

+1

[K-Cully]

Is there a recommended way to configure rubber duck to use a specific second model or can, and should, it just be configured through custom instructions?

[logar16]

I was just inundated with rubber ducks. I was using Claude Opus 4.6 and it launched a background agent, and I ended up with over 10 rubber-duck agents. I asked Copilot why it launched so many and it said:

You're right, and I owe you an honest answer: that was excessive. Here's what happened:
The benchmark agent (the one actually doing the work) launched its own rubber duck critics internally — multiple rounds of them. Then I also launched rubber ducks to review its plan. So we ended up with 10+ rubber ducks all saying essentially the same 5 things, burning tokens and cluttering your task list.

My discussion questions:

• Can we limit how frequently it launches ducks? I don't think the current instructions are clear enough about this and the agent rubber-ducks everything.
  • Can we turn off rubber-duck tool for subagents and leave it up to the orchestrator of the fleet to decide when to invoke?
  • Can we specify when rubber-duck can be used like ONLY after plan is made but before implementation or NEVER for tests etc.
  • Can we just turn off the feature if it isn't adding value?
• Can we have the system warn the agent when it's got more than one rubber duck running at a time or it is running a rubber duck on every modified file? Something to kind of pump the brakes if it's context is full or was recently compacted or it's just a huge fan of rubber ducking...

[inteist]

This is both hilarious and frickin AMAZING that it gave you such an introspective answer!

Would be great to have an official answer about premium requests impact.

[muehz]

Wondering if it makes sense here to just make it a /rubber-duck command similar to /fleet so that you can opt in and then restrict the natural language identification to only happen when the user mentions rubber duck or is quite explicit with their request for a review.

Loving it so far but it definitely spins up more frequently than I would choose if I had more control over when it gets used.

[logar16]

This is both hilarious and frickin AMAZING that it gave you such an introspective answer!

Later in the response it was like "I should have been fine with the one critique instead of gathering a parliament of ducks" which I found quite entertaining 😄

[logar16]

I actually have found that every time rubber duck is invoked, I get 4 subagents. I'm not sure why, could be it takes to long to hear from first so it keeps launching them or what, but I consistently get four each time and they all come to same conclusions, so it's just wasting tokens. I'm sorry but I can't use this feature in this state. 😢