feat(billing): threshold notification service with persisted dedupe#2351
Draft
k11kirky wants to merge 1 commit into
Draft
feat(billing): threshold notification service with persisted dedupe#2351k11kirky wants to merge 1 commit into
k11kirky wants to merge 1 commit into
Conversation
Contributor
Author
|
Warning This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
This stack of pull requests is managed by Graphite. Learn more about stacking. |
This was referenced May 25, 2026
k11kirky
force-pushed
the
posthog-code/usage-threshold-monitor
branch
from
23ff881 to
d6105bb
Compare
k11kirky
force-pushed
the
posthog-code/usage-sidebar-reset-time
branch
from
c79d047 to
a6fca1b
Compare
This was referenced May 25, 2026
Moves usage-limit detection out of the renderer into a main-process
`UsageMonitorService` that polls /v1/usage every 30s, detects when a
bucket newly crosses 50/75/90/100%, and emits an event through a
tRPC subscription. Dedupe state lives in a persistent electron-store
keyed by `${userId}:${product}:${bucket}:${anchor}:${threshold}` so
crossings don't re-fire after an app relaunch. Anchors are
`reset_at` rounded to the hour for burst (jitter-tolerant), and
`billing_period_end` (Pro) or the date of `reset_at` (Free) for
sustained. Stale entries are pruned on startup.
The renderer subscribes via `initializeUsageThresholdToast` (modelled
on `connectivityToast`) and shows a warning toast at 50/75/90% with
a "View usage" action that opens the Plan & Usage settings. At 100%
the existing `UsageLimitModal` opens if a session is active, else
the user gets a blocking error toast.
`useUsageLimitDetection` is deleted — the 100% path is now driven
from the same subscription. The renderer holds no detection state.
`toast.warning` is extended to forward an action button (the wiring
already exists in `ToastComponent`).
Generated-By: PostHog Code
Task-Id: bac06178-1ab1-4000-9a56-1901215bd4af
Generated-By: PostHog Code
Task-Id: bac06178-1ab1-4000-9a56-1901215bd4af
k11kirky
force-pushed
the
posthog-code/usage-sidebar-reset-time
branch
from
a6fca1b to
211250e
Compare
k11kirky
force-pushed
the
posthog-code/usage-threshold-monitor
branch
from
d6105bb to
1589fab
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
Users had no visibility into their LLM usage approaching or reaching limits. Without proactive notifications, users would be surprised when hitting rate limits mid-session.
Changes
Introduced a
UsageMonitorServicethat polls the LLM gateway every 30 seconds and emitsthreshold-crossedevents when usage crosses 50%, 75%, 90%, or 100% for either the burst (daily) or sustained (monthly) bucket.Key behaviors:
electron-storeso notifications don't re-fire after an app relaunch within the same billing windowbilling_period_endon the usage responseOn the renderer side,
initializeUsageThresholdToastsubscribes to the newusageMonitor.onThresholdCrossedtRPC subscription and shows:UsageLimitModal(when a session is active) at 100%The old
useUsageLimitDetectionhook and its polling-based approach have been removed in favour of this event-driven model. Thetoast.warningutility was extended to support anactionbutton.How did you test this?
Unit tests cover the core deduplication and emission logic in
UsageMonitorService:isProis correctly derived frombilling_period_endnullwithout throwingPublish to changelog?
no