Gemini 3.8 Flash is missing from listModels() and silently falls back to Claude Sonnet 5

[SIkebe]

Summary

With @github/copilot-sdk@1.0.13, the Copilot-hosted model gemini-3.8-flash is absent from client.listModels(). However, client.createSession({ model: "gemini-3.8-flash" }) succeeds, and session.rpc.model.getCurrent() reports that Gemini is selected.

When a prompt is sent, the authoritative assistant.usage event reports that the request actually used claude-sonnet-5.

This results in three conflicting states:

listed: false
selected: gemini-3.8-flash
used: claude-sonnet-5

There is no error or warning indicating that the requested model was unavailable or that fallback occurred.

Environment

• @github/copilot-sdk: 1.0.13
• Bundled Copilot CLI/runtime: 1.0.83
• Node.js: v22.17.0
• npm: 11.6.2
• OS: Windows NT 10.0.26200.0
• Authentication: Explicit GitHub token for a Copilot-enabled user
• Provider: GitHub Copilot-hosted models, not BYOK
• Model: gemini-3.8-flash

This was reproduced with two separately authenticated GitHub accounts.

Minimal reproduction

Install the current stable SDK:

npm install @github/copilot-sdk@1.0.13

Save the following as repro.mjs:

import { CopilotClient } from "@github/copilot-sdk";

const requestedModel = "gemini-3.8-flash";
const gitHubToken = process.env.GITHUB_TOKEN ?? process.env.GH_TOKEN;

if (!gitHubToken) {
  throw new Error("Set GITHUB_TOKEN or GH_TOKEN.");
}

const client = new CopilotClient({
  gitHubToken,
  useLoggedInUser: false,
});

let session;

try {
  await client.start();

  const models = await client.listModels();
  console.log(
    "listed:",
    models.some(({ id }) => id === requestedModel),
  );

  session = await client.createSession({
    model: requestedModel,
  });

  const current = await session.rpc.model.getCurrent();
  console.log("selected:", current.modelId);

  let actualModel;

  session.on("assistant.usage", ({ data }) => {
    actualModel = data.model;
  });

  const response = await session.sendAndWait(
    "Reply with exactly OK.",
    120_000,
  );

  console.log("used:", actualModel);
  console.log("response:", response?.data.content);
} finally {
  await session?.disconnect();
  await client.stop();
}

Run it:

node repro.mjs

Actual result

listed: false
selected: gemini-3.8-flash
used: claude-sonnet-5
response: OK

The session-scoped model catalog also omits Gemini when queried with cache bypass:

const result = await session.rpc.model.list({ skipCache: true });

Expected result

One of the following would be consistent behavior:

1. If gemini-3.8-flash is available, it should be returned by the model-list APIs and used for the request.
2. If it is unavailable in the SDK/server-mode context, session creation or model switching should fail with a clear error.
3. If automatic fallback is intentional, the SDK should surface it explicitly, and getCurrent() should report the effective model rather than the unavailable requested model.

At minimum, session.rpc.model.getCurrent() and assistant.usage.data.model should not disagree without an accompanying model-change or fallback notification.

Additional observations

• client.listModels() returned 21 models, with no Gemini models.
• session.rpc.model.list({ skipCache: true }) returned 20 models, also with no Gemini models.
• The same behavior remained after explicitly enabling Gemini 3.8 Flash in the applicable Copilot model policy and waiting for the setting to propagate.
• Standalone Copilot CLI 1.0.83 can use gemini-3.8-flash successfully, and its usage data identifies Gemini as the actual model.
• This suggests a difference between standalone CLI startup model resolution and SDK/server-mode model discovery or dispatch.
• The issue is reproducible on a clean temporary Node.js project using the published SDK package.

[github-actions]

Investigation summary

I reviewed the SDK's model-related code paths in nodejs/src/client.ts and the generated RPC wrapper (nodejs/src/generated/rpc.ts):

• client.listModels() (client.ts ~2113-2140) is a thin cache wrapper around connection.sendRequest("models.list", {}) — it does no client-side filtering, validation, or fallback logic.
• client.createSession() (client.ts ~1509-1740) forwards config.model verbatim as model: config.model in the session.create RPC request (client.ts:1629) — there is no client-side check that the requested model exists in the catalog before creating the session.
• session.rpc.model.getCurrent() and session.rpc.model.list() (generated/rpc.ts ~24824-24825) are pure passthroughs to session.model.getCurrent / session.model.list RPC calls — the SDK does not compute or cache "current model" state itself; it just relays whatever the connected CLI/runtime reports.

Conclusion: The copilot-sdk (this repository) contains no client-side logic that resolves models, decides fallback, or reconciles getCurrent() with actual usage — all of that resolution happens inside the bundled Copilot CLI/runtime that the SDK talks to over JSON-RPC. So the described behavior (accepting an unlisted model, reporting it as "selected", then silently using a different model for the actual request with no model_change/fallback event) is a genuine functional bug, but the root cause lives in the CLI/runtime's model-catalog and model-resolution/dispatch code, not in this SDK's implementation.

Labeling as bug since it's a real, reproducible inconsistency affecting SDK users end-to-end (no error surfaced, getCurrent() and assistant.usage.data.model disagree). However, since the SDK itself only relays what the CLI/runtime returns, a fix will need to happen in the underlying Copilot CLI/runtime's model resolution and catalog logic (and/or it should emit an explicit fallback/model-change event so getCurrent() stays consistent with actual usage) — this may need to be cross-filed against the copilot-cli runtime if that's tracked in a separate repository.

Generated by Bug Handler for #2571 · copilot · auto · 25.9 AIC · ⌖ 6.25 AIC · ⊞ 7.6K · ◷