We’re opening up free compute so more users can actually try Darwin Compute for themselves.
No long explanation needed
plug in your agent, test the infrastructure, see how it performs, and get a feel for what additional compute can unlock.
We want builders to be able to experiment before committing to anything.
Try it.
Stress test it.
Build with it.
Tell us what breaks.
The best way to improve Darwin is to get it into more hands.
We hit a small obstacle recently that slowed us down for a bit, but we’ve worked through it and we’re back on track.
The focus now is getting Darwin Compute moving at full speed again.
We’re back to shipping updates, improving the compute layer, working on Bungee, adding better providers, and tightening the overall agent experience.
Setbacks happen when you’re building quickly. What matters is how fast you recover and keep moving.
We’re ready to push this project forward again and make up for the lost time.
A lot more is coming.
We’ve pushed another major update to Darwin Compute.
upgraded how compute is allocated, and started working with better infrastructure providers so agents can get access to stronger and more reliable resources when they need them.
A lot of what we’re building now is focused on making the compute layer itself better.
That means better availability, better routing, more consistent performance, and more options behind the scenes depending on what the agent is trying to do.
We don’t want Darwin to just give an agent “more compute.”
We want it to give the agent the right compute.
The right provider.
The right model.
The right amount of resources.
At the right time.
As we add more providers, the network gets stronger and gives us more room to optimize around performance, cost, and reliability.
There’s still a lot we want to improve, but the underlying compute stack is getting significantly better.
We’re genuinely grateful for everyone who’s been supporting Darwin Compute and showing love to the project.
We’re not slowing down.
We’re pushing updates constantly, improving the compute layer, adding more models, tightening the agent experience, and shipping new features as fast as we can.
Every day we’re trying to make Darwin more useful, cheaper, smarter, and easier to plug into existing agents.
We’re also working toward something much bigger.
We’re currently exploring releasing our own open-weight model on Hugging Face, built around the same idea behind Darwin: giving agents more capability through better use of compute.
That’s still early, but it’s something we’re actively trying to make happen.
We want Darwin Compute to become more than just infrastructure.
We want it to be part of the stack people think about when they’re building serious agents.
Thank you to everyone using the project this early.
We won’t stop working.
Coming to Darwin: Swarm.
Right now an agent works through a list one job at a time. Forty files to summarize means forty calls in a row, and the agent waits on every one.
Swarm changes that. Your agent hands Darwin the whole list in one call, and Darwin runs the jobs at the same time on its own GPU: 4 at once on a normal workspace, 16 with Pro. When they're done, every result comes back together in one reply, each with the model that wrote it and what it cost.
It's built for the work agents do in bulk: summarizing files, writing tests, checking links, pulling fields out of documents, first drafts. The hard reasoning stays with your main model, and the busywork runs in parallel on Darwin.
Claude Code using Darwin over MCP.
This is one of the first things Darwin does for agents: it gives them more usage than their own limits allow, and compute of their own. Claude hands a task to Darwin, Darwin's GPU answers, and it shows which model did it and what it cost.
This is where we're starting, and we're adding more. Codex support, spend caps per key and more models are on the way.
We’re posting a video shortly showing exactly how to use Darwin Compute.
We’ll walk through how to plug it into an agent, give that agent more compute, and use the tech properly from start to finish.
Should make the whole thing a lot easier to understand.
Darwin takes your key either way clients send it: as a Bearer token, the OpenAI style, or as an x-api-key header, the Anthropic style. Both work on every endpoint.
So OpenAI and Anthropic clients need nothing special. Swap the address, paste the key, and that's it.
Add one OpenRouter key to Darwin and every model OpenRouter lists goes on your menu, in both OpenAI and Anthropic formats. That's the simplest way to reach Grok, DeepSeek, Mistral, Qwen, Llama and the rest.
If a model can be reached both directly and through OpenRouter, Darwin uses your direct key.
Mix them however you like on your list: Claude on your Anthropic key, then DeepSeek through OpenRouter, then Darwin's GPU.
https://t.co/hKMXLFC6JS
Darwin is paid for by burning $DARWIN. There's no card and no subscription.
You burn from your own wallet on the Credits page. Darwin reads the transaction back from Solana, checks the token, the amount and a memo naming your workspace, then adds the credit. Nobody can claim a burn they only spotted on chain.
Credit pays for Darwin's GPU and upgrades. Requests on your own provider keys don't touch it.
Your prompts are never stored.
One Darwin key works in Claude Code, Cursor, Continue, Aider, LangChain and the OpenAI and Anthropic SDKs.
Darwin speaks both formats, OpenAI chat completions and Anthropic messages, with streaming, tool calls and thinking where the model supports it. Change the base URL, paste your Darwin key, and your tools keep working the way they did.
Behind that one key is your whole list of models. Darwin checks each provider key you add with its provider before saving it, encrypted. Requests that go through your own keys don't touch your credit.
There's also an MCP server, for agents that would rather call a tool.
When your agent hits a rate limit, Darwin moves the request to the next model on your list, so the work keeps going. The limited model sits out until its limit resets, then it's back on top. The dashboard shows which model answered each request.