What happened
The GitHub release page for simonw/llm-gemini lists version 0.36, published on November 10. Its release note names one user-facing change: “Gemini 4 Carbon, as llm -m gemini-4-carbon.” The stated command identifies the model name that a user can pass to the llm command when selecting Gemini 4 Carbon. The release links that work to issue #161.
The announcement is narrowly scoped. It does not introduce a separate interface, an agent workflow, or a new configuration syntax. Instead, it adds a model identifier to an existing command-line integration. A developer who already invokes models through the LLM CLI has a documented way to request Gemini 4 Carbon without changing the basic command pattern used for model selection.
The release does not announce Gemini 4 Carbon itself, and it does not describe a change to Google’s access terms. It also does not state whether a separate installation step, credential configuration, account type, or API setting is required. Those details may matter in practice, but they are outside the scope of this release note. The update should therefore be read as plugin support for a named model, rather than a statement that every LLM CLI user automatically has access to that model.
GitHub’s release page shows three commits to the main branch since the release and lists two assets. It does not identify those commits as additional user-facing features, and the short release note does not enumerate changes beyond Carbon support. There is no stated price, quota, context window, modality list, latency figure, benchmark result, availability condition, or compatibility guarantee. The page also does not say whether selecting the new model changes the behavior of existing calls or affects other models in llm-gemini.
For an existing LLM CLI user, the concrete action stated by the release is simple: select the model with llm -m gemini-4-carbon. That is useful as an integration point, but it is not a substitute for checking a team’s Gemini access and local tool configuration. The release establishes the command name; operational eligibility and workload fit remain separate questions.
What the archive adds
New Runtime’s earlier coverage on November 11 documented Gemini 4 Carbon on Google Cloud and in Agent Studio, and separate coverage recorded access through Perplexity products. Those were distribution routes for the model, not coverage of this command-line integration. This is a new fact in the wider Carbon availability story: llm-gemini adds another developer-facing route rather than restating the model’s launch. Earlier coverage on Google Cloud and Agent Studio and earlier coverage of Perplexity access.
Trend signal
The release is a small example of model choice becoming portable across developer interfaces: a model-specific option can be added to an existing CLI while preserving the tool’s basic invocation pattern. That can reduce interface-switching for users who already work in that environment. One small plugin release does not establish a durable interoperability layer, however, so this does not yet fit a pattern New Runtime tracks.
Connections to other events
New Runtime’s November 11 coverage also recorded Gemini 4 Carbon ranking first on CursorBench 4.0 and Perplexity’s WANDR benchmarks for deep agentic work. That benchmark note concerns model evaluation; version 0.36 concerns a local developer interface. Together, they distinguish two separate questions for builders: whether a model is promising for a workload, and whether it is reachable through the tools a team already operates.
Why it matters
A shared command-line interface can make model experimentation less disruptive for developers who already use it to invoke different providers. Rather than adopting a separate client solely to try Gemini 4 Carbon, an llm-gemini user can select it within an existing command pattern. That may reduce friction in local exploration, scripts, and repeatable command-line workflows.
The release does not claim that calls to different models are equivalent, nor that Carbon is cheaper, faster, or better for a particular task. Teams should treat the addition as a newly selectable endpoint, not as evidence for a production migration. Prompt behavior, authentication, cost, latency, output format, and failure modes can all determine whether a model is suitable for a particular automation.
The practical consequence is modest but real for existing users: model access is now closer to the workflow they already have. A team evaluating Carbon can begin with a small, controlled comparison rather than redesigning its tooling around a new client. The relevant decision is not whether a new identifier exists, but whether it improves a measured task under the team’s own constraints.
Limits and uncertainty
The release note is brief and does not independently establish how Gemini 4 Carbon performs. Pricing, quotas, model limits, required account configuration, and availability are not described in the announcement. There are no benchmark results, completed-task examples, or stated compatibility guarantees for scripts using the new identifier.
The page also does not clarify whether all llm-gemini users can invoke the model or whether Google-side access requirements apply. It does not document credential handling, error behavior, fallback behavior, or any difference between this model and other plugin-supported options. Builders should verify those details in their own environment before relying on the integration in production, especially where scripts are automated or cost-sensitive.
Skill to build now
Create a small repeatable model-comparison command for one real task your team already runs. Use the documented llm -m gemini-4-carbon selector alongside the model currently used in that workflow, then record task success, runtime, output format, and any setup failures. Keep credentials and budgets controlled. This turns a new CLI option into a testable engineering choice rather than an assumption based on the model name.
Reader takeaway
llm-gemini 0.36 makes Gemini 4 Carbon selectable from the LLM CLI with llm -m gemini-4-carbon. It is a useful integration update for existing LLM users, but it supplies no new evidence about Carbon’s price, access terms, reliability, or task-level capability. Test the route on a bounded workload before making it part of production automation.