The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point in your pull request via creating an issue comment (i.e. comment on the pull request page) using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

src/commands/statusline.ts (1)

288-289: Optional: simplify toggles using includes()

This is equivalent today and a bit more compact. Only consider if you don't plan to introduce overlapping substrings like "text-short" later (not blocking).

-const renderEmojiStatus = ctx.values.visualBurnRate === 'emoji' || ctx.values.visualBurnRate === 'emoji-text';
-const renderTextStatus = ctx.values.visualBurnRate === 'text' || ctx.values.visualBurnRate === 'emoji-text';
+const renderEmojiStatus = ctx.values.visualBurnRate.includes('emoji');
+const renderTextStatus = ctx.values.visualBurnRate.includes('text');

src/commands/statusline.ts (1)

293-300: 5000 boundary: code vs. docs/canonical thresholds mismatch

Current code treats 5,000 tpm as High (since it’s the “else” after < 5000), while docs say High is “> 5,000” (i.e., 5,000 is Moderate). Also, there’s a known preexisting mismatch with canonical thresholds elsewhere. Not blocking for this PR, but worth aligning.

Two paths (pick one; I can open a follow-up issue if you want):

• Keep current code and fix docs to say “≥ 5,000” and “2,000–4,999”.
• Or switch to canonical constants and comparison direction used elsewhere.

Proposed code change (if aligning to canonical constants; otherwise ignore and just adjust docs):

-const burnStatus: BurnStatus = burnRate.tokensPerMinuteForIndicator < 2000
-  ? 'normal'
-  : burnRate.tokensPerMinuteForIndicator < 5000
-    ? 'moderate'
-    : 'high';
+const burnStatus: BurnStatus =
+  burnRate.tokensPerMinuteForIndicator > BURN_RATE_THRESHOLDS.HIGH
+    ? 'high'
+    : burnRate.tokensPerMinuteForIndicator > BURN_RATE_THRESHOLDS.MODERATE
+      ? 'moderate'
+      : 'normal';

If you choose this, also update the existing import to bring in the thresholds (outside this hunk):

import { BURN_RATE_THRESHOLDS, DEFAULT_REFRESH_INTERVAL_SECONDS } from "../_consts.ts";

If you prefer to keep the current logic, I recommend we update the docs’ “Output Format” thresholds to:

• Green: Normal (< 2,000 tokens/min)
• Yellow: Moderate (2,000–4,999 tokens/min)
• Red: High (≥ 5,000 tokens/min)

docs/guide/statusline.md (1)

164-176: Nit: use a “text” fence for output examples

These are outputs, not shell commands. “text” (or no language) better conveys that.

-```bash
+```text
 # Default (off)
 🔥 $0.12/hr

 # With emoji
 🔥 $0.12/hr 🟢

 # With text  
 🔥 $0.12/hr (Normal)

 # With both emoji and text
 🔥 $0.12/hr 🟢 (Normal)

</blockquote></details>

</blockquote></details>

<details>
<summary>📜 Review details</summary>

**Configuration used: CodeRabbit UI**
**Review profile: CHILL**
**Plan: Pro**

**💡 Knowledge Base configuration:**

- MCP integration is disabled by default for public repositories
- Jira integration is disabled by default for public repositories
- Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

<details>
<summary>📥 Commits</summary>

Reviewing files that changed from the base of the PR and between 192afc34a385722b5cd5f9d8e70bde176a01d3dd and 4267df17e298d19cf9b9fb7f2b7cd689f9dfa3e5.

</details>

<details>
<summary>📒 Files selected for processing (2)</summary>

* `docs/guide/statusline.md` (3 hunks)
* `src/commands/statusline.ts` (4 hunks)

</details>

<details>
<summary>🧰 Additional context used</summary>

<details>
<summary>📓 Path-based instructions (2)</summary>

<details>
<summary>docs/guide/*.md</summary>


**📄 CodeRabbit Inference Engine (CLAUDE.md)**

> Use image paths like "/screenshot.png" for images stored in /docs/public/ and always include descriptive alt text

Files:
- `docs/guide/statusline.md`

</details>
<details>
<summary>**/*.{ts,tsx}</summary>


