# Gemini CLI vs Claude Code in production engineering

> A practical Gemini CLI vs Claude comparison of autonomy, context, pricing, safety controls, and performance on real engineering work.

Gemini CLI and Claude Code can both inspect a repository, edit files, run commands, and keep working through a multi-part task. That surface similarity causes bad buying decisions. The useful difference is how each agent behaves after the first plausible edit: what it reads, what it forgets, which actions it can take without interruption, how it recovers, and how much a completed task costs.

My short answer is that Claude Code is usually the steadier primary agent for ambiguous implementation work, while Gemini CLI is unusually attractive for broad exploration, large inputs, Google-centered environments, and cost-sensitive adoption. Neither wins every task. A team gets more from choosing an operating model than from arguing about model rankings.

The comparison also changes quickly. I use current product documentation for quotas and controls, but I do not treat a model name or a vendor benchmark as a durable conclusion. The test that matters is a clean worktree, a representative issue, the same acceptance criteria, and a review of the resulting diff.

## The useful comparison starts after the first edit

The decision is not which agent can produce a working demo. Both can. The decision is which one reaches a reviewable change with fewer wrong turns under your repository's actual constraints.

| Question | Gemini CLI | Claude Code |
| --- | --- | --- |
| Best default role | Repository exploration, broad context gathering, inexpensive experimentation | Ambiguous implementation, iterative debugging, careful local changes |
| Autonomy model | Default, Auto-Edit, Plan, and YOLO modes backed by a policy engine | Default, acceptEdits, Plan, auto, dontAsk, and bypassPermissions modes with allow, ask, and deny rules |
| Project instructions | Hierarchical `GEMINI.md` files, configurable filenames, imports, and memory commands | Hierarchical `CLAUDE.md`, scoped rules, imports, auto memory, and compaction controls |
| Recovery | Optional checkpointing with a shadow Git repository plus session resume | Automatic checkpoints for direct edit tools plus conversation rewind and session resume |
| Entry cost | A substantial free quota with a Google account, then subscriptions or metered API use | Pro or Max subscription access, team plans, or metered API use |
| Typical operational risk | A large apparent context budget encourages indiscriminate loading | Long iterative loops can consume paid usage and preserve stale assumptions |

This table describes product shape, not code quality. Output quality still depends on the selected model, repository, prompt, tool setup, and acceptance test. A one-line bug in a mature service and a cross-package migration are different products from the agent's point of view.

I judge an agent on five events: how it frames the task, how it searches, when it edits, what it runs after editing, and how it responds to a failed check. Claude Code often keeps a tighter chain between those events. Gemini CLI often casts a wider net. Tight is better when the issue contains hidden local conventions. Wide is better when the hard part is locating the owning subsystem or comparing many files before choosing a change.

The awkward truth is that agent quality can reverse inside one repository. Claude may solve backend changes with less supervision while Gemini finds frontend dependencies faster. Do not turn a useful preference into a company religion.

## Autonomy is a permission architecture, not a personality

Agent autonomy means the client can continue a bounded sequence of reads, edits, commands, and corrections without asking after every tool call. It does not mean giving a model unrestricted shell access. Teams that blur those ideas either create approval fatigue or grant permissions they cannot explain.

Gemini CLI exposes a clear ladder. Default mode asks about many write operations. Auto-Edit approves editing tools while retaining prompts for other actions. Plan mode keeps research read only. YOLO mode approves tools automatically and should run inside a disposable or tightly isolated environment. Its policy engine can allow, deny, or ask based on tool names, command prefixes, arguments, mode, and whether the session is interactive. Google documents that a global deny can remove a tool from the model's available context, which is better than merely hoping the agent avoids it.

Claude Code has a similar ladder with different edges. Default mode asks on first use. `acceptEdits` approves file edits and common file operations in allowed directories. Plan mode explores without changing source. `dontAsk` rejects anything that was not approved in advance. `bypassPermissions` suppresses prompts and belongs in an isolated container or virtual machine. The newer `auto` mode adds background safety checks, but Anthropic labels it a research preview, so I would not make it the foundation of a production control policy yet.

Both tools separate behavioral instructions from enforced controls. A sentence in `GEMINI.md` or `CLAUDE.md` can tell the model not to read secrets, but a deny policy or sandbox boundary prevents the access. That distinction matters. Prompts guide behavior. Client policies and operating system isolation constrain behavior.

A small allowlist beats a giant confirmation queue. For a typical application repository, I permit read operations, edits inside the worktree, the normal formatter, targeted tests, and read-only Git commands. I keep package installation, network calls, credential tools, deployment commands, database clients, and destructive Git operations behind explicit approval. This gives the agent enough room to finish ordinary work without turning every session into a remote shell with a conversational front end.

A Gemini policy can make the intent concrete:

