Our mission is to build open tools that help developers and enterprise create AI applications they trust.
Joined July 2025
- Tweets1.2K
- Following427
- Followers3.7K
- Likes3.3K
Corbits retweeted
Agentic uncoupling?
@ryancarson built @HelloUntangle to help people going through divorce. If there are tons of apps for weddings, shouldn't there also be an app to make a not-so-fun process a little easier?
youtube.com/shorts/uK1GRuOkM…
Corbits retweeted
What's new in v0.3.12 and v0.3.13 of Corbits Code?
- Opencode Go adapter improved and models dynamically show up from their API now
- Ollama adapter added with automatic model discovery
- Agent prompt improvements and fixes
- Various performance improvements and fixes
Get started at github.com/corbitsdev/corbit… for the coding agent that gets out of your way
Corbits retweeted
Shoutouts:
The @corbitsdev dispatch skill completely changed how I build with AI. Their agent team + skills ran the whole build. And the wizard helping me @TheGreatAxios
Deep research and AI guru assist: @ShanuMathew93
Site is standing on great public research: @GavinSBaker on @patrick_oshag's Invest Like the Best, @dwarkesh_sp on compute economics, @alfongj's Everything Router, @PanteraCapital's Stateful pod, @SemiAnalysis_ data, plus Epoch AI + METR, and more! Incredible time to have access to all of this.
every claim cited with sources + methodology: ai-scan-gamma.vercel.app/sou…
Corbits retweeted
If you are building open weights models in the US @corbitsdev will support & contribute
If you are building a startup around open intelligence I will feature you on my podcast to our 135k subs and potentially invest if there is the opportunity
OpenRouter is one of the most insane stories in tech.
Co-founded by OpenSea founder, Alex Atallah. It has become one of the most important companies in AI.
Scaled to 100s of millions in revenue and wildly profitable.
They process 25 TRILLION tokens every week and will do 1 QUADRILLION tokens this year.
As a result, Stripe have reportedly offered to buy them for $10BN.
Last round was $1.3BN just months ago… so what happens now?
I sat down for a chat with OpenRouter Founder, @alexatallah and have summarized my notes below:
1. This Is Going to Be the Biggest Market in the History of Tech
AI model inference is set to become one of the largest markets in technology. Even as token prices fall dramatically, Jevons Paradox means usage can grow far faster than costs decline, driving massive overall compute consumption across an increasingly multi-model future.
2. Why None of the Routing Products Being Created Today Will Compete With OpenRouter
Building AI gateways has become trendy, but copycat routers that treat routing as a side feature are playing to exist rather than to win. True routing requires relentless focus on optimizing latency, cost, and constantly shifting model quality while giving developers maximum flexibility.
3. Model Labs Have Every Incentive to Come After Your Startup Eventually
Startups building thin wrappers around AI models face an existential threat if they occupy workflows that frontier labs consider strategic. Releases like Claude Design show how labs can move up the application layer, absorb valuable use cases, and lock entire enterprise teams into their ecosystems.
4. One New Model Every 10 Hours and the Myth of Model Consolidation
Model creation is accelerating as hardware companies, Neo Labs, and agent frameworks continuously release specialized models. Rather than consolidating around a single winner, developers are embracing diverse models optimized for different tasks, reinforcing a fragmented, multi-model future.
5. America Is Still Very, Very Behind in Open-Weight AI
The U.S. remains significantly behind China in the race for open-weight models. Chinese labs benefit from aggressive state support and open-source momentum, while American efforts face business model and capital constraints. Closing the gap will require dedicated access to compute and sustained investment.
6. How Open-Weight Models Are Rapidly Closing the Gap on Frontier AI
Models like Kimi K3 and the 5.2 generation show how quickly open-weight intelligence is closing the gap with proprietary frontier models. Using low-cost open models for deterministic subtasks beneath a frontier orchestrator can maintain output quality while sharply reducing inference costs.
7. Why We Need to Think About Employee Cost Completely Differently
In the AI era, employee cost is no longer just a fixed salary. It increasingly includes the variable inference spend of the AI tools each employee deploys. Companies will need to evaluate workforce performance through a cost-to-productivity lens that accounts for both human compensation and AI consumption.
(links in comments)
Corbits retweeted
Today's been a fun release. s/o @TheGreatAxios for changing how we work at @corbitsdev
Corbits retweeted
Corbits, an AI operations platform that runs open-source agents together in one workspace, has integrated NEAR AI for private, verifiable inference and IronClaw for secure agent orchestration 🧵
1/5 Whenever your team sends something to a hosted AI model, there’s a good chance you’re including sensitive info, maybe a transcript, customer data, or an internal document.
Calling something "private AI" doesn’t mean much unless you can actually prove it. That’s why we decided to partner with @near_ai.
See the full story here: corbits.dev/blog/ai-privacy-…
Corbits retweeted
My farm truck wont pass inspection due to rust. I built an agent that scrapes facebook marketplace for me, gathers the details from the seller that i need, evaluates the truck for rust, milage, seats etc.
Then either messages for more info, passes, or suggests an offer. Full auto until the offer stage when i review.
Saving me a ton of time and built on interchange so that i have system level permissions / guardrails for what it can and can not do on my machine.
I'll happily open source it if anyone wants it - runs locally and is model agnostic.
RIP farm truck.
Corbits retweeted
Most agents today carry their own credentials. The API key is injected into the agent's environment, and the agent makes direct outbound calls to the services it needs. The container or VM is the trust boundary. The agent is just code running inside it.
Interchange changes that boundary. The agent does not carry credentials. The organization does.
Interchange is an operating system for agents. Agents declare what they need, but the system decides whether they get it and never hands the secret to the agent itself.
Not "agents store credentials in a vault." Not "agents rotate credentials frequently." The agent never has the secret, never sees the API key, and never makes a direct outbound call to a third-party API.
Freddy is an experimental agent that wraps all of Firecrawl: scrape, crawl, extract, search, browser automation, and usage monitoring. He is also surprisingly honest about his own limits, which is rare. But Freddy is the demo, not the story.
Freddy runs in a sidecar. Think of it as a locked container. The sidecar has no secrets. It cannot call Firecrawl directly. It can only talk to the hub.
The hub is the backend control plane. It stores credentials, enforces rules, and decides what agents are allowed to do [+ it can be extended with your own custom logic].
The credential lives in the tenant. "Tenant" is Interchange's word for the organization boundary. ABK Labs is the tenant here. The Firecrawl API key was added once to the tenant by an administrator, and it belongs to the organization (tenant), not to Freddy, not to me.
Freddy's definition is pure code. It declares one thing: "I need the Firecrawl credential. Source: the organization." There is no process.env, no injected secret, no runtime configuration. The definition is a blueprint that says what it needs, not a container that carries what it has.
When I deploy Freddy, the system checks my authorization first. It looks up who I am (my "principal" is just my identity in the system) and asks whether I have permission to use the Firecrawl credential and whether the organization allows me to deploy an agent with this capability.
These permissions are called "grants." They are the explicit rules that say who can access what. If I have the right grants, the agent launches. If I do not, the launch fails immediately. The credential is resolved at the organizational boundary, not the agent boundary.
At runtime, the flow is strict. Freddy decides to call a tool, but he cannot reach Firecrawl. He is locked in the sidecar. He sends the request to the hub.
The hub receives the request, looks up the credential from the organization's vault, attaches the API key, forwards the request to Firecrawl, gets the response, strips the credential, and returns the result to Freddy.
Freddy sees the data. He never sees the key. The sidecar never sees the key. Only the hub touches the secret.
If the credential rotates in the vault, every agent using it gets the new credential on the next call without redeployment. If an agent is compromised, the attacker has no secrets to extract because the agent never had them. If someone leaves the organization, their grants are revoked and their agents lose access. There is no key rotation across every deployed agent.
The same pattern works for the LLM, for GitHub, for any provider. The agent definition is portable, versioned, shareable code. The secrets are organizational infrastructure. Authorization is checked at deployment. Runtime calls are mediated by the hub.
This is the difference between treating agents as scripts with API keys and treating them as programs that run inside an operating system. The agent does not carry its own credentials; the organization does. The agent does not make its own outbound calls; the hub mediates them. The agent does not decide what it can access; the organization's grants and policies decide.
Built on @corbitsdev Interchange
ALT This is a screenshot of the organization space (i.e a Workbench) where I'm chatting with Freddy, the Firecrawl agent.