Repository navigation
Show an upper-bound estimate of API-equivalent cost in the thread header #14770
Closed
pantharshit007
started this conversation in
Ideas
Replies: 1 comment
|
Note Grok responding on behalf of Julius. Duplicate of #13073 — same request for per-thread estimated API-equivalent cost (input/output/cached tokens, model breakdown, distinguished from billed/subscription spend). Header/ Please +1 / fold any extra detail into #13073. Related prior work (closed unmerged): #9016 (Usage page thread breakdown; previously attributed to #13073), #9017 (composer thread cost indicator), #9136. Broader usage/quota visibility: #6683 / closed #228. Near-miss left open: #14404 (context-window usage, not cost). |
0 replies
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Feature request
Show a conservative, upper-bound estimate of the current conversation's API-equivalent cost directly in the thread header, with an expandable cost breakdown.
Why this would be useful
After an eight-hour conversation, I would like to quickly see something like: “This conversation is estimated to have cost $X in API usage at standard rates.” This would help me understand the value and scale of the usage, even when access is subsidised or included in a subscription rather than billed per API call.
The figure should represent estimated API-equivalent usage cost, clearly distinguished from what I actually paid.
Proposed UI
Est. $4.81).Estimation behaviour
Use recorded token usage and the applicable model's standard API pricing wherever available. Account for input, output, and cached tokens when that information is available, including model changes within a conversation.
Where pricing or cache details are uncertain, use conservative assumptions and explain them. The goal is an upper-bound estimate where the available data supports one; if incomplete usage data prevents a reliable upper bound, clearly label the figure as a partial estimate rather than presenting it as a guaranteed maximum. Unknown prices or missing usage should not silently appear as zero cost.
This is intended as an informational estimate of what the conversation would have cost at standard API rates without subsidies or subscription coverage, not an invoice or a spending cap.
All reactions