Repository navigation
[Feature]: Multi-currency support (GBP, EUR, etc.) #91
Description
Preflight checklist
- I searched existing issues and didn't find this request.
- This fits the project's scope (Claude-only, lightweight, token-attribution focused).
What problem would this solve?
Currently, the extension displays Claude Code usage costs exclusively in USD. For international users (UK, EU, Asia-Pacific, etc.), understanding costs requires manual currency conversion. This friction makes it harder to quickly grasp spending in local terms—especially when reviewing costs in the status bar or dashboard during active coding sessions.
The extension already supports robust localization (8+ UI languages, timezone picker with grouped dropdowns, locale-aware number formatting), but currency remains hardcoded to USD. This inconsistency leaves the localization story incomplete.
Proposed solution
Add a currency selector dropdown in the Settings tab (⚙ Settings, General group) alongside the existing timezone and language pickers. Users would select from a curated list of common currencies (USD, GBP, EUR, JPY, AUD, CAD, CHF, CNY, INR, etc.), and all cost displays would automatically convert using live or periodically-refreshed exchange rates.
Key implementation details:
- Currency dropdown in Settings (General group), styled like the existing timezone picker
- Exchange rate data: fetch from a free, reliable source (e.g., open exchange rate API, or bundle with periodic updates)
- No API key required—keep it as frictionless as timezone selection
- Apply conversion to all cost displays: status bar, dashboard tables/charts, cost composition, project/session columns, and share card
UI impact: Minimal—a single dropdown control and a cost multiplier applied at display time. The underlying token counts and pricing logic remain unchanged.
Alternatives you've considered
- Manual currency conversion outside the extension (current workaround): cumbersome, error-prone, and defeats the purpose of a dedicated monitoring tool
- Hardcoded exchange rates: rates drift over time and require frequent updates
- User-configurable exchange rate multiplier (e.g., "multiply costs by 0.79"): less discoverable, more error-prone, requires users to look up and remember the rate
Anything else?
Existing localization patterns to follow:
The extension already has strong foundations to build on:
- Multi-language UI system (
src/i18n.ts) with 8 languages - Timezone picker with grouped dropdowns and UTC offset labels (
src/settings.ts, lines 151–155) - Locale-aware number formatting for decimal places and compact token notation
This feature would extend that proven pattern consistently to regional currency preferences, making the extension more inclusive for global users.
Related to: The ongoing localization work (timezone support, multi-language UI, number formatting) shows this is already a project priority.
Activity
github-actions commentedon Aug 20, 2026
🤖 Automated first-pass reply
The configured analysis model did not return a usable analysis for this issue. The item has still been received and remains available for maintainer review.
To help with triage, please ensure the extension, VS Code, and operating-system versions plus anonymous diagnostic logs are included.
🤖 Posted automatically by CCU Bot — not a maintainer decision.
Carl723000 commentedon Aug 20, 2026
Thank you for the thoughtful proposal. We agree with the underlying need: a local-currency view would make the estimated cost much easier to interpret for international users.
We do not plan to add a live or periodically refreshed exchange-rate feed. The extension’s USD cost is already an estimate derived from public token prices; adding a network-sourced exchange rate would create a second estimation layer together with a new dependency on rate providers, caching, refresh policy, and offline failure handling.
We would instead like to pursue a narrower, local-first option:
This preserves the lightweight and auditable design while still solving the quick local-currency interpretation problem. If this narrower scope works for you, we would keep this issue open to track it.
🤖 Generated with OpenAI Codex
Bozodragon commentedon Aug 20, 2026
Thanks for the explanation.
That would absolutely meet my requirements for this feature, it's more for general context than as an alternative to billing details, and being able to input the conversion rate manually makes it easier to make it work for a wider audience.
It might be useful to make the currency or symbol configurable to make it extra flexible perhaps.
Carl723000 commentedon Aug 28, 2026
Status update: this remains accepted for a later release under the agreed local-first scope—configurable currency or symbol plus a user-provided conversion rate, with no exchange-rate network dependency. It is intentionally outside v2.3.0 and remains open for follow-up.
Carl723000 commentedon Sep 6, 2026
The accepted local-first scope is now recorded in the post-v2.3.1 P0.5 roadmap on
main(087bae5):This remains open for a later release and is intentionally outside v2.3.1.
🤖 Generated with OpenAI Codex
Carl723000 commentedon Sep 9, 2026
Implementation update: the agreed local-first scope is complete in the v2.3.2 test candidate.
≈marker;Automated coverage includes the pure converter, settings normalization/persistence, Claude and Codex server-rendered surfaces, client-rendered drill-downs and metric switches, weekly details, and share-card output. We will keep this issue open until the candidate is merged/released, then close it with the public release reference.
🤖 Generated with OpenAI Codex
Carl723000 commentedon Sep 10, 2026
Correction to the 2.3.2 candidate update: after UI review, the candidate now uses one curated currency dropdown and defaults to USD. It no longer exposes a manual multiplier. Rates are a bundled ECB-derived snapshot dated 2026-09-09; they are not fetched, refreshed, or editable. All source estimates and persistence remain USD, with conversion applied only at display time and converted values marked ≈. This keeps the requested one-control UI while retaining local-first and offline behavior. The candidate covers dashboard summaries, tables, charts, drill-downs, weekly-equivalent values, status-bar estimates, and share cards. We will keep the issue open until the change is merged and released.
🤖 Generated with OpenAI Codex: https://developers.openai.com/codex/
fix: stabilize v2.3.2 dashboard interactions (ClaudeCodeUsage#100)