feat(usage): add OpenCode to usage contract and provider presentation - #7623

💭 I'm checking whether the colSpan issue in UsagePage.tsx was actually fixed, since the current diff only shows the test file update and doesn't include changes to UsagePage.tsx itself. I want to verify against the file at head and reconcile this with the earlier commit that mentioned registering a third provider.

1. git_tools — colSpan

2. browse_code — apps/web/src/components/usage/usageProviders.ts

💭 The colSpan fix looks good now with the adjusted count. I should verify that OpenCodeIcon actually exists in the Icons export, and also double-check the purple hex color used for mobile matches the other hardcoded brand colors consistently.

3. git_tools — OpenCodeIcon

4. browse_code — apps/web/src/components/usage/UsagePage.tsx

💭 With the colSpan fix in, I should now check other call sites that assume a fixed provider count, like the provider summary cards around line 250-282, to see if any grid-cols values are hardcoded based on provider count.

5. browse_code — apps/web/src/components/usage/UsagePage.tsx

💭 UsagePage checks out. I should look at UsageSkeleton for a hardcoded provider count, and check UsageProviderChart's legend too, so I'll search for PROVIDER_ORDER usages across the web codebase.

6. git_tools — PROVIDER_ORDER|PROVIDER_PRESENTATION

7. browse_code — apps/web/src/components/Icons.tsx

💭 I notice a discrepancy: two grep results show different line numbers and different expressions for the colSpan calculation in UsagePage.tsx—one at line 420 using activeProviders.length, another at line 394 using PROVIDER_ORDER.length. That's inconsistent, so maybe one grep ran against a different revision or branch than I assumed. I should confirm by re-viewing the file directly and checking the git diff for UsagePage.tsx against the merge base to see what's actually at head.

8. git_tools — f6f2be3..fe3155c

9. github_api_read_only — repos/{owner}/{repo}/contents/apps/web/src/components/usage/UsagePage.tsx

💭 UsagePage looks unchanged, so that earlier grep must have caught a stale version. Now I'm turning to the chart component to see whether the legend using PROVIDER_ORDER shows all providers or just the active ones passed in. Looking at the color choices, opencode's hardcoded violet stands out against claude's brand hex and codex/grok's theme-aware tokens, but since claude already uses a fixed brand color as precedent, this probably isn't a strong finding — likely not worth flagging given the semantic-token rule is really about contrast/chrome settings, not chart series colors. I should also check the chart file directly for any place that assumes a fixed provider count, and cross-reference with the test expectations for all PROVIDER_ORDER columns.

10. browse_code — apps/web/src/components/usage/UsageProviderChart.tsx

💭 Since the chart is provider-count agnostic, I'm now checking whether other web UI locations, like the settings page or the UsagePage test mock referencing a provider order array, hardcode provider lists that would need updating too.

11. git_tools — grok

💭 Good, no stale test file to worry about. I'm also wondering whether the backend actually has an opencode usage collector—if not, the new provider row just won't have data, but since providersWithUsage filters out zero-usage entries it shouldn't clutter the UI. Though I notice UsageSkeleton maps over PROVIDER_ORDER, so it'll now render four skeleton rows during loading. That said, whether the server collects opencode usage is really a data-layer question, not a UI consistency issue in scope here — I'll check the shared usageMerge/server code quickly just to confirm.

12. git_tools — opencode

💭 I should check whether apps/server actually emits opencode usage data at all — if it doesn't, the UI addition would be harmless but inert rather than a consistency violation. I'm also considering the #8b5cf6 color choice, comparing how other providers handle light/dark theming — Codex uses a contrast-foreground variable, Grok uses color-mix, and Claude sticks with a fixed brand color, so I need to figure out what's appropriate for OpenCode's identity here. Looking closer at the icon implementation, it swaps fills between light and dark using visibility classes on individual SVG paths — I want to confirm that toggling display: none/block on path elements actually renders correctly across browsers, and how that interacts with the shared ProviderMark wrapper applying its own class. The icon's non-square viewBox (32x40) means it gets letterboxed when forced into a square size-4/size-3 container, but since this same OpenCodeIcon is already used identically elsewhere in the codebase with the same sizing, this isn't a new inconsistency worth flagging — it's an established pattern I should leave alone. Double checking the dark variant handling confirms it's pre-existing behavior, and mobile's theme-aware colors for codex/grok versus opencode's fixed violet are out of scope here. I'm also weighing whether the chosen violet hex conflicts with any existing hardcoded colors used elsewhere in the web app's usage charts, though it seems like a minor concern. I should also verify there's no other web surface requiring an exhaustive Record keyed by UsageProviderKind that would need an opencode entry -- typecheck should catch this, but I'll search for that pattern in the web/shared code to be sure.

13. git_tools — UsageProviderKind

💭 I'm checking whether the server actually scans OpenCode transcripts for usage data, since the PR didn't seem to add that scanning logic—meaning the UI might show a loading skeleton for OpenCode that never gets populated. This mirrors an existing mismatch with grok though, so it's not a new class of bug, just possibly another instance of it.

14. git_tools — "grok"

💭 I've confirmed the server never emits opencode usage records, so that provider stays dead in the UI—providersWithUsage will never include it. This means the skeleton loader shows four provider rows during loading, but only up to three actually render with real data once loaded. That row-count mismatch is a genuine layout inconsistency introduced by expanding PROVIDER_ORDER from 3 to 4. The changed file is in scope, and the affected consumer (UsagePage's UsageSkeleton) is directly downstream, though this is borderline since the skeleton over-rendering issue existed pre-patch for less-common providers like grok and is only slightly worsened here. I want to check whether the previous colSpan finding has actually been fixed — yes, it now derives from activeProviders.length + 3, so that inconsistency is resolved, and the skeleton appears intentionally provider-count agnostic by design, mapping all of PROVIDER_ORDER as placeholders per the comment about adding providers only requiring a contract entry. Now I'm considering whether the violet color chosen for opencode fits stylistically with the other providers' brand-hex or theme-token colors. I'm leaning toward "All clear," but I want to double-check the skeleton row placeholder styling and the icon sizing for OpenCodeIcon in the tooltip, since its non-square 32:40 viewBox differs from the square marks used by Claude/Codex/Grok, potentially causing alignment differences when all icons share the same size-4 class. I want to see if other providers' icons have non-square viewBoxes too, to judge whether this is tolerated elsewhere in the repo. I'll structure the JSON with a success state, a title reflecting no issues found, and the summary set to "All clear."