[Bug]: The app says Gemini API ran out of limit while test saying yes

[MRAKS05]

Description

The dashboard is saying Gemini API key limit reached also the apps log saying the same while test promt in settings page says yes.

Steps to Reproduce

Revealed after long term use

Relevant Log Output

Screenshots / Screen Recordings

Screenshot_2026-06-11-19-59-07-421_com.browserlimit.app.jpg
Screenshot_2026-06-11-19-59-00-068_com.browserlimit.app.jpg

App Audit Logs

No response

App Version

1.1.0 (latest release)

Android Version

Android 16+ — API 36+

Device

Xiaomi / Redmi / POCO

Shizuku Status

Yes — Shizuku is running

Gemini AI Status

Yes — Gemini is enabled and API key is set

Affected Area

• Detection / Engine (browser detection misclassifications)
• Overlay (countdown, remove/keep buttons)
• Dashboard (status, counts, toggle)
• Settings (configuration changes not saving/applying)
• Onboarding (setup wizard)
• Logs (log display, export, recheck)
• Exceptions (exception management)
• Service / Background (GuardService, auto-detection)
• Shizuku (uninstall failures)
• UI / Theme (layout, colors, animations)

Verification

• I have searched for existing issues before filing this report
• I am running the latest version of the app
• I have tried restarting the app / device

Additional Context

No response

[MRAKS05]

Investigation Summary

The Dashboard shows "Gemini API: Limit Reached" while the Settings test prompt succeeds. This is not a real Gemini API rate limit — it is a self-imposed local soft limit of 20 API calls/day, hardcoded in SettingsManager.kt since the initial commit.

How the two paths diverge:

Path	Code	Uses local counter?
Dashboard status	canUseGeminiApi() → checks geminiApiCount < 20	✅ Yes
Browser detection	tryUseGeminiApi() → check-and-increment, then GeminiClient.isBrowser()	✅ Yes
Settings test prompt	Direct GeminiClient.isBrowser() call, no counter check	❌ No

The Settings test creates a fresh GeminiClient and calls the real Gemini API directly, bypassing the local 20-call counter entirely. So the counter can be exhausted (showing "Limit Reached"), but the actual API key works fine.

---

Fix Plan

1. Make the daily limit a configurable setting (not hardcoded)

File: SettingsManager.kt

• Add a new preference property geminiDailyLimit: Int with default 20, backed by SharedPreferences + StateFlow
• Add setter setGeminiDailyLimit(value: Int)
• Replace both occurrences of 20 in canUseGeminiApi() and tryUseGeminiApi() with geminiDailyLimit

2. Add UI control in Settings

File: SettingsScreen.kt

• Add a slider or number picker in the Gemini section labeled "Daily API check limit"
• Range: 5–100, step 5, default 20
• Show current value (e.g., "20 checks/day")
• Wire to settings.setGeminiDailyLimit()

3. (Optional) Clarify Dashboard label

Change "Limit Reached" → "Daily check limit reached" so users understand it is a local self-imposed cap, not their API key being invalid.

---

Why This Fix Works

• Users who hit the limit can increase it from Settings without waiting for the next day
• The Settings test prompt will still bypass the counter intentionally — it tests the API key, not the local limit
• The local counter still prevents runaway API costs, but now the user controls the ceiling

[MRAKS05]

Updated Plan: Fully Dynamic (No Manual Slider)

Scrap the slider idea. The limit should be fully automatic using the real Gemini API response — no hardcoded counter, no user config.

What To Do

1. Remove the static counter from SettingsManager.kt:

• Delete geminiApiCount, lastApiDate, canUseGeminiApi(), tryUseGeminiApi()
• Replace with a simpler geminiRateLimitedUntil: Long (epoch ms timestamp of when cooldown expires, 0 = not limited)

2. Handle 429 in GeminiClient.kt after all 3 retries fail:

• Write the current time + backoff (e.g., 60s) into geminiRateLimitedUntil
• Return a rate-limited error as today

3. Update BrowserDetector.kt:

• Instead of tryUseGeminiApi(), just check if currentTime < geminiRateLimitedUntil → skip API, fallback to local list
• No daily call counting at all

4. Update DashboardScreen.kt:

• hasLimit = System.currentTimeMillis() > geminiRateLimitedUntil
• Label becomes: "Ready" / "Rate Limited (retry in Xs)" / "Disabled" / "Error"
• This now reflects real API health, not an arbitrary counter

Why This Is Better

• No stale counter to reset — works immediately after rate limit expires
• No arbitrary 20/day cap — uses the API real quota
• Dashboard status is truthful: if the API says 429, show limited. If API works, show ready.
• No manual slider needed — fully automatic

---

Files to modify:

File	Change
SettingsManager.kt	Remove counter fields. Add geminiRateLimitedUntil
GeminiClient.kt	On final 429 failure, write cooldown timestamp
BrowserDetector.kt	Check timestamp instead of counter
DashboardScreen.kt	Read timestamp for status
SettingsScreen.kt	Test prompt already works (just remove counter refs)