You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The database is SQLCipher-encrypted. My implementation is still pretty ugly and currently has the encryption key hardcoded, so I won't post it here yet. I'll add it here or open a pull request once I have the time.
Happy to take a PR. Two constraints worth knowing before you spend time on it, both learned from the TRAE CN attempt in #474:
A hardcoded decryption key is fine to post. It is in the shipped binary, so it is not a secret — extracting it is the normal way anyone reads a SQLCipher store. What I will not merge is anything that sends a user credential off the machine; if the integration needs a token for a vendor API, that path has to be opt-in behind an explicit flag, defaulting off.
Verify what input_tokens actually means before you trust it. This is the single thing most provider PRs get wrong here. Codex and every-code fold cached reads into their input count, and copying that naively inflated cost 6-7x. Check the parsed numbers against TRAE's own billing or cost field on a few hundred records rather than assuming the field names mean what they say. The repo's normalization is:
Also: if this is international TRAE and the CN build writes a different store, they should be separate sources rather than one bucket — same call I made for WorkBuddy in #632.
No rush on timing. If you want, open it as a draft early and I will review the parser shape before you polish it.
"A hardcoded decryption key is fine to post." - I wasn't sure if it was device-bound and therefore unique. I got the idea from the CN version, but I didn't know if it was universal for the English one too. (I didn't even check until now, but yeah, it matches exactly ^^)
Noted. Thank you for the recommendations! I have to do a few other things first tho, so it might take a few more days.
Released in v1.1.4. The published release includes the CLI and macOS, Windows, and Linux builds. TRAE costs can be partial for multi-request turns, and the Linux TRAE data path remains unverified.
Activity
linear commentedon Sep 17, 2026
001-318
xiufengsun commentedon Sep 20, 2026
Happy to take a PR. Two constraints worth knowing before you spend time on it, both learned from the TRAE CN attempt in #474:
A hardcoded decryption key is fine to post. It is in the shipped binary, so it is not a secret — extracting it is the normal way anyone reads a SQLCipher store. What I will not merge is anything that sends a user credential off the machine; if the integration needs a token for a vendor API, that path has to be opt-in behind an explicit flag, defaulting off.
Verify what
input_tokensactually means before you trust it. This is the single thing most provider PRs get wrong here. Codex and every-code fold cached reads into their input count, and copying that naively inflated cost 6-7x. Check the parsed numbers against TRAE's own billing or cost field on a few hundred records rather than assuming the field names mean what they say. The repo's normalization is:Also: if this is international TRAE and the CN build writes a different store, they should be separate sources rather than one bucket — same call I made for WorkBuddy in #632.
No rush on timing. If you want, open it as a draft early and I will review the parser shape before you polish it.
jonasfroeller commentedon Sep 20, 2026
"A hardcoded decryption key is fine to post." - I wasn't sure if it was device-bound and therefore unique. I got the idea from the CN version, but I didn't know if it was universal for the English one too. (I didn't even check until now, but yeah, it matches exactly ^^)
Noted. Thank you for the recommendations! I have to do a few other things first tho, so it might take a few more days.
feat: track TRAE (xiufengsun#643)
feat: track TRAE (xiufengsun#643)
xiufengsun commentedon Sep 30, 2026
Released in v1.1.4. The published release includes the CLI and macOS, Windows, and Linux builds. TRAE costs can be partial for multi-request turns, and the Linux TRAE data path remains unverified.