Compare
grr measured against the other Google Workspace CLIs. Every number below was actually run — no vendor benchmarks, no estimates. Where grr is behind, the table says so; where a claim could not be verified, it says that instead.
How to read this
Measured metrics are credential-free by design: process startup (--version), the
grr schema JSON contract dump, the grr api list method index,
binary size on disk and peak memory. Nothing here needs a Google account or a network
round-trip, which is what makes a daily CI benchmark possible without flakes.
Protocol per metric: the first run is a discarded warm-up, then
15
timed runs using process.hrtime.bigint() around the process; median, p95 and
min are reported. Every tool gets the identical protocol on the same machine. A run whose
medians land within the noise band (max(15 ms, 6%)) of the committed snapshot rewrites
nothing, so small differences are noise, not news. The benchmark re-runs whenever a new
version of grr, gog or gws ships — the workflow watches each project's release tags and
rebuilds on change — so the numbers follow the tools rather than a one-time snapshot.
Peak memory is max RSS: the maximum resident set size across the same runs,
read from the platform's /usr/bin/time (GNU -v on Linux, BSD
-l on macOS) while each tool runs its schema-dump command — each tool's schema-dump command (grr schema / gog schema / gws schema drive.files.list --resolve-refs) — not --version, which is too trivial a workload to separate the tools. It is a single
high-water mark per run, so the highest is reported rather than a median. This is the
figure that competes with local models and agents sharing unified memory: every megabyte a
CLI holds is one they cannot. All memory figures come from the same locally built
(unpacked) grr binary as the timings; the packed release artifact is not separately
re-measured for memory, and that basis is stated rather than assumed.
Binary size is the number users actually install. grr's release artifact is UPX-packed when the packer succeeds, so the size shown is the shipped artifact, with the unpacked build in the tooltip; the timings and peak memory above come from the unpacked build, which is what the benchmark runs. Competitor sizes are their official release builds, as shipped — so the "smallest" claim compares like with like. When a snapshot has no release artifact (no tag yet, or offline), the row falls back to the unpacked build and says so.
Feature matrix cells are verified against each project's own documentation and, where possible, a running release binary — sources are listed under the table. "Not documented" means exactly that: the claim could not be verified from their docs, so it is neither confirmed nor denied.
- measured on
- linux / arm64
- grr binary
- release · grr 2.5.1
- latest releases
- grr v2.5.1 · gog v0.48.0 · gws v0.22.5
- node
- v26.13.0
- warm-up
- 1 run discarded per metric
The numbers
Medians of 15 runs on the machine named above. A missing card value means the command is not present in the measured binary — the reason is printed, never padded.
| tool | startup median | startup p95 | startup min | schema dump | api index | peak memory | binary size |
|---|---|---|---|---|---|---|---|
| grr grr 2.5.1 | 5.5 ms | 6.2 ms | 5.3 ms | 19.5 ms | 22.6 ms | 16.2 MB | 3.1 MB |
| gog v0.48.0 (f939ed37 2026-11-05T20:20:32Z) | 72.2 ms | 72.6 ms | 71.7 ms | 157.5 ms | — | 101.7 MB | 39.6 MB |
| gws gws 0.22.5 | 28.2 ms | 30.5 ms | 27.1 ms | 30 ms | — | 47.1 MB | — |
Snapshot generated from a locally built release binary . Competitor binaries are their official GitHub release builds, as shipped ; grr’s size is its own shipped release artifact, its timings and memory the unpacked build. The benchmark script
What each tool actually offers
Verified against each project’s own documentation and running binaries — grr’s cells were re-verified against the current build. Where grr trails, the row says so; where it leads, the row says that too.
| feature | grr | gog | gws | Google Workspace MCP servers |
|---|---|---|---|---|
| Coverage | 402 methods across the 14 consumer Workspace APIs — every Workspace API a consumer account can actually authorise (domain-locked services like Classroom and Meet are deliberately out of scope) — generated from a Discovery index committed to the repo, works offline | 27 services, incl. Classroom, Meet, Analytics, Ads, YouTube | Every Workspace API — command surface built from Google’s live Discovery Service at runtime | n/a — fixed per-product toolsets |
| Natural-language entry | Yes — grr ask "<request>": a System One model (Jev by default, provider-agnostic config) picks service → method and fills each required parameter from code-supplied candidates via one typed question; the plan prints by default, --run executes it. Neither competitor documents an equivalent | Not documented | Not documented | n/a — the MCP client is the interface |
| MCP server | Yes — grr mcp: all 402 methods as typed MCP tools over stdio (inputSchema from Discovery); --readonly for a read-only server; tools/call runs the same call path as grr api call | Yes — gog mcp, typed stdio, read-only by default | No — v0.22.5 has no mcp command; no MCP section in its README | Is one — hosted remote servers (Developer Preview) |
| Agent skills | Yes — packaged skills/grr/SKILL.md (discover-first discipline, the naming rule, the output contract); npx skills add https://github.com/debanjanbasu/grr-cli | Yes — schema, reference pages and skills generated from the same command tree | Yes — 100+ SKILL.md files, one per API, plus 50 curated recipes | n/a — agents connect directly via MCP |
| Multi-account | Yes — named accounts (--account work) keep a separate token each in the OS keyring | Yes — accounts, aliases, keyring-stored tokens | Not documented | n/a |
| Safety profiles | Global --readonly, --deny-service and --deny-verb flags, honored by every entry point: the command tree, grr api call, grr ask and grr mcp | Global --readonly and --no-input, exact command allowlists, Gmail no-send policy, dry-run plans; build-time Safety Profiles documented | Not documented | n/a — per-server OAuth scopes |
| HTTP/3 (QUIC) | Always on, HTTP/2 fallback — the only tool in this table that documents HTTP/3 | Not documented | Not documented | n/a |
| Zero-config OAuth | Yes — release binaries ship the client compiled in (source builds run grr auth setup) — the only one in this table | No — create your own Desktop OAuth client in Google Cloud | No — GCP project + OAuth client required (auth setup) | No — own GCP project, OAuth consent screen and Web client per server |
| Runtime dependencies | None — single static binary | None — single binary | Node 18+ for npm install; pre-built binaries also published | No CLI to install — any MCP client |
| Binary size (as shipped) | 3.1 MB | 39.6 MB | — launcher shim, not a binary (852 B) | n/a — hosted service |
| Language | Rust | Go | Rust | Hosted service |
| License | MIT | MIT | Apache-2.0 | Developer Preview terms |
Where the others still win: gog covers 27 services — including domain-locked enterprise APIs like Classroom and Meet that a consumer account cannot authorise and that grr deliberately leaves out. gws covers every Workspace API, not just the consumer 14 — its command surface is rebuilt from Google's live Discovery Service, so when Google adds a method, gws has it without a release — and it ships 100+ agent skills. Google's remote MCP servers need no local install at all.
Where grr goes further: grr ask takes a request in plain words; a System One
model (Jev by default) classifies the service and the method, then fills each required
parameter by asking one typed question with every candidate code-supplied — the model can
only select. Neither competitor documents anything like it. grr mcp exposes
all 402 methods as typed MCP tools and runs them through the same call path as
grr api call, behind the same --readonly,
--deny-service and --deny-verb gates as the rest of the CLI.
Named accounts keep separate tokens in the OS keyring. HTTP/3 is always on with HTTP/2
fallback, release binaries ship the OAuth client compiled in so the first run is
zero-config — the size row above is
computed from the same snapshot, not typed by hand.
Peak memory is the figure that competes with the local models and agents sharing unified memory on a modern machine: every megabyte a CLI holds is one they cannot. On this snapshot the schema dump peaks at grr 16.2 MB · gog 101.7 MB · gws 47.1 MB of resident memory — each tool's own closest-equivalent workload, measured rather than assumed, and never a synthetic one.
The original bet is unchanged: the command tree is generated from a Discovery index committed to the repository — reviewable in a diff, working offline, refreshed by a daily workflow — rather than rebuilt from live Discovery at runtime.
Sources: gog cells from its README (quick start, accounts, MCP guide, safety) plus
gog auth services and gog --help on the v0.43.0 release binary;
gws cells from its README and gws --help / gws auth --help on the
0.22.5 release binary — which answers "Unknown service mcp" to gws mcp — and
its LICENSE file; Google server cells from Google's configure-mcp-servers guide
(Developer Preview). grr cells re-verified against the current binary:
grr mcp --help, a live initialize + tools/list handshake (402 tools, each
with an inputSchema), grr ask --help, grr auth login --help,
grr auth status --help, and --readonly / --deny-verb
refusal checks. The binary-size and peak-memory rows read the same measured snapshot as
the table above.
Unverifiable claims are labelled "Not documented" rather than guessed.