Update Usage View to Yearly Refresh

[ngoiyaeric]

User description

This change updates the Usage component to reflect a shift from a daily refresh model to a yearly one. It also updates the sample usage history with new task names, 'upcoming' dates, and revised credit consumption values. verified via frontend screenshot.

---

PR created automatically by Jules for task 14763946411330416327 started by @ngoiyaeric

---

PR Type

Enhancement

---

Description

• Updated refresh model from daily to yearly credits

• Changed refresh credit amount from 300 to 500

• Replaced sample task list with new QCX-TERRA and Green OS tasks

• Updated task dates and credit consumption values

---

Diagram Walkthrough

flowchart LR
  A["Daily Refresh<br/>300 credits"] -- "Convert to yearly model" --> B["Yearly Refresh<br/>500 credits"]
  C["Old Task List<br/>Large credit values"] -- "Replace with new tasks" --> D["QCX-TERRA & Green OS<br/>Small credit values"]

Loading

File Walkthrough

Relevant files

Enhancement

usage-view.tsx Update usage view to yearly refresh model                                components/usage-view.tsx Updated refresh credits label from 'Daily refresh credits' to 'Yearly refresh credits' Changed refresh credit value from 300 to 500 Updated refresh subtext from 'Refresh to 300 at 00:00 every day' to 'Refresh to 500 every year.' Replaced sample usage history with three new tasks: 'QCX-TERRA Crop yield Analysis', 'QCX-TERRA Flood predictions', and 'Green OS climate synchronization' Updated task dates to 'upcoming' and credit changes to single-digit values (-7, -5, -3) +6/-6

---

[google-labs-jules]

👋 Jules, reporting for duty! I'm here to lend a hand with this pull request.

When you start a review, I'll add a 👀 emoji to each comment to let you know I've read it. I'll focus on feedback directed at me and will do my best to stay out of conversations between you and other bots or reviewers to keep the noise down.

I'll push a commit with your requested changes shortly after. Please note there might be a delay between these steps, but rest assured I'm on the job!

For more direct control, you can switch me to Reactive Mode. When this mode is on, I will only act on comments where you specifically mention me with @jules. You can find this option in the Pull Request section of your global Jules UI settings. You can always switch back!

New to Jules? Learn more at jules.google/docs.

---

For security, I will only act on instructions from the user who triggered this task.

[vercel]

The latest updates on your projects. Learn more about Vercel for GitHub.

Project	Deployment	Actions	Updated (UTC)
qcx	Ready	Preview, Comment	Feb 2, 2026 0:34am

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ ngoiyaeric
❌ google-labs-jules[bot]
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[coderabbitai]

Warning

Rate limit exceeded

@ngoiyaeric has exceeded the limit for the number of commits that can be reviewed per hour. Please wait 21 minutes and 4 seconds before requesting another review.

⌛ How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

🚦 How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.

Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.

Please see our FAQ for further information.

📥 Commits

Reviewing files that changed from the base of the PR and between 184f678 and 86013ed.

📒 Files selected for processing (1)

• components/usage-view.tsx

✨ Finishing touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch update-usage-view-to-yearly-refresh-14763946411330416327

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[qodo-code-review]

PR Compliance Guide 🔍

Below is a summary of compliance checks for this PR:

Security Compliance
🟢	No security concerns identified No security vulnerabilities detected by AI analysis. Human verification advised for critical code.
Ticket Compliance
⚪	🎫 No ticket provided Create ticket/issue
Codebase Duplication Compliance
⚪	Codebase context is not defined Follow the guide to enable codebase context checks.
Custom Compliance
🟢	Generic: Comprehensive Audit Trails Objective: To create a detailed and reliable record of critical system actions for security analysis and compliance. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Meaningful Naming and Self-Documenting Code Objective: Ensure all identifiers clearly express their purpose and intent, making code self-documenting Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Robust Error Handling and Edge Case Management Objective: Ensure comprehensive error handling that provides meaningful context and graceful degradation Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Error Handling Objective: To prevent the leakage of sensitive system information through error messages while providing sufficient detail for internal debugging. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Secure Logging Practices Objective: To ensure logs are useful for debugging and auditing without exposing sensitive information like PII, PHI, or cardholder data. Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
	Generic: Security-First Input Validation and Data Handling Objective: Ensure all data inputs are validated, sanitized, and handled securely to prevent vulnerabilities Status: Passed Learn more about managing compliance generic rules or creating your own custom rules
