I built a marketplace for unused API capacity. Here’s why.
AI teams are spending more and more on API usage, while some teams have capacity they aren’t fully using.
At the same time, other AI builders are looking for ways to reduce their API costs without sacrificing the models they rely on.
That made me wonder: what if unused API capacity could be useful to another team instead?
So we built Unburn — a marketplace designed to connect teams with unused API capacity to AI builders looking for more affordable API usage.
Where it stands today: Unburn is live and in the early validation stage. We’re currently looking for AI teams with significant API usage who are willing to test the idea and share honest feedback.
What I still want to understand:
- Would you use something like this? What would make you trust it?
- If you have high API costs, what are you doing today to reduce them?
- Which AI providers do you spend the most on?
If you’ve dealt with high API costs, I’d genuinely love to hear how you handle them today.
The thread has settled on trust and provider terms, which are real, but there is a structural problem underneath that decides whether the marketplace can work at all: the thing you are trading mostly does not exist as an asset.
Most API spend is metered consumption, not reserved capacity. A team does not hold 40 million idle tokens in an account; it holds a spending commitment or an unused quota that expires. So "unused capacity" is only sellable where a provider contract has a minimum spend or a committed-throughput tier, and that is a narrower population than it looks. Two consequences follow.
First, the seller is someone with a negotiated enterprise agreement, and those agreements almost always carry non-transferability, no-resale and account-sharing clauses. The buyer is being asked to route production traffic through a credential whose terms may be voided by doing exactly that. Your compliance question is not a hurdle to clear once; it is the load-bearing wall, because the entire supply side exists only where those clauses are being read loosely.
Second, the arbitrage is self-eliminating. The spread exists because list price and negotiated price differ. Providers watch for exactly this kind of resale, and when it gets big enough to matter they have two easy responses: tighten terms or price the gap away. Either one removes the supply without removing your platform's costs. A marketplace whose inventory is an inefficiency that the counterparty is incentivised to eliminate is a business with a clock on it.
There is a version of this that survives: instead of reselling capacity between accounts, aggregate demand so that the committed-throughput tier becomes reachable at a smaller scale, with one party holding the contract and the members paying for access rather than trading credentials. That converts the supply problem into a collective-buying problem, which is legal, boring and durable. I run Piramyd, which is one instance of that shape, so read my view accordingly.
The number I would want before building further: what fraction of your prospective sellers actually have a commitment-based contract, rather than just a high monthly bill? If it is the latter, there is nothing to trade.
That’s a really good point. We’re looking into the provider terms and seller requirements now, and we’ll make sure the marketplace only supports capacity that can actually be shared or transferred safely. We’re also working through the security and usage tracking side.
The trust question seems like the key hurdle, especially around provider terms and reliability. A narrow pilot with a small set of well-understood workloads could help you learn whether the savings are meaningful before tackling every edge case. I’d also ask early users what proof they need to feel comfortable testing it—compliance clarity, predictable SLAs, or simply transparent usage accounting.
Absolutely. We’re focusing on trust first and looking at things like verification, usage tracking, security, and clear transaction terms so users know exactly what they’re getting.
That sounds like the right approach. A lot of marketplaces focus heavily on the cost-saving angle, but if security, reliability, or provider compliance become weak points, the savings disappear pretty quickly. In the long run, trust and consistency are probably more valuable than squeezing out the absolute lowest cost. It'll be interesting to see whether the biggest opportunity ends up being the marketplace itself or the infrastructure and governance layer around it. Looking forward to seeing how your thinking evolves as you validate the different approaches.
Have early AI teams shown willingness to actually route production usage through Unburn, or is the strongest signal so far interest in the cost savings?
That’s exactly the kind of thing we want to test next. We’re focusing on getting real teams to try the product with production use cases and using their feedback to improve the experience.
That production-use test is the part I’d be most interested in following. If you’re open to it, what’s the best email to reach you on?
The trust question is the right one to focus on first. API credits are often tied to enterprise rate limits and provider contracts, so the issue isn't really 'can I trade this?' but 'will using a third-party marketplace cause problems with my provider?' I'd be curious whether you're seeing more demand from the buyer side (cheaper API access) or seller side (teams with unused capacity to offload). That split usually tells you where the real pain is.
That’s a good question. We’re looking at both sides right now — making sure there’s enough seller supply while also understanding what buyers actually need and expect before using it.
Interesting idea. My biggest questions would be around provider terms of service, reliability, and security. If API credits or capacity aren't officially transferable, many teams may worry about account risk or losing access unexpectedly.
Trust would probably come from clear compliance with provider policies, transparent pricing, usage guarantees, and a way to ensure sensitive data never passes through another team's infrastructure.
For reducing costs, most teams I know focus on model routing, prompt optimization, caching, batching, and using smaller models where possible before looking for alternative capacity sources. It would be interesting to see whether the savings from a marketplace like this are large enough to outweigh the operational and compliance concerns.
Yeah, those are exactly the concerns we’re working through. We’re looking at security, reliability, and provider terms alongside the actual cost-saving use case, rather than treating the marketplace as the only solution.