[Feature]: Track actual Agent token usage per turn and measure context costs
I maintainer di solito rispondono entro 1 giorno
Valutazione
- Difficoltà
- 4/5
- Tempo stimato
- 3-5 giorni
- Idoneità per principianti
- 22/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Abbastanza chiara
- Stato di attività
- Attiva
- Stack tecnologico
- electron, typescript
- Ambito
- desktop-dev
Direzione di ricerca
Start from the desktop Agent turn code that issues model calls and collects provider usage fields, and from the chat context indicator fed by #312 so the cumulative summary stays separate from it. Read the Workbench usage accounting from #653 before adding any new measurement path. Done means multi-call turns sum usage without double counting, missing usage is shown as incomplete, and summaries persist across restart. The maintainer has not yet confirmed scope, so agree on it before implementing.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
Problem
Splitting the AI-token feedback out of #677, as requested by the maintainer. The reporter describes roughly 62,000 tokens used for AI editing and difficulty understanding which settings reduce consumption. This is a user report, not a reproduced measurement.
Current context occupancy and cumulative tokens consumed across an Agent turn answer different questions: a multi-step turn may send context repeatedly.
Existing work
- #312 already feeds the chat context indicator from the native chat-budget path, including compacted model context. Preserve it and distinguish it from cumulative usage.
- #653 already adds Workbench usage accounting and versioned measurement/replay tooling (part of #459). Reuse this rather than build another measurement system.
- I found no currently open PR dedicated to desktop per-turn usage and context-cost measurement. Please flag overlapping work before implementation.
Proposed first increment
- Aggregate provider-reported input/output tokens across model calls in a desktop Agent turn. Include cached/reasoning details when available without double-counting subsets of totals.
- Show a concise per-turn summary separate from the context indicator. Mark missing/partial usage as unavailable/incomplete, not zero; clearly label any estimates.
- Persist the summary with chat messages so reopening a project preserves it. Store usage metadata only, without credentials or raw provider payloads.
- Measure short/long transcripts and repeated editing turns in reproducible Workbench scenarios. Record provider/model, call count, usage completeness and editing outcomes alongside token totals.
Follow-up based on evidence
Compare range-limited transcript reads, smaller tool results, less repeated project context or adjusted compaction only after identifying the bottleneck. Verify editing outcomes alongside any token reduction.
Exact pre-run cost promises and hard token caps are outside this first increment and need separate design discussion.
Validation
- Multi-call turns sum available usage without double counting; missing/partial usage is explicit.
- Usage remains attached to the originating project/session/turn when sessions switch during a run.
- Completed-turn summaries survive restart and project reopening.
- Claimed reductions include reproducible before/after evidence and editing-quality checks.
I am interested in taking on the initial usage-accounting and measurement work if this scope fits the project direction.
- Lingua principale
- TypeScript
- Stelle
- 3.7k
- Fork
- 231
- Merge medio
- 16h 25m
- PR unite (30g)
- 331
Preparare l'ambiente
- Nessun Dockerfile né file Docker Compose
- Ha un modello di pull request
- Leggi la guida per i contributori
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di getopenscreen/openscreen
-
build.yml: macOS arm64 DMG fails, cargo missing on the macos-26 runner imageForse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
getopenscreen/openscreen#1423 ·
I maintainer di solito rispondono entro 1 giorno
-
Native review wanted: machine-translated recording bar tooltips (14 locales)Forse di nuovo libera @auberginewly l’ha presa 20 giorni fa e non c’è nessuna pull request aperta. Apertagood first issue help wanted
Difficoltà 2/5 1-3 ore Idoneità per principianti 68/100
getopenscreen/openscreen#913 · 5 commenti ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 57/100
getopenscreen/openscreen#1422 ·
I maintainer di solito rispondono entro 1 giorno
-
macOS: pick the YCbCr matrix per buffer instead of hard-coding BT.709Forse già presa Una pull request collegata a questa issue è aperta o già unita. Aperta
Difficoltà 3/5 1-2 giorni Idoneità per principianti 72/100
getopenscreen/openscreen#1420 ·
I maintainer di solito rispondono entro 1 giorno
-
enhancement
Difficoltà 3/5 1-2 giorni Idoneità per principianti 48/100
getopenscreen/openscreen#1419 ·
I maintainer di solito rispondono entro 1 giorno
Tutte le issue di getopenscreen/openscreen
Issue simili
-
e2e-failure ready-to-code
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 82/100
redhat-developer/rhdh-plugin-export-overlays#4616 · 1 commento ·
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
I maintainer di solito rispondono entro 1 giorno
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 66/100
I maintainer di solito rispondono entro 1 giorno
-
ai-handle
Difficoltà 2/5 1-3 ore Idoneità per principianti 72/100
nextlevelbuilder/dewee-web-v2#73 ·
I maintainer di solito rispondono entro 1 giorno
-
backend bug good first issue
Difficoltà 2/5 1-3 ore Idoneità per principianti 70/100
PoCInnovation/Distribox#255 ·
I maintainer di solito rispondono entro 1 giorno