Update

Compliance status legend

🟢 - Fully Compliant
🟡 - Partial Compliant
🔴 - Not Compliant
⚪ - Requires Further Human Verification
🏷️ - Compliance label

[qodo-code-review]

PR Code Suggestions ✨

Explore these optional code suggestions:

Category	Suggestion	Impact
Possible issue	Initialize credit state to match yearly limit To prevent user confusion, initialize the credits state to 500 to match the new yearly credit limit displayed in the UI. components/usage-view.tsx [13-16] { details: 'Green OS climate synchronization', date: 'upcoming', change: -3 }, ]) - const [credits] = useState(0) + const [credits] = useState(500) const { toggleUsage } = useUsageToggle() Apply / Chat Suggestion importance[1-10]: 7 __ Why: The suggestion correctly identifies a logical inconsistency where the UI displays a yearly credit limit of 500, but the credits state is initialized to 0, which would likely result in an incorrect balance display for the user.	Medium
	Separate upcoming status from date Refactor the data structure by replacing the string 'upcoming' in the date field with a null value and adding a separate boolean flag like upcoming: true. components/usage-view.tsx [11] -{ details: 'QCX-TERRA Crop yield Analysis', date: 'upcoming', change: -7 }, +{ details: 'QCX-TERRA Crop yield Analysis', date: null, upcoming: true, change: -7 }, Apply / Chat Suggestion importance[1-10]: 5 __ Why: This is a good suggestion for improving data structure and maintainability by separating the 'upcoming' status from the date field, which would simplify future date-based operations like sorting or formatting.	Low
Update

[charliecreates]

The main concern is using date: 'upcoming', which can break any date parsing/sorting and creates inconsistent data shape versus prior entries. Additionally, the yearly refresh amount/copy is hard-coded in multiple places, increasing the chance of drift if business rules change. Consider keeping sample data structurally consistent and centralizing refresh policy values.

Additional notes (1)

• Maintainability | components/usage-view.tsx:55-63
  Refresh credit values and copy are hard-coded in the UI (500, “every year”). If these values are used elsewhere (or could change again), this will be easy to miss and drift from backend/business rules.

This is especially risky since you’re also keeping credits as a constant 0, which suggests this view may later become dynamic but currently mixes static and (future) computed values.

Summary of changes

What changed

• Updated the credits refresh copy in UsageView from daily to yearly:
  • Label: Daily refresh credits → Yearly refresh credits
  • Amount: 300 → 500
  • Helper text: Refresh to 300 at 00:00 every day → Refresh to 500 every year.
• Replaced the sample usage history entries with new task names and placeholder timing:
  • New items like QCX-TERRA Crop yield Analysis
  • Dates changed to the string upcoming
  • Credit deltas reduced to small single digits (-7, -5, -3)

[charliecreates]

The date field switched from a concrete timestamp (e.g. 2026-01-17 08:05) to the placeholder string upcoming. If the table renders/sorts/filters by date (or if other parts of the UI expect a parseable date), this will create inconsistent behavior or broken ordering.

Even if this is “sample data”, the component is still using it as runtime state, so it should stay structurally consistent with what the UI expects.

Suggestion

Keep date values in a consistent, machine-sortable format and represent “upcoming” separately (e.g., status: 'upcoming') or use an ISO date in the future and format it as “Upcoming” in the UI.

Example:

const [usage] = useState([
  { details: 'QCX-TERRA Crop yield Analysis', date: '2026-03-01T00:00:00Z', change: -7, status: 'upcoming' },
  // ...
])

Then in the cell renderer:

{row.status === 'upcoming' ? 'Upcoming' : formatDate(row.date)}

Reply with "@CharlieHelps yes please" if you’d like me to add a commit with this change.