**📄 CodeRabbit Inference Engine (CLAUDE.md)**

> `**/*.{ts,tsx}`: Use tab indentation and double quotes; format with ESLint
> Do not use console.log; use logger.ts instead (only allow console.log when explicitly eslint-disabled)
> Use .ts extensions for local file imports (e.g., import { foo } from "./utils.ts")
> Prefer @praha/byethrow Result type over traditional try-catch; use Result.try(), Result.isFailure()/isSuccess() and early returns; reserve try-catch for complex file I/O or legacy code
> For async operations, wrap with a function using Result.try() and call it
> Variables use camelCase; Types use PascalCase; Constants may use UPPER_SNAKE_CASE
> Only export constants/functions/types that are used by other modules; keep internal/private items non-exported
> Always use Node.js path utilities for file paths for cross-platform compatibility
> Use in-source testing blocks guarded by if (import.meta.vitest != null); do not create separate test files
> Use Vitest globals (describe, it, expect) without imports inside test blocks
> Only use dynamic imports (await import()) inside test blocks to avoid tree-shaking issues
> Mock data in tests should use fs-fixture createFixture() for Claude data directory simulation
> Tests must use current Claude 4 models (Sonnet and Opus) and cover both; do not use Claude 3 models
> Model names in tests must exactly match LiteLLM pricing database entries

Files:
- `src/commands/statusline.ts`

</details>

</details><details>
<summary>🧠 Learnings (1)</summary>

<details>
<summary>📚 Learning: 2025-07-20T23:46:21.740Z</summary>

Learnt from: AsPulse
PR: #328
File: src/_live-rendering.ts:133-167
Timestamp: 2025-07-20T23:46:21.740Z
Learning: When AsPulse points out that variables are clearly type-inferred as strings from their construction (using template literals, string methods like .toFixed(), .padStart(), etc.), avoid suggesting unnecessary type assertions that would reduce code readability. ESLint type safety errors about "error type" often indicate type definition issues with imported packages rather than actual type problems in the user's code.

**Applied to files:**
- `src/commands/statusline.ts`

</details>

</details><details>
<summary>🧬 Code Graph Analysis (1)</summary>

<details>
<summary>src/commands/statusline.ts (1)</summary><blockquote>

<details>
<summary>src/_utils.ts (1)</summary>

* `formatCurrency` (305-307)

</details>

</blockquote></details>

</details><details>
<summary>🪛 LanguageTool</summary>

<details>
<summary>docs/guide/statusline.md</summary>

[grammar] ~162-~162: There might be a mistake here.
Context: ...mbine both emoji and text indicators  **Examples:**  ```bash # Default (off) 🔥 $0...

(QB_NEW_EN)

---

[grammar] ~178-~178: There might be a mistake here.
Context: ...hr 🟢 (Normal) ```  **Status Indicators:** - 🟢 Normal (Green) - ⚠️ Moderate (Yellow)...

(QB_NEW_EN)

---

[grammar] ~180-~180: There might be a mistake here.
Context: ...tus Indicators:** - 🟢 Normal (Green) - ⚠️ Moderate (Yellow) - 🚨 High (Red)  ## ...

(QB_NEW_EN)

---

[grammar] ~181-~181: There might be a mistake here.
Context: ...Normal (Green) - ⚠️ Moderate (Yellow) - 🚨 High (Red)  ## Troubleshooting  ### No ...

(QB_NEW_EN)

</details>

</details>
<details>
<summary>🪛 ESLint</summary>

<details>
<summary>src/commands/statusline.ts</summary>

[error] 288-288: Unsafe member access .values on an `any` value.

(ts/no-unsafe-member-access)

---

[error] 288-288: Unsafe member access .values on an `any` value.

(ts/no-unsafe-member-access)

---

[error] 289-289: Unsafe member access .values on an `any` value.

(ts/no-unsafe-member-access)

---

[error] 289-289: Unsafe member access .values on an `any` value.

(ts/no-unsafe-member-access)

---

[error] 302-302: Unsafe assignment of an error typed value.

(ts/no-unsafe-assignment)

---

[error] 302-302: Unsafe member access .green on an `error` typed value.

(ts/no-unsafe-member-access)

---

