Hello, you can call me T. Apologies in advance for the long-winded intro to the project.
Over the last few days, Iโve watched attempt after attempt to launch an inference router fail. Most were thin wrappers around basic model-to-model requests, built without any sense of what a real router could become. Then, time and again, the teams rugged. It has been frustrating to watch because the first version is not difficult to build. A live catalog, metered requests, honest pricing, one balance and reliable access are all shippable (You can already do this in Manyways). The harder part is staying to build the full system people were promised.
My goal is to make $MANY the currency that powers democratized inference. Fees generated by the token would flow into a shared inference balance that pays for real requests across model providers. As the token is used, the pool grows. As people use the pool, they get access to models and give us the data needed to build better routing. Every request still has a real cost, so the balance, spending limits and routes should be visible. If the pool can fund a month of inference, we should say that. If it can fund years, we should show that too. I want the economics tied to something people can use and inspect.
In 2021, Robinhood showed how much demand appears when you remove commissions, minimums and ceremony from markets. I want to bring that instinct to intelligence: fewer accounts, fewer paywalls and a much lower barrier between a person with an idea and the models that can help them build it. Manyways already starts with free model comparisons and one wallet-funded API. The larger mission is to turn $MANY fees into shared access, then keep widening that access as the network grows. I want to build an inference economy where the token continuously buys the thing it represents: intelligence people can use.
Come give it a try @ https://t.co/VULrjpbaLr
-T
After the recent patch, models are now operating with 20-30% more efficiency, making way for our first Many Strategy.
For those that might have missed my follow-ups in the comments, I want to take a moment to breathe and start thinking thoughtfully about other mechanisms that involve our inference token.
A brief except of thoughts so far:
The inference pool is currently designed to create product usage. As more developers route through Manyways, builders can compete to create strategies that reduce cost or improve results. Publishing and scaling those strategies would require staked $MANY.
Holders who do not use the API could delegate $MANY to strategies they believe in. Their stake would help those strategies qualify for production traffic, while real usage and measured performance determine which strategies grow.
I want token fees to keep funding inference. Revenue from enterprise routing or a strategy marketplace can fund rewards for builders and delegates once that revenue exists. That gives holders a role tied to useful work and product demand, without pretending passive holding creates value on its own.
I absolutely want to drill-in more on how holders (perhaps not users) can further find value in their tokens outside of a simple investment, so please don't hesitate to share any concerns, suggestions etc.
๐ฆ Night owl hours are approaching, expect big things.
@dreams_alike@dont_get_rugged Huge oversight, thank you for the callout. I had thought this was committed minute one, but must have got pushed aside in another rebuild.
Next update will be to finalize the deeper inference pools tracking, and migrate our previous dial to the new Postgres tables. You'll see it hung up on the 3k number until that's done.
Letting it spin it's wheels for a little bit and I'll plug it in.
-t
@gglfggg Hi @gglfggg, most definitely. Things have been at a pretty heavy pace since launch so I haven't had a chance to fully get my thoughts onto paper and in a wide view - but early thoughts are here below.
Solid question, @KrystianDeFi.
The inference pool is currently designed to create product usage. As more developers route through Manyways, builders can compete to create strategies that reduce cost or improve results. Publishing and scaling those strategies would require staked $MANY.
Holders who do not use the API could delegate $MANY to strategies they believe in. Their stake would help those strategies qualify for production traffic, while real usage and measured performance determine which strategies grow.
I want token fees to keep funding inference. Revenue from enterprise routing or a strategy marketplace can fund rewards for builders and delegates once that revenue exists. That gives holders a role tied to useful work and product demand, without pretending passive holding creates value on its own.
I absolutely want to drill-in more on how holders (perhaps not users) can further find value in their tokens outside of a simple investment.
After many emails, phone calls, and back & forths, I am pleased to share that the router is back online.
Alas, I didn't want to give any false hope here ahead of any proven work to get us back online. This was definitely an unexpected hurdle that consumed quite a bit of work, including a decently heavy rebuild of the back-end.
Please be gentle with our new friends while I observe and adjust on the fly with limited models, and slowly re-enable key generation. The model dispatch should be in full production now.
I can't thank everyone enough for their patience
$MANY is back in action. Inference is democratized.
0xa26992c4268a8a78a4d872fe4bdad2ed03ac287d
It would seem a large number of the inference providers have flagged the project, you may experience some instability while we work through this. Thank you for the patience.
While the work on the endpoint and inference strategy releases turns in the background, I want to say how much your interest has meant to me.
Model routing is a problem I care about. Seeing you test $MANY and challenge the design has made the work feel worth doing. Your questions and ideas have helped me see where the product needs more thought.
Thank you for giving this your attention. Iโm excited to keep building with you and show you what ships next.
Iโm adding buffered and streamed Responses support to Manyways API keys, alongside structured inputs and tool calls. Generating one will require a wallet holding at least $5 worth of $MANY.
Once this ships, holders can connect the shared inference pool to OpenCode and use it instead of maintaining a separate coding-agent plan:
1. Hold $5 of $MANY.
2. Connect your wallet at https://t.co/jDvcLbzkKQ and generate a key.
3. Install OpenCode with `npm install -g opencode-ai`.
4. Add Manyways as a custom Responses provider using `https://t.co/4W9uE8aoRa`.
5. Choose a model and run `opencode` from your project.
Iโll publish the copy-paste configuration and production compatibility status when the endpoint ships.
Solid question, @KrystianDeFi.
The inference pool is currently designed to create product usage. As more developers route through Manyways, builders can compete to create strategies that reduce cost or improve results. Publishing and scaling those strategies would require staked $MANY.
Holders who do not use the API could delegate $MANY to strategies they believe in. Their stake would help those strategies qualify for production traffic, while real usage and measured performance determine which strategies grow.
I want token fees to keep funding inference. Revenue from enterprise routing or a strategy marketplace can fund rewards for builders and delegates once that revenue exists. That gives holders a role tied to useful work and product demand, without pretending passive holding creates value on its own.
I absolutely want to drill-in more on how holders (perhaps not users) can further find value in their tokens outside of a simple investment.
Community time.
Iโve worked in product across a few successful startups, and I learned the same lesson at each one: users need a hand on the roadmap. You live with the friction, find use cases the team missed, and show us which features earn a place in the product. My job is to listen for patterns in that feedback, then pair what I hear with my own judgment about where the market is heading and where we can build an advantage.
I have several releases slated for the next 48 hours. However, I want your input on what else should be factored in. Send me a specific ask, a rough idea, or a point of friction. Call out what we missed. Tell me where $MANY falls short today and what would make it more useful for the work you want to do.
Iโll read it all, ask questions, and use the strongest signals to set priorities.
Feel free to drop a direct message, or share in the thread.
I suppose I'll take the compliments! In the meantime, a peek in on what is being implemented. You'll see small(er) components that make up these whole parts over the next few hours as they begin to get implemented.
I suppose I'll take the compliments! In the meantime, a peek in on what is being implemented. You'll see small(er) components that make up these whole parts over the next few hours as they begin to get implemented.
How does efficient routing work within the API?
Aside from simple slow vs fast routing efficiencies. I'll be introducing Manyways Strategies, which will exit QA testing soon and be available for a pool of early users.
Stake $MANY to enable specific inference strategies for your API Key.
Use Switchyard to send routine agent turns to an efficient model and move errors, loops, or hard reasoning to a capable one. Set cost and latency limits, choose cheaper capacity when the request can tolerate it, and define your own fallbacks.
Before putting a new model in the route, run it in shadow against sampled traffic. Your users still receive the primary response while you compare cost, latency, and output quality. Refine the strategy, publish it, and serve it through one API. This is how $MANY turns model routing from a closed platform decision into infrastructure users can test and build themselves.
Users in a specific wallet pool that have used the API feature will be added to the alpha.
Switchyard Repo: https://t.co/sQfdA5IaRS
If you experience any consistent issues with a single model, or single prompt, please flag it to me here or within a direct message.
We'll modify any existing caches if a provider suddenly misbehaves upstream, and ensure it's resolved quickly.
For example - noticed a fresh batch here, which was a quick solve.
Democratized and observable inference, $MANY.
0xa26992c4268a8a78a4d872fe4bdad2ed03ac287d