[nwparker]

	Files	Added	Deleted	Net
Test	4	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​123	0	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​123
Prod	11	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​74	$\color{#cf222e}{\Huge{\mathbf{−}}}$​27	$\color{#1a7f37}{\Huge{\mathbf{+}}}$​47

Latest verification — 2026-09-20: The actual guarded fetcher and rendered Usage menu now show two populated native quota buckets (Gemini Models weekly 10%, Claude/GPT weekly 0%): live proof. Earlier fixture/empty-group screenshots remain historical evidence, not the limit of current validation. No account switching or remote quota verification is claimed. All checks at the unchanged PR head are green. Earlier screenshots and test notes below describe their original runs.

ELI5

If you tell Orca where your Antigravity executable lives, quota refresh should use it and keep its usage controls available. Previously, launching used your setting while quota refresh silently looked for plain agy elsewhere.

What Changed

Quota refresh now reads the execution runtime’s configured Antigravity command each cycle. Executable paths, including quoted paths with spaces, use the same executable for the version check and /usage. Changing the command drops an in-flight response or cached quota from the previous executable.

Commands with extra arguments now show an explicit unavailable explanation. They are neither executed as quota commands nor replaced with an unrelated agy installation. This does not change interactive launch behavior.

The Antigravity usage entry and visibility checkbox also remain available when a custom command is configured but PATH detection finds no agy. The existing checkbox still controls whether the entry is shown.

Why

Reuses the existing command parser and executable resolver, plus the bounded process runner. Appending quota flags to arbitrary launch arguments could execute another prompt; silently discarding those arguments could select another account. A plain executable path or a wrapper executable that accepts agy’s flags is supported; arbitrary argument-bearing launchers are not yet supported for quota.

Linked Issue

Refs #9122, #19561, #21541, #7809. Stacked on #21672; native quota source originally added in #21654.

Visual Proof

Actual hidden Orca Usage panel, same temporary argument-bearing launch override. Before, quota ignored it and queried the default agy; after, it explains the unsupported command. These are live empty-quota/error states, not populated account fixtures.

Before:

After:

Configured-command visibility with an explicitly simulated empty detection list (renderer fixture, not live PATH detection):

The actual menu checkbox was checked, unchecked, and checked again; the entry hid and reappeared accordingly. Fixture state was restored.

Testing

• I manually tested these changes locally
• Automated tests added/updated

38 focused resolver/fetcher/service tests passed; 42 service/account/refresh tests passed (overlapping suites). Full pnpm tc, changed-code quality gate and commit hooks passed. Hidden Electron/Vite development build succeeded.

Installed agy 1.2.7 on macOS, through a wrapper executable in a path with spaces: both the bundled production fetcher and rebuilt app called the wrapper with --version, then --print /usage --output-format json. Actual CLI returned empty quota groups, correctly unavailable. Runtime settings were restored; credentials and global hooks were untouched. Windows path parsing is unit-tested; no native Windows/Linux/WSL/SSH execution or populated OAuth quota is claimed.

Follow-up visibility change: 35 gating/provider-visibility tests, renderer typecheck, changed-code quality and commit hooks passed. Actual hidden UI menu/toggle verified with the renderer fixture above. No component styling changed.

Review

No shell execution added. Existing version floor, output limits, timeouts and cancellation remain. Unsupported commands do not fall back to another installation. Regression tests cover command changes during a request and failure after replacing the executable.

Agent skill upstream boundary

• Not applicable; no upstream skill source copied.

Notes

The rate-limit service uses its owning runtime’s settings and filesystem. This does not add direct SSH quota transport or change remote wire fields; it does not depend on a Git worktree. Existing paired clients receive the same result shape. Full authenticated account migration remains outside this fix.

Checklist

• This PR is small and focused
• I explained what changed and why
• Before/after screenshots attached
• Self-reviewed for correctness, security, and performance
• Cross-platform, SSH/remote, and path impact considered
• Focused tests, full typecheck, changed-code quality and development build passed; CI will cover remaining gates

[nwparker]

Authenticated follow-up, 2026-09-20: the exact branch usage fetcher now returns status: ok, two populated native Antigravity buckets, and no error. Refreshed the hidden Orca renderer and inspected the Usage menu: Gemini Models weekly 10% used; Claude and GPT models weekly 0% used. This supersedes the earlier empty-quota-only limitation. Account add/select/persistence remains outside this verification.

[nwparker]

Independent verification (2026-09-20):

• Quota command/fetcher/service/status-bar suites: 187/187 passed.
• pnpm tc:node and pnpm tc:web passed.
• pnpm run check:code-quality:changed origin/main passed with 0 new findings across 160 changed files.
• Full CI run 35445277063 is green across all eight test shards, typecheck, static analysis, both packages, and verify.

Verdict: approve after stack order with #21654 for configured executable resolution and quota visibility. This verifies resolver/UI behavior and CI; live remote or multi-account quota remains unverified. No merge performed.

[nwparker]

ELI5 / evidence / trade-offs audit

ELI5: Orca lets the user choose which agy executable to run, so a custom install can be used without changing code.

Proof: Executable-resolution tests, authenticated agy verification, and CI pass; no distinct UI artifact was available for this plumbing change.

User-facing trade-off: A misconfigured custom path can fail at launch and now reports that failure directly.

This note scopes the claim to the evidence above; it does not claim untested remote, SSH, WSL, or vendor combinations.

[pullfrog]

ℹ️ Two rough edges worth a look — both about consistency, nothing blocking.

Reviewed changes

• Configured executable now drives quota — resolveAntigravityUsageCommand resolves the user's agentCmdOverrides.antigravity (reusing planAgentBinary + resolveCliCommand) and runs both --version and /usage through it. Arg-bearing or unresolved commands return an explicit unavailable result instead of falling back to a PATH agy.
• Command-change invalidation — preparation captures the command and a changed flag, clears the fetching snapshot on change, and application drops the result if the resolver moved mid-cycle, so one executable's quota is never attributed to another.
• Custom-command visibility — isStatusBarItemAvailable gains an optional settings argument so the Antigravity entry shows when a custom command is configured but PATH detection misses agy.

  ^{｜ Fix all ➔ ｜ Fix 👍s ➔ ｜ View workflow run ｜ Using DeepSeek Flash (free via Pullfrog for OSS) ｜ 𝕏}

[pullfrog]

This makes the status bar's own visibility menu show the entry, but the Appearance settings pane still hides it: useAvailableStatusBarToggles filters through isStatusBarItemAvailable(t.id, detectedAgentIds) without settings, so an Antigravity toggle stays hidden there when PATH detection misses agy even though a custom command is configured. Thread settings through that hook so both visibility surfaces agree.

Technical details

# Appearance-pane toggle still PATH-gated

## Affected sites
- `src/renderer/src/components/status-bar/use-available-status-bar-toggles.ts:11` — `isStatusBarItemAvailable(t.id, detectedAgentIds)`, no settings argument.
- `src/renderer/src/components/settings/AppearanceWindowSidebarSection.tsx:75` — sole production caller; `settings` is already a prop here but not forwarded.
- `src/renderer/src/components/settings/appearance-status-bar-search.ts:103` — `getStatusBarToggles()` includes the `antigravity` toggle, so it is in the filtered list.

## Required outcome
- With `agentCmdOverrides.antigravity` non-blank and PATH detection missing `agy`, the Antigravity switch is listed in Settings → Appearance → Status Bar, matching the status bar menu.

## Suggested approach
- Give `useAvailableStatusBarToggles` the same optional settings shape and pass it from `AppearanceWindowSidebarSection`.

[pullfrog]

Changing agentCmdOverrides.antigravity does not invalidate the current snapshot, so the previous executable's cached quota stays in getState() until the next full poll — up to 15 minutes, longer while polling is suspended. The MiniMax block just above already invalidates + refreshes on its settings keys; doing the same for the Antigravity command makes the PR's "cached quota is dropped" behavior immediate rather than deferred to the next cycle.

Technical details

# Antigravity snapshot not invalidated on command change

## Affected sites
- `src/main/startup/main-process-account-services.ts:84-104` — `onSettingsChanged` handles MiniMax keys only; `agentCmdOverrides` is not checked.
- `src/main/rate-limits/service/service-full-cycle-application.ts:199-204` — the drop happens on the next cycle's apply, not at settings-change time.
- `src/renderer/src/store/slices/rate-limits.ts` — `refreshRateLimits` is only invoked by the manual refresh button, so the renderer does not refresh on this settings write.

## Required outcome
- After the configured command changes, the status bar must not keep displaying the prior executable's quota while waiting for the next poll.

## Suggested approach
- In the settings hook, when `'agentCmdOverrides' in updates` and the antigravity entry changed, invalidate/clear the antigravity snapshot and trigger a refresh, mirroring the MiniMax branch.