I’m a form using peasant and one challenge I face is my users never know how many credits they have.
My users are often surprised to run out of usage and then send me angry emails. I know there is credit visibility in the chat interface but I need something that works in pure form tools.
One easy solution is for Pickaxe to create an action that tells the model how many credits remain. I would love if every response said something like: “This run used 19,400 credits. You have 24,600 of 70,000 credits remaining on this tool. Your credits reset on October 7.”
A simple message like that would be a huge stress and time saver for both me and my users. But to generate that message the model needs to know three things:
- Credits remaining
- Credits used for that roung
- Credit refresh date
Here is Claude’s detailed breakdown of the feature request:
The problem
Chat Pickaxes give users a reasonable sense of their credit balance. Form Pickaxes do not. A user fills in the form, clicks the button, and gets a result with no indication of what it cost or how much allowance is left. On an expensive form tool, that means the first sign of a credit limit is a broken run.
I run a workspace of more than 80 Pickaxes for authors, most of them form tools, and this week a user hit the limit on an image-generation form tool in the worst possible way. Her previous month’s runs had used up her allowance on that tool. When she came back, the run started, the image action was invoked, and the platform cut it off mid-loop. The tool’s own error log reported:
Chat GPT Image 2 returned an API error: Invalid ‘prompt’: empty string. Fallback generation produced an asset, but the agent loop reported a budget-limit interruption after generation.
She got a non-image, assumed her prompt was wrong, and emailed me asking what she did wrong. Her prompt was fine. She had no way to know she was out of credits on that tool, and she still had full credits on every other tool in the workspace because limits are per deployment.
Two things made this hard to diagnose. The embed’s low-credit warning did not fire before the wall. And she uses the embed as a guest, so I could not look up her counter to tell her where she stood.
What I am asking for
Three changes, in order of value. Any one of them helps.
1. A platform-generated footer on form responses
After billing completes, append a short line to the response that reports what just happened. Something like:
This run used 19,400 credits. You have 24,600 of 70,000 credits remaining on this tool. Your credits reset on October 7.
Computed server-side, after the run is billed, so it is exact. The model cannot produce these numbers itself, and any attempt to make it do so in the prompt would produce invented figures. Only the platform has the real ones, and it already stores them: Message Insights records per-message cost, and each user record carries the per-deployment counter and reset date.
2. Prompt variables for the pre-run balance
Expose remaining credits and the reset date to the prompt, the same way form fields are injected. This is weaker than the footer, because it is the balance before the run rather than after, but it lets the prompt warn a user that the next image will not fit and stop before spending anything.
3. Make the embed’s low-credit warning read the per-deployment counter
The warning banner appears to read the account-level counter, which stays at zero for users on a public access group, while enforcement reads the per-deployment counter. The result is that users on a per-deployment limit never see a warning before they hit the wall. Reading the counter that enforcement actually uses would fix this without any new feature.
Why form tools specifically
Chat tools have a conversation. A user sees each reply cost something and builds an intuition. Form tools are single-shot and often expensive, since they are the natural home for image generation, long-document analysis, and multi-action workflows. A single form run can cost a third of a monthly allowance. That is exactly the case where a user needs to see the number, and it is the case where nothing shows it.
Related
This overlaps with the per-response Message Insights API endpoint you have already ticketed. The footer in ask 1 is the user-facing half of the same data. If that endpoint ships first, the footer becomes a thin layer on top of it.
Happy to share the full session details privately if that helps reproduce the mid-run interruption.