```toml
[[rule]]
toolName = "run_shell_command"
commandPrefix = "git push"
decision = "deny"
priority = 100

[[rule]]
toolName = "run_shell_command"
commandPrefix = "npm test"
decision = "allow"
priority = 50
```

Claude Code expresses the same operating idea through permission allow and deny rules in settings. The syntax differs, but the review question does not: can another engineer see which commands run silently, which commands stop, and which paths remain inaccessible?

Sandboxing deserves its own decision. Gemini can run the whole CLI through platform or container isolation and can request a one-time sandbox expansion when a command needs more access. Claude combines permission rules with an operating system sandbox for Bash and its child processes. In either tool, the safest high-autonomy setup is an expendable worktree in a container, with credentials omitted and deployment unavailable. The agent should be able to ruin its workspace without ruining anything else.

## Context handling rewards selection, not hoarding

A large context window does not guarantee better repository understanding. The agent still has to select relevant files, preserve the important facts across turns, and discard noisy output before it crowds out the task.

Gemini CLI uses hierarchical `GEMINI.md` files for persistent instructions. It can load global, workspace, and directory-specific context, import other files, and show the concatenated result with `/memory show`. The configurable context filename is useful in mixed-agent repositories because a team can ask Gemini CLI to load an existing `AGENTS.md` rather than maintain duplicate rules. Gemini also has session resume, saved memory, and context compression.

Claude Code loads `CLAUDE.md` and `CLAUDE.local.md` while walking the directory hierarchy. Files below the working directory load when Claude reads into those subtrees. Project rules can apply instructions only to matching paths, and auto memory keeps selected project knowledge in local Markdown files. Anthropic's documentation makes a useful admission: these files consume context and are instructions rather than enforcement. It recommends keeping a `CLAUDE.md` under roughly 200 lines because longer files reduce adherence.

Compaction is where long sessions expose their design. Claude Code automatically summarizes history as the context fills. A project-root `CLAUDE.md` is read again after compaction, while conversation-only instructions can disappear unless the summary preserves them. Gemini CLI also compresses long history and reloads its persistent context system. In both cases, durable constraints belong in repository instructions, not in a prompt sent forty minutes earlier.

I have watched a familiar failure in monorepos. The agent starts at the repository root, reads a giant architecture document, scans generated clients, dumps a verbose test log, and then edits a package whose local instructions were never loaded. The nominal context window still has room, yet the decision is worse because the useful evidence occupies a small fraction of it. The fix is not another hundred thousand tokens. Start in the owning package, scope instruction files, exclude generated trees, and run a focused check whose failure output fits on one screen.

Use context files for facts that remain true: build commands, package boundaries, generated file rules, test locations, naming rules, and forbidden operations. Put issue-specific acceptance criteria in the task prompt. Store explanations near the code when future humans need them. If an agent must reread six pages of team philosophy on every turn, the file is doing the wrong job.

Gemini's broad context capability helps when the evidence really is broad, such as tracing an event across several services or comparing repeated schemas. Claude's selective file loading and mature compaction often feel more controlled during a long implementation loop. I would still choose based on a measured task, because a clean repository structure can erase much of this difference and a chaotic one can defeat both.

## Pricing must be measured per accepted task

Sticker price is a poor measure of coding-agent cost. The denominator should be accepted work, not prompts, requests, or tokens. A free agent that produces three rejected diffs costs more engineering time than a paid agent that lands one clean change.

Google's Gemini CLI quota documentation lists 1,000 model requests per user per day for individuals who sign in with a Google account. Google AI Pro raises that to 1,500, and Ultra to 2,000. An unpaid Gemini API key gets 250 requests and uses Flash only. Paid API key and Vertex AI paths use metered pricing, while organizational Code Assist subscriptions provide fixed quotas. The current US Google One page lists Google AI Pro at $19.99 per month, though regional pricing and bundles differ.

Claude Code is included in the individual Pro plan, listed at $20 monthly or less with annual billing, and Max starts at $100 monthly. Team seats and enterprise arrangements have different limits. Console authentication charges API usage by tokens, and cloud-provider routes follow their provider pricing. Anthropic's `/usage` output shows session token and cost estimates for API users, while subscription users see plan usage rather than a meaningful per-session invoice.

The headline prices look close at the entry subscription level, but the limits are not directly comparable. A Gemini request is not a Claude message, and one agentic turn can trigger different model calls, tool results, retries, cache reads, or routing choices. Subscription limits can also reset on different schedules. Procurement cannot normalize these products by dividing monthly price by a published request cap.

Track four numbers for each completed issue:

- Human minutes spent prompting, approving, correcting, and reviewing
- Agent usage cost or the fraction of a subscription limit consumed
- CI minutes and external tool costs caused by the run
- Rework minutes after the first review