[error] 303-303: Unsafe assignment of an error typed value.

(ts/no-unsafe-assignment)

---

[error] 303-303: Unsafe member access .yellow on an `error` typed value.

(ts/no-unsafe-member-access)

---

[error] 304-304: Unsafe assignment of an error typed value.

(ts/no-unsafe-assignment)

---

[error] 304-304: Unsafe member access .red on an `error` typed value.

(ts/no-unsafe-member-access)

---

[error] 307-307: Unsafe object destructuring of a property with an error typed value.

(ts/no-unsafe-assignment)

---

[error] 309-311: Unsafe assignment of type `any[]` to a variable of type `string[]`.

(ts/no-unsafe-assignment)

---

[error] 310-310: Unsafe call of a(n) `error` type typed value.

(ts/no-unsafe-call)

---

[error] 318-318: Unsafe argument of type error typed assigned to a parameter of type `string`.

(ts/no-unsafe-argument)

---

[error] 318-318: Unsafe call of a(n) `error` type typed value.

(ts/no-unsafe-call)

</details>

</details>

</details>

<details>
<summary>🔇 Additional comments (5)</summary><blockquote>

<details>
<summary>src/commands/statusline.ts (4)</summary>

`71-71`: **LGTM: clear, typed choices for visual burn-rate modes**

The `as const` array gives you a nice string-literal union for downstream inference. Good call.

---

`82-90`: **CLI arg wiring looks solid and consistent with docs**

Enum choices, default `off`, `short: 'vb'`, and `toKebab: true` match the documented UX. Nice.

---

`301-308`: **LGTM: mapping typed against picocolors Formatter**

The mapping is clear and correctly typed; the picocolors formatters are appropriate here. Any “error typed value” warnings from static analyzers around `pc.*` are likely environment false-positives—no action needed.

---

`309-321`: **Rendering pipeline reads cleanly and preserves back-compat**

Base colored cost-per-hour plus optional emoji/text segments is straightforward and keeps default behavior unchanged. Good ergonomics.

</details>
<details>
<summary>docs/guide/statusline.md (1)</summary>

`47-62`: **Nice quick-start snippet for visual indicators**

Good placement and clear cross-link to the full section. Matches the new CLI flag.

</details>

</blockquote></details>

</details>

<!-- This is an auto-generated comment by CodeRabbit for review status -->

src/commands/statusline.ts (6)

72-73: Nice: explicit, closed set of choices for visualBurnRate.

Clear, forward-compatible enum. Consider exporting a local alias for reuse where needed.

Apply this diff to introduce a reusable type alias:

-const visualBurnRateChoices = ['off', 'emoji', 'text', 'emoji-text'] as const;
+const visualBurnRateChoices = ['off', 'emoji', 'text', 'emoji-text'] as const;
+type VisualBurnRate = typeof visualBurnRateChoices[number];

---

83-91: CLI arg looks good; verify multi-letter short flag and consider removing redundant toKebab.

• short: 'vb' is convenient, but some parsers only allow single-char shorts. Please confirm gunshi supports multi-letter short aliases for flags.
• You already enabled toKebab: true at the command level; repeating it here is likely redundant.

Would you confirm locally that the following variants work end-to-end?

• bun run start statusline -vb emoji
• bun run start statusline --visual-burn-rate emoji
• bun run start statusline --visual-burn-rate=emoji

If -vb is not supported, fall back to a single-letter alias (e.g., -v) or omit the short flag.

Optional cleanup:

 		visualBurnRate: {
 			type: 'enum',
 			choices: visualBurnRateChoices,
 			description: 'Controls the visualization of the burn rate status',
 			default: 'off',
 			short: 'vb',
 			negatable: false,
-			toKebab: true,
 		},

---

294-296: Tighten types for ctx.values access to avoid ts/no-unsafe-member-access warnings.

Static analysis flags ctx.values.* as any. A minimal, local narrowing removes the noise without changing behavior.

