junhoyeo/tokscale

Second follow-up to #1251, which I said I would open separately. #1251 fixed the gh credential lookup on Windows: CredReadW with CRED_TYPE_GENERIC is an exact match on the full TargetName with no prefix or wildcard matching, and gh (via go-keyring) writes "<service>:<username>" with an empty username, so the real target is "gh:github.com:" and the bare "gh:github.com" we had been asking for was one character short. That fix was scoped to gh. Two other callers still pass a bare service name, and nobody has checked whether that is right. All line numbers are on 3f4fbd73. The contract crates/tokscale-cli/src/commands/usage/helpers.rs:12-23 now states it explicitly: Windows: the Credential Manager has no service attribute. CredReadW is an exact match on the full TargetName and supports no wildcards, so the caller must pass a complete target name. For anything written by Go's go-keyring (which is what gh uses) that is "<service>:<username>", never the bare "<service>". It is a doc comme

Follow-up to #1251, which I said I would open separately. gh is a multi-host CLI: gh auth login --hostname ghe.example.com stores a token for that host, and GH_HOST selects which host the rest of the CLI operates against. Tokscale's Copilot integration has no concept of a host at all. Every discovery path is pinned to github.com, in four independent places, and they have to be fixed together rather than one at a time. All line numbers are on 3f4fbd73. 1. The keyring service name is a constant crates/tokscale-cli/src/commands/usage/copilot.rs:38 const GH_KEYRING_SERVICE: &str = "gh:github.com"; gh composes this as "gh:" + hostname (keyringServiceName in cli/cli), so an enterprise user's token lives under gh:ghe.example.com and nothing here ever asks for it. #1251 parameterised the target composition on the service name — gh_wincred_targets(service) takes an argument and there is a test at copilot.rs:745 asserting it works for gh:ghe.example.com — but the service name itself is still

#939 merges duplicate Copilot usage spans (same traceId+spanId) by component-wise maximum, on the assumption that repeated exporter emissions are monotonic snapshots of one LLM call — which OTel span identity semantics imply, and which #938's reproduction asserts. There is currently no captured real-world exporter fixture in the repo demonstrating a duplicate span whose usage values differ. If Copilot's exporter ever emits per-flush deltas under one spanId, max-merge silently undercounts that span. Asks: If you have a Copilot OTEL export (chat span) where the same spanId appears twice with different token values, please attach a redacted sample. With a real fixture we can either lock the snapshot assumption into a test or switch the merge to summation for delta-shaped exporters. Watch signal: user reports of Copilot totals dropping after v4.6.x.

GPell999, — 4/10/26, 2:31 PM Hello, does anyone know about gsd tokscale currently doesn't support gsd 2, its a new harness JUNO, — 12:22 AM get-shit-done (GSD) is not a harness with its own session store. It's a meta-prompting / context-engineering installer that layers on top off existing runtimes (Claude Code, Codex, Gemini, OpenCode, Cursor, etc.). It: Writes artifacts (.planning/STATE.md, HANDOFF.json, SESSION_REPORT.md, ~/.gsd/knowledge/*.json) — but these are derived state, not conversation transcripts with token counts. Reads Claude Code's ~/.claude/projects/*.jsonl for its "profile" feature — explicitly relying on the host's logs. Has no native token/usage log. In contrast, every existing tokscale harness (Claude, Codex, Droid, Amp, OpenClaw, …) is registered in crates/tokscale-core/src/clients.rs because it has its own session-file store with per-message token accounting. GSD has no equivalent store. Why "add GSD as a new harness" is problematic If I clone the Dr