release: v0.4.27 — Antigravity dual-window quota card, shared buckets, legible green bars - #939
Merged
Conversation
chore: sync main to dev after v0.4.26
The card showed only the 5-hour window. A group shares one weekly limit and one 5-hour limit, so hiding either leaves the account holder guessing which one is about to run out — the real client shows both, grouped, with weekly first, and now so does this. Rows are composed here rather than taken from the backend: the group name comes from the upstream, the window from WindowSeconds, so "Gemini · 周" is localised without translating anything the upstream owns. The group name loses its trailing "models", which carries nothing next to a window and a percentage. A group with only one window — the fallback model view is entirely 5h — gets no window suffix, since there is nothing to disambiguate against. The upstream describes each group in a full sentence. Printed inline it would push the numbers off the card, so it moves behind a hint icon next to the label, together with a short explanation of how the two limits interact. The description is taken off the item as well as out of the row, so it cannot reappear in the detail line reserved for the reset countdown. Sorting needed no change: resolveAuthFileQuotaRank ranks by the tightest quota the card actually shows, and it reuses resolveQuotaCardSlots, so the weekly bucket became eligible the moment the card began showing it. Its test now pins that an account at 3% weekly outranks its own roomier 5h window, which is the behaviour an operator reading the card expects. renderQuotaBar moves into quotaBar.tsx as useQuotaBarRenderer, for the same reason renderQuotaBarNode already lived there: the presentation hook is over the file-size limit and may only shrink. Both touched files ended up smaller than their baselines, which are updated to match. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
feat(ai-accounts): show both Antigravity quota windows per group
The card drew five independent bars — Gemini Pro, Gemini Flash, Gemini Image, Claude, GPT-OSS — for what is, on the live account, a single shared quota. Asked what the bars meant, there was no way to tell they were the same limit counted five times. The backend now groups models by the quota they actually draw on, so a row corresponds to one real bucket. It has no family name to show, and inventing one is what this grouping exists to avoid, so the row says how many models share it: "19 个模型共享". The member list goes behind the hint icon under a heading, one model per line, rather than as a bare comma-separated string in the row. Shared buckets group by their own key rather than by label, since they all carry the same label key — they render alike but are distinct quotas and must stay distinct rows. The named-group path is untouched: an account that can read the upstream summary still shows the upstream's own group names with both windows. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
feat(ai-accounts): show which models share an Antigravity quota
The card gave each quota two lines — a label row and a separate track below it — so five quotas filled the card and the numbers sat far from the names they belonged to. Reading down a column meant hopping between rows. Each quota is now one line: the fill is the row's own background rather than a track underneath, and the label, countdown and percentage share it. Same information, half the height, and the numbers line up in a column you can scan. The countdown moves inline from the detail row it used to occupy, which is what freed the second line. Antigravity rows carry the family name straight from the backend again. That view now measures each family from one representative model, so the hint says which model the number came from — an aggregate had no honest answer to that question, since it mixed models on different reset cycles. The previous "N 个模型共享" labelling is gone. It described the data correctly and told the reader nothing: a bucket count is an internal detail, not something to hand to someone checking whether they have quota left. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
feat(ai-accounts): compact single-line quota rows
A card at rest lit five emerald surfaces at once: the plan badge, the quota chip's border, its background, its label, and the success rate. Every account in good standing therefore rendered as one flat green field, and a colour that is always on cannot signal anything — the amber and rose tones meant to flag a quota worth acting on had to compete with it for attention. Return all five to the neutral slate the surrounding chips already use and keep only the progress ring green, so a healthy quota still reads as healthy without claiming the whole card. The amber (20-60%) and rose (<20%) branches, the warning/urgent/expired subscription tones and the sub-90% success rates are deliberately untouched: they are now the only coloured things on the grid, which is the point. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
useAuthFilesFilesPresentation.tsx sits above the 800-line limit and the gate only lets such files shrink, so the two explanatory lines added with the neutral subscription tone pushed it from 974 to 976. The reasoning lives in the previous commit message instead. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
fix(ai-accounts): stop painting the healthy state green
#936 neutralised percentClass, chipClass and chipLabelClass, but the card view renders quota through renderQuotaBarNode, which uses none of them except the percent: it consumes fillClass and paints it as the row's own background rather than a slim track underneath. At 100% that fill covers the entire line, so every healthy window still rendered as a green band and the card read exactly as before. Move fillClass to neutral slate for the >= 60% branch. fillHex keeps its emerald: it drives the 14px progress ring in QuotaMetricChips, where the colour occupies a ring instead of a row. Amber and rose fills are left alone, so a bar that changes colour now means something changed. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
fix(ai-accounts): neutralise the quota bar fill, not just its text
#936 and #937 read the flat green field as too much colour and drained it to slate. That was the wrong diagnosis: the problem was never that the bar was green, it was that the green was a 20%-opacity wash under text-slate-600 labels and text-slate-400 countdowns — nothing on the row had enough contrast to read, and draining the colour only made a dull row duller. Restore the green and spend the contrast where it earns something: - The fill drops the opacity wrapper for a solid but light tint (emerald-100), so text sits on a known colour instead of a wash. - A 2px rule runs down the fill's right edge. That edge is what encodes the percentage, and it locates the value far more precisely than a block boundary — which matters most at 100%, where the fill covers the whole row and had no visible boundary at all. - Label, countdown and percent move onto the tone (emerald-900 / emerald-700 / emerald-900) rather than hardcoded slate, so every element on the row belongs to one colour family. Keeping the tint light is what stops a grid of cards becoming a wall of colour: saturation is spent on the 2px edge, not on the full-width background. Amber and rose follow the same construction, so a bar that changes colour still reads as a change of state. The subscription badge and the >=90% success rate return to emerald as well; both were drained by #936 and neither was the source of the problem. Two assertions move from text-rose-700 to text-rose-900: the depleted state is still rose, one stop darker for legibility. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
fix(ai-accounts): make the quota bar green legible instead of neutral
Promotes the verified Antigravity quota and routing fixes onto the release branch for v0.4.27.
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.
Promotes the verified
devbranch tomainfor v0.4.27. Pairs with CliRelay v0.4.27.Key changes
windowSeconds— so they localise.emerald-100fill, aborder-r-2marker at the percent, and labels that contrast against the fill.Compatibility and upgrade notes
Verification
devPRs passedquality-build-e2e/test-build/vitest(2 shards).bun run --filter @code-proxy/admin-panel test -- pages/auth-files/__tests__/quotaCardSlots.antigravity.test.ts pages/auth-files/__tests__/authFilesQuotaSort.test.ts pages/auth-files/__tests__/AuthFilesPage.files-table.test.tsx→ 3 files, 99 passed.