I never put a “Donate” button on any of my OSS efforts. Not because I’m rich (I’m not.) I just don’t like the “donation” term. I feel like I never needed kinda reward or payback for what am I doing.
OTOH, some code requires a ton of tokens (a year ago it would require weeks to be developed.) I found myself hesitating to implement some features right away because I don’t want to break a $1K/month limit I pay for AI assistant.
That said, my initiative would be to introduce kinda “Tokenware” which is effectively an open source code that is being developed by endowments (I still avoid “donations” term fwiw.) There is no issue to calculate the approximate number of token required per a feature (this part might be even automated) and put it next to the feature description.
Every project in the wild might pin “accepting tokens for features” badge on their projects, and that’s how everyone might know their endowments were used to enrich the project, not for dirty weekend in Vegas. Maybe I can even convince Github to be a part of it (badges and token transfers.)
WDYT?
4 Likes
Do we already have a tokencurrency btw? A tokencoin?
Hey that’s an interesting idea, wouldn’t be surprised to see it become very popular very soon 
Do you intentionally want to assume each feature costs a fixed value (be it number of tokens or $ etc)?
In my experience, as features are added, the cost of other features fluctuate (can be cheaper or more expensive). Thus building software often requires figuring out what NOT to build and managing complexity.
I’m a strategist, not a tactician!
To me it sounds pretty reasonable though to settle a price for the feature, it’s the same as what we do working with customers, they say, “hey, I need this button to be red,” and we respond “two billion bucks bro, and it’s red.”
I am usually able to implement whatever is needed, but I want to stop (or at least decrease an amount) paying my own money for the requested features.
I think you are right, and that tokens themselves can be a form of universal currency just like MCP+LLM forms a kind of universal glue between software. We tried to defend micropayments for content and support multiple times but worse alternatives always settled.
Maybe issues tagged with [tokens: 300k, accepted_models: opus-4.7-xhigh, pr_review: [opus>=4.6, gpt>5]] will become the norm. You provide the plan and prompt to orient the donator’s agent in your codebase, and they provide cost of implementation and review.
Since last week I strongly believe there will be tooling to apply an agentic conversation to a codebase, just like you can publish patches by email. Instead of providing the resulting PR, you provide the whole conversation that generates the PR, but the edits are there as inline patches and the whole transcript can be fed into a git CLI or GUI to see the diff. So you can’t masquerade a PR of sonnet 3.5 quality for an opus 4.7 one.
An interesting new kind of PoW.
1 Like
Turns out we’re all in energy business (again).
1 Like
How does it matter? Also, I am not using Claude for its miserable RAG, and proper solutions always involve several providers for different kinds of tasks.
I disagree we need to judge by the model used (it’s like judging the code quality by number of LoCs.) If I could have it done with local ollama—I’m good, I deserve a reward.
This is all not about donations, let alone control. I just want to be able to support my OSS better without breaking $1K/month limit on that, as I stated in the post above.
1 Like
Well cost is often used as a proxy for effort or investment, and different models have different per-token cost. But I think I misunderstood your initial post : I understand someone pays for the tokens, but who burns them through an agent ? You or the person who sponsors ?
If the person burns their tokens to provide a PR, the whole sponsorship thing is out of scope. I just accept or reject a PR, that’s it.
Sure. And I am too greedy to buy cheap stuff, as my father used to tell me. On average, the tokens-per-feature is nearly constant across providers.
1 Like
