builders · review · first seen Oct 28, 09:33 UTC

Google Gemini CLI adds model discovery in preview

Gemini CLI v0.67.0-preview.0 shipped a models command and --list-models flag, plus an IDE companion bridge into container sandboxes over exec stdio. For builders, the reason to look now is to test whether either addition fits a workflow they already use.

L0 · primary1 source2 claims checked4 min read

What shipped

The v0.67.0-preview.0 release adds two model-discovery entry points: a models command and a --list-models flag. Both are shipped changes in the preview release. The claim does not say what either entry point prints, whether their output is identical, or which models a user will see. If you need a model list for a decision today, the release gives you a place to check, not an answer you can assume in advance. [1]

The release also adds a bridge for the IDE companion into container sandboxes over exec stdio. This is distinct from model discovery: it concerns the connection between the IDE companion and a sandbox, not model selection. The release excerpt identifies the bridge and its transport but provides no setup sequence or supported-configuration list. Its presence in the release is a reason to test your own container workflow, not evidence that every IDE and sandbox combination works. [1]

These are shipped entries in a version named v0.67.0-preview.0, not features merely scheduled for that version. Keep the scope of the announcement equally precise. It establishes a CLI model-discovery surface and an IDE companion bridge over exec stdio. It does not establish a broader catalog of available models, a particular bridge experience, or a dependency between the two additions. Those distinctions matter when deciding what to evaluate and what to leave out of a rollout decision. [1][2]

Why it matters if you build

For a builder choosing a model while using Gemini CLI, the new command and flag can move discovery into the CLI workflow. Start by asking what your environment shows rather than treating the release entry as a model inventory. The supplied material does not say whether the command and flag return the same information, whether configuration affects the result, or how any limits are presented. Until you inspect their output, neither entry point is a dependable basis for documenting available choices for a team. [1]

For a builder working inside a container sandbox with the IDE companion, the exec-stdio bridge is the change worth testing. The claim names a connection path but not the steps needed to use it or the behavior available after connection. It supplies no figures for operating cost, latency, or reliability. The practical question is narrower than whether the bridge is generally useful: does it work in the container and IDE arrangement you use, and does that observed behavior meet your needs? [1]

Evaluate the two additions separately. A useful model-discovery result would not demonstrate that the IDE bridge works; a working bridge would not show which models the CLI lists. Separating the checks also keeps the decision tied to what the release actually says. The supplied evidence gives feature names and a transport, but no output examples, compatibility matrix, or measurements that would justify adopting both as a single workflow without testing them. [1][2]

How to try it today

1. Use Gemini CLI v0.67.0-preview.0 for the evaluation.
2. Run the models command and note what it shows in your environment.
3. Run with --list-models and compare what it shows.
4. If you use a container sandbox, test the IDE companion bridge over exec stdio in that setup.
5. Record separate results for model discovery and the bridge before deciding whether to adopt either.

What we checked

Every claim below was walked down the source ladder. The rung is how close the source is to the thing itself; the tense is the source's own.

1. shipped L0 · primary

   Gemini CLI v0.67.0-preview.0 adds a models command and --list-models flag for model discovery.

   per GitHub releases · google-gemini/gemini-cli (L0)
2. shipped L0 · primary

   Gemini CLI v0.67.0-preview.0 adds an IDE companion bridge into container sandboxes over exec stdio.

   per GitHub releases · google-gemini/gemini-cli (L0)

What is not confirmed

The supplied material does not establish which models appear, who can see them, what the discovery output contains, or whether the command and flag behave identically. It does not establish IDE compatibility, bridge configuration steps, supported container environments, or what the companion can do after connecting. It also provides no measured cost, latency, or reliability. Treat those as unanswered questions for your own evaluation, not as properties implied by the release entries. [1][2]

Who should act, who should wait

Act now if you use Gemini CLI and need to inspect model choices, or if you already use the IDE companion with a container sandbox and have a specific connection to test. Check the named features in v0.67.0-preview.0 and decide from what happens in your environment. Wait before making either feature a required team workflow if that decision depends on documented output, compatibility, setup steps, or measured operating costs. The release confirms that the additions shipped; it does not answer those deployment questions. [1][2]

Sources

• Release v0.67.0-preview.0 — GitHub releases · google-gemini/gemini-cli L0 · primary
• Release v0.66.0 — GitHub releases · google-gemini/gemini-cli L0 · primary