(Github Copilot Adapter): Gemini 2.5 & o3 GONE from model picker

[ranyadshalom]

I've noticed in the past week or 2 that I am not able to select these models anymore. Of course, they are available to me on the Github website.

Good old print-debugging exposed that this was because they are no longer included in the response the adapter gets from Github's API endpoint.

Anyone else encountered this? I wonder if there's an easy fix here - maybe a different way to ask Github for their list of models, or a profile config that I missed.

[olimorris]

We pull models directly from GitHub:

codecompanion.nvim/lua/codecompanion/adapters/copilot/helpers.lua

Lines 35 to 97 in d067c84

	function M.get_models(adapter, get_and_authorize_token_fn, oauth_token)
	if _cached_models and _cache_expires and _cache_expires > os.time() then
	return _cached_models
	end
	if not _cached_adapter then
	if not adapter then
	return {}
	end
	_cached_adapter = adapter
	end
	if not get_and_authorize_token_fn(adapter) then
	return {}
	end
	local url = "https://api.githubcopilot.com/models"
	local headers = vim.deepcopy(_cached_adapter.headers)
	headers["Authorization"] = "Bearer " .. oauth_token
	local ok, response = pcall(function()
	return curl.get(url, {
	sync = true,
	headers = headers,
	insecure = config.adapters.opts.allow_insecure,
	proxy = config.adapters.opts.proxy,
	})
	end)
	if not ok then
	log:error("Could not get the Copilot models from " .. url .. ".\nError: %s", response)
	return {}
	end
	local ok, json = pcall(vim.json.decode, response.body)
	if not ok then
	log:error("Error parsing the response from " .. url .. ".\nError: %s", response.body)
	return {}
	end
	local models = {}
	for _, model in ipairs(json.data) do
	if model.model_picker_enabled and model.capabilities.type == "chat" then
	local choice_opts = {}
	if model.capabilities.supports.streaming then
	choice_opts.can_stream = true
	end
	if model.capabilities.supports.tool_calls then
	choice_opts.can_use_tools = true
	end
	if model.capabilities.supports.vision then
	choice_opts.has_vision = true
	end
	models[model.id] = { opts = choice_opts }
	end
	end
	_cached_models = models
	_cache_expires = utils.refresh_cache(_cache_file, config.adapters.opts.cache_models_for)
	return models
	end

This will be an issue with availability on the GitHub side.

[ranyadshalom]

Interesting.

Unfortunately changing the API endpoint in codecompanion to https://api.individual.githubcopilot.com/models didn't do the trick for me.

[olimorris]

This is really strange.

I'm aware that GitHub can turn off certain models for performance reasons etc. I've typically observed this when a new model has been launched and it's getting hit hard.

But I can't fathom why that would be the case here. Is there anything missing in the request to /models call that could be causing this? Perhaps a header?!

[Eckii24]

I think this PR is leading to this issue:

#1789

Previously we were taking the base URI from the token itself, which means it was api.individual.githubcopilot.com (or api.business...). We are still doing that, when calling the completions endpoint. The PR tries to fix an issue with unauthorized calls, when the token was already expired and kind of reverted it back to call api.githubcopilot.com.

This would match my observation, that the latter endpoint is returning less models than the first one.

This PR would fix that, but would possible bring back the auth problem...

#1873

Edit: One argument against this theory is the post, that changing the adapter to use api.individual... wasn't fixing the model issue for you...

[olimorris]

@Eckii24 have you reverted back to a previous version to test this out? I don't understand how we would "lose" access to those models. We're still hitting https://api.githubcopilot.com/models and if we weren't authenticating correctly we'd see an error or at the worst, no models returned.

[Eckii24]

commit 94acda8 (refactor: references are now context)

commit 3527a9c (before the PR from above)

We are "losing" the models, because the different githubcopilot endpoints are returning different results.

[bassamsdata]

@Eckii24 Thank you for spending time investigating this. Would you mind testing the new PR #1899 to see if there are any issues with GitHub Copilot now?

[ranyadshalom]

Thanks @bassamsdata !
I just pulled the latest main branch and it's working here too. Marking as resolved.