-											const renderEmojiStatus = ctx.values.visualBurnRate === 'emoji' || ctx.values.visualBurnRate === 'emoji-text';
-											const renderTextStatus = ctx.values.visualBurnRate === 'text' || ctx.values.visualBurnRate === 'emoji-text';
+											const visualBurnRate = ctx.values.visualBurnRate as VisualBurnRate;
+											const renderEmojiStatus = visualBurnRate === 'emoji' || visualBurnRate === 'emoji-text';
+											const renderTextStatus = visualBurnRate === 'text' || visualBurnRate === 'emoji-text';

Note: I’m purposefully keeping the assertion scoped to this value to avoid bleeding assertions elsewhere. If you’d rather avoid any assertions, a small type guard like function isVisualBurnRate(x: string): x is VisualBurnRate using visualBurnRateChoices.includes(x) would also work.

---

299-305: Avoid hardcoded thresholds; use canonical BURN_RATE_THRESHOLDS and align comparison direction.

This block re-encodes thresholds (2000/5000) and "<" direction, which has been inconsistent with the canonical constants/logic elsewhere. Import BURN_RATE_THRESHOLDS and use the same ">" direction for consistency and single source of truth.

-											type BurnStatus = 'normal' | 'moderate' | 'high';
+											type BurnStatus = 'normal' | 'moderate' | 'high';
 
-											const burnStatus: BurnStatus = burnRate.tokensPerMinuteForIndicator < 2000
-												? 'normal'
-												: burnRate.tokensPerMinuteForIndicator < 5000
-													? 'moderate'
-													: 'high';
+											const burnStatus: BurnStatus = burnRate.tokensPerMinuteForIndicator > BURN_RATE_THRESHOLDS.HIGH
+												? 'high'
+												: burnRate.tokensPerMinuteForIndicator > BURN_RATE_THRESHOLDS.MODERATE
+													? 'moderate'
+													: 'normal';

And update the import at the top accordingly:

-import { DEFAULT_REFRESH_INTERVAL_SECONDS } from '../_consts.ts';
+import { DEFAULT_REFRESH_INTERVAL_SECONDS, BURN_RATE_THRESHOLDS } from '../_consts.ts';

If you prefer to keep this PR focused, I can open a follow-up issue to track harmonizing burn-rate thresholds across modules.

---

307-314: Use satisfies to keep types precise and avoid picocolors typing warnings.

Explicitly annotating the mapping with Record<..., Formatter> is tripping static analysis (pc.* seen as error-typed). The satisfies operator preserves type safety without forcing a type on pc.* functions.

-											const burnStatusMappings: Record<BurnStatus, { emoji: string; textValue: string; coloredString: Formatter }> = {
-												normal: { emoji: '🟢', textValue: 'Normal', coloredString: pc.green },
-												moderate: { emoji: '⚠️', textValue: 'Moderate', coloredString: pc.yellow },
-												high: { emoji: '🚨', textValue: 'High', coloredString: pc.red },
-											};
+											const burnStatusMappings = {
+												normal: { emoji: '🟢', textValue: 'Normal', coloredString: pc.green },
+												moderate: { emoji: '⚠️', textValue: 'Moderate', coloredString: pc.yellow },
+												high: { emoji: '🚨', textValue: 'High', coloredString: pc.red },
+											} satisfies Record<BurnStatus, { emoji: string; textValue: string; coloredString: (s: string) => string }>;

This keeps the same runtime behavior, eliminates the "error type" cascade, and lets you drop the dedicated Formatter import.

---

1-1: Remove now-unused Formatter import if you adopt the satisfies refactor.

If you switch the mapping to use satisfies with a simple string->string function type, this import becomes unused.

-import type { Formatter } from 'picocolors/types';

Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro

💡 Knowledge Base configuration:

• MCP integration is disabled by default for public repositories
• Jira integration is disabled by default for public repositories
• Linear integration is disabled by default for public repositories

You can enable these sources in your CodeRabbit configuration.

Learnt from: AsPulse
PR: ryoppippi/ccusage#328
File: src/_live-rendering.ts:133-167
Timestamp: 2025-07-20T23:46:21.740Z
Learning: When AsPulse points out that variables are clearly type-inferred as strings from their construction (using template literals, string methods like .toFixed(), .padStart(), etc.), avoid suggesting unnecessary type assertions that would reduce code readability. ESLint type safety errors about "error type" often indicate type definition issues with imported packages rather than actual type problems in the user's code.