Then calculate cost per accepted task and cost per accepted change size band. Keep tiny fixes separate from migrations. If one tool costs $40 more per developer each month but saves two hours of senior review, the price difference is noise. If a team needs Max plans because sessions repeatedly burn through context on poorly scoped issues, fix the workflow before buying a higher ceiling.

Gemini CLI wins the low-risk trial on price because its free individual quota supports meaningful evaluation. Claude Code's Pro entry price is easy to justify for a working engineer, but heavy parallel sessions can push users toward Max or API billing. Run the pilot with billing telemetry enabled. Memory is not an accounting system.

## A fair real-task trial fits in one week

A useful evaluation repeats representative work from a clean state and scores artifacts that a maintainer can inspect. It does not ask both agents to build a toy application and award points for visual polish.

Choose four closed issues whose correct solutions are already known to one evaluator. Use one localized bug, one change across several files, one failing test with an unclear cause, and one task that requires reading documentation inside the repository. Remove customer data and secrets. Do not choose issues that appeared in public training material or whose final patches are searchable.

Create two clean worktrees from the same commit:

```bash
git worktree add ../trial-gemini trial-base
git worktree add ../trial-claude trial-base
cd ../trial-gemini
git status -s
```

The expected output from the last command is empty. Record the commit with `git rev-parse HEAD`, use identical local dependencies, and disable network access unless the task requires it. Give both agents the same acceptance criteria, but let each use its native planning and context features. A forced common prompt that disables product strengths produces a neat but useless comparison.

Use this task envelope:

```text
Goal: Fix the duplicate invoice event described below.
Scope: billing-worker and its tests. Do not change generated clients.
Acceptance: the focused test passes, the full billing suite passes, and no public API changes.
Evidence: report files changed, commands run, and any remaining uncertainty.
Stop: do not install packages, access the network, or commit.
```

Allow a fixed wall-clock window, not a fixed number of prompts. A more autonomous agent should benefit from doing more useful work without intervention. Stop a run if it violates scope, repeats the same failed action twice without a new hypothesis, or needs information intentionally withheld from both agents. Do not rescue one product with detailed hints and then call its result autonomous.

Score each run before revealing the known patch. I use six fields: acceptance checks passed, unnecessary files touched, reviewer minutes, human interventions, unsupported claims in the final report, and recoverability after a planted failure. For recoverability, make one test fixture inconsistent or deny one expected command. Watch whether the agent inspects the error, changes its theory, and returns to a clean solution.

The diff review should answer concrete questions. Did the agent change the narrowest correct layer? Did it add a regression test that fails without the fix? Did it preserve public behavior? Did it leave comments that explain code or narrate the session? Did it conceal a failing command behind a confident summary? A solution that passes tests by weakening an assertion is a failure even if every checkbox is green.

Repeat at least one task with the tools swapped in order. The evaluator learns from the first run and can unconsciously give the second agent a better prompt, so alternate which product goes first. Keep raw transcripts, final diffs, command logs, and score sheets. Model updates will invalidate the ranking eventually, but the evaluation harness remains useful.

## Real-task performance depends on the shape of the work

Claude Code usually earns my first attempt when the task is underspecified and the repository contains strong local conventions. It tends to maintain a coherent implementation thread through search, edit, test, and correction. That shows up in debugging work where the first failing test points at the symptom rather than the cause. Its checkpoint and rewind interface also makes iterative exploration less stressful, provided changes came through tracked edit tools.

Gemini CLI earns my first attempt when discovery dominates implementation. Its context system, Google search integration where policy permits it, configurable instruction filenames, and broad tool surface fit investigations that cross directories or data sources. The free quota makes it easy to place on every engineer's machine for occasional analysis rather than reserving it for daily users.

For a narrow bug with a reliable failing test, both tools are often good enough. The deciding factor becomes latency and interruption rate. If the agent reads the test, finds the production path, makes one edit, and reruns the focused check, model differences barely matter. A concise project instruction file matters more.

For a cross-package refactor, Gemini's appetite for broad evidence can help locate all call sites, but it can also expand the task. Claude often keeps the change more local, though that same restraint can miss a distant integration point. Require a repository search for the old symbol after the edit and make the full type check part of acceptance. Tool preference cannot replace a migration invariant.

For frontend work, neither terminal agent sees what a human sees unless you provide a browser or screenshot loop. A component that compiles can still have broken focus order, clipped text, or a mobile layout failure. Give the agent an executable visual check or keep a human in the loop. Judging frontend skill from source diffs alone rewards confident guessing.

For operations and infrastructure, permission design dominates model quality. The agent should be allowed to read manifests, render templates, validate configuration, and inspect sanitized logs. It should not hold production credentials or run deployment commands during an ordinary coding session. Plan output can be useful, but a plausible shell command is not evidence that the command is safe for your environment.

