Before submitting
Area
apps/web and apps/desktop
Problem or use case
Long sessions directing coding agents can be productive but repetitive. I want an optional progression layer that makes sustained T3 Code work more enjoyable without changing prompts, adding provider calls, or encouraging token burn.
Proposed solution
A local-first T3 Rewards system built around themed Journeys. Existing T3 Usage projections and successful workspace actions produce deterministic XP, missions, streaks, and cosmetic collectibles. One Journey is active at a time, progression can be paused, and earned rewards can appear in small native surfaces such as the thread header, latest completed response, conversation markers, and sidebar artwork.
The design is opt-in and private by default: no prompts, code, project names, or paths are included in rewards or share cards, and no reward logic modifies provider requests.
Why this matters
For people who direct agents throughout the day, lightweight progression can make routine work feel more satisfying while leaving T3 Code as the primary work surface. It also gives existing usage and activity data a playful, inspectable use that does not require another service.
Smallest useful scope
One opt-in Journey on web/desktop, local persistence, deterministic XP from existing Usage/activity, pause/resume, and a small collection of cosmetic rewards. No server sync, mobile UI, economy, purchases, or provider changes.
Alternatives considered
An external tracker would lose the native context and require a second app or data export. I am currently maintaining this as a separate personal fork and desktop flavor that stays rebased on Nightly source.
Risks or tradeoffs
- Product scope and a potentially large UI surface
- Performance if observers or animation continuously repaint
- Incentives that accidentally reward verbosity or artificial usage
- Accessibility, reduced motion, and theme compatibility
- Different support expectations across web, desktop, and mobile
The implementation avoids continuous animation, bounds persisted history, uses existing local projections, and does not reward prompt length or failed activity.
Examples or references
Personal fork/working branch: https://github.com/SethMed7/t3code/tree/rewards-nightly
Screenshots are attached below.
I am not proposing a pull request. I plan to keep building and maintaining this for myself because it makes the work more enjoyable; this issue is only to learn whether maintainers or other users find the direction interesting.
Before submitting
Area
apps/web and apps/desktop
Problem or use case
Long sessions directing coding agents can be productive but repetitive. I want an optional progression layer that makes sustained T3 Code work more enjoyable without changing prompts, adding provider calls, or encouraging token burn.
Proposed solution
A local-first T3 Rewards system built around themed Journeys. Existing T3 Usage projections and successful workspace actions produce deterministic XP, missions, streaks, and cosmetic collectibles. One Journey is active at a time, progression can be paused, and earned rewards can appear in small native surfaces such as the thread header, latest completed response, conversation markers, and sidebar artwork.
The design is opt-in and private by default: no prompts, code, project names, or paths are included in rewards or share cards, and no reward logic modifies provider requests.
Why this matters
For people who direct agents throughout the day, lightweight progression can make routine work feel more satisfying while leaving T3 Code as the primary work surface. It also gives existing usage and activity data a playful, inspectable use that does not require another service.
Smallest useful scope
One opt-in Journey on web/desktop, local persistence, deterministic XP from existing Usage/activity, pause/resume, and a small collection of cosmetic rewards. No server sync, mobile UI, economy, purchases, or provider changes.
Alternatives considered
An external tracker would lose the native context and require a second app or data export. I am currently maintaining this as a separate personal fork and desktop flavor that stays rebased on Nightly source.
Risks or tradeoffs
The implementation avoids continuous animation, bounds persisted history, uses existing local projections, and does not reward prompt length or failed activity.
Examples or references
Personal fork/working branch: https://github.com/SethMed7/t3code/tree/rewards-nightly
Screenshots are attached below.
I am not proposing a pull request. I plan to keep building and maintaining this for myself because it makes the work more enjoyable; this issue is only to learn whether maintainers or other users find the direction interesting.