For large log analysis or generated code, preprocess first. Give either agent the smallest slice that preserves the failure. Large context windows tempt teams to paste everything, which increases cost and buries causal order. A twenty-line timeline of the first error and its request identifier beats a hundred thousand lines of repeated retries.

My aggregate preference is therefore conditional: Claude Code for the main implementation loop, Gemini CLI for broad investigation and a low-cost second opinion. A different repository can reverse it. The only opinion I would defend without a trial is that teams should not grant either one production authority just because its code output looks mature.

## The worst failures look productive

The dangerous run is not the one that crashes. It is the one that edits many files, runs several commands, and reports success while solving a nearby problem. Activity makes weak reasoning harder to notice.

Gemini CLI can over-collect. In a large repository it may read many related files, form a broad architectural theory, and then change more layers than the issue requires. The correction is a tighter scope, explicit generated-code exclusions, and an acceptance test tied to public behavior. If the agent keeps widening the search after it has a reproducible failure, ask it to state the smallest causal chain before editing.

Claude Code can become locally persuasive. It may settle on a theory early, preserve that theory through compaction, and interpret later failures as details to patch around. The correction is to require a fresh hypothesis after repeated failure and to clear the session when the task changes. A long conversation is not accumulated wisdom if its first assumption was wrong.

Both agents can pass the wrong test. I have seen coding agents update snapshots, loosen assertions, replace integration tests with mocks, and declare the original behavior fixed. Put test integrity in the acceptance criteria: the regression test must fail on the base commit and pass on the proposed change. Review test changes before production changes because they define what victory means.

Recovery controls also have boundaries. Claude Code checkpoints do not track files changed through arbitrary Bash commands. Gemini checkpointing is disabled by default and must be configured. Neither feature replaces Git. Use a clean worktree, inspect `git diff`, and commit only after human review. A rewind button is useful; a known starting commit is proof.

## Choose a team default and preserve an escape hatch

A team should standardize the safety envelope, evaluation method, and repository instructions before it standardizes the vendor. This creates comparable behavior and keeps a future switch affordable.

Choose Claude Code as the default when senior engineers spend most of their agent time implementing ambiguous changes, the repository has good tests, and the team accepts a paid seat for regular use. Its permission controls, scoped instructions, compaction behavior, and recovery flow support a disciplined implementation loop. Budget against accepted issues, then move heavy users to a higher plan only when the work justifies it.

Choose Gemini CLI as the default when broad analysis is common, Google Cloud identity and tooling already shape the environment, or the organization needs a credible free entry path. Its policy engine deserves serious attention from platform teams. Test the exact authentication route you will deploy because personal sign-in, organizational Code Assist, API keys, and Vertex AI have different quotas, billing, and data terms.

Keep both when the second tool has a defined job. Useful pairings include one agent implementing and the other reviewing the diff, or Gemini mapping a migration while Claude performs a bounded package change. Do not run two agents concurrently in the same worktree. Use separate worktrees and compare results before merging, or they will overwrite files and contaminate each other's evidence.

At oleg.is, I evaluate these tools as parts of an engineering operating system, not as isolated subscriptions. A Team & AI Audit is justified only if it identifies which work can move to agents, which controls must stay human, and what the accepted-task economics look like.

The first rollout should cover a small group, a fixed issue set, and one month of review data. Record interventions and rejected changes without blaming users for using the tool differently. Variation tells you where instructions, permissions, or issue quality are weak. Standardize the parts that reduce variance, then allow engineers to choose the better agent for unusual work.

## Production use needs a written operating policy

A written policy turns agent choice into an engineering decision that can survive staff changes and product updates. It should fit on one page and name the boundary of autonomous work.

State where agents may run, which repositories they may access, how worktrees are created, and which credentials are absent. List commands that run without approval and commands that never run from an agent session. Require a clean base commit, issue-specific acceptance criteria, focused tests, a diff review, and human ownership of the final commit. Define how transcripts and usage data are retained under your company's policies.

Add one rule for context: persistent repository facts live in the agent instruction file, while temporary issue details live in the task. Add one rule for failure: after two attempts with the same hypothesis, the agent must stop or restate the evidence. Add one rule for cost: measure accepted output and reviewer time, not raw token totals alone.

Re-run the four-task trial after a major model or client change, or when team metrics drift. Keep the old results so you can tell whether the product changed or the issue mix changed. Vendor release notes can tell you that a feature exists. Only your harness can tell you whether it improved your work.

If you must choose today without a pilot, use Claude Code for the primary implementation seat and install Gemini CLI for exploration under the free quota. Then schedule the trial. The default is a starting position, not a verdict, and the first rejected production diff will teach you more than another comparison chart.