Build your agentic credit score from your github profile credit profile and give your agents money to spend. Enable your agents to access 1400+ tools like Exa, Firecrawl, Fal (media generation), Apollo.io, Browserbase, Modal and a lot more with just one MCP. Installing Vaaya is simple just run npx @vaaya/mcp install
Free
Launch Team / Built With
LoomHit record, hand off to AI
Promoted
Cool concept but I'm stuck on the trust model - a github profile is not a hard identity, it can be bought, forked from, or built up with throwaway contributions. What stops someone from renting an aged high-star account to unlock a bigger agent spending limit, then walking away once the bill comes due? Curious how you're weighting signal vs just profile age/stars.
@omri_ben_shoham1 Fair challenge, and you're right that a GitHub profile is not a hard identity. We don't treat it as one.
The thing that blunts your specific attack is that the GitHub line is card-gated. Nothing from it is spendable until a card is on file, and that card settles whatever gets drawn. So renting an aged high-star account gets you a bigger number on the screen, not free money. On top of that the amounts are deliberately small. We're underwriting tens of dollars, not thousands, so acquiring and burning an account costs more than the payoff.
That sizing isn't an accident. I've spent time in alternate lending, where thin-file underwriting always has exactly this problem. The answer there was never a perfect signal, it was small limits, fast feedback, and tightening as you learn. Same playbook here.
On weighting, it isn't stars or age. Those are the cheapest things to manufacture so they carry the least. I won't pretend the current model is more than a starting point though, and we're actively improving it.
The real unlock is spend history. Once accounts have a track record of drawing and repaying, that becomes the primary signal and GitHub drops to secondary. That's effectively a FICO equivalent for a developer profile, and it's what we're building toward.
@omri_ben_shoham1 @apoorv_khanna
Like Omri, I have many of the same questions. I was one of the guys who, in India, created Samsung Finance +, so the notion of trying to essentially make FICO equivalents, yep, been there, not an easy problem. Unless I missed something, linking a credit card to your system does not add something I already have. I can get a pre-paid Visa, let my agent have at it and if she/it goes rogue, i'm protected to the 10 bucks I have on the pre-paid card, right? So, I applaud the effort here, but I'm missing (respectfully) the value-add/point. I see this as, maybe, closer to zapier's MCP with a zillion connectors which in and of itself, is valuable.
@omri_ben_shoham1 @rick_segal1 We've been in the same trenches. I scaled India's first BNPL, so when you say FICO equivalents are not an easy problem, I'm not going to argue with you. And you're right about the prepaid card. For loss containment it's equivalent. That's not the value-add, and I won't pretend it is.
The gap the card doesn't close is access. A prepaid Visa doesn't get your agent an Exa account, a Firecrawl key, a fal account, a Modal account and seventy more, each with its own signup, its own key and usually its own monthly minimum. Most of those vendors won't sell you two cents of anything. We buy wholesale and meter per call, so your agent spends a penny on a search and thirty three cents on an image with no subscription anywhere. That's the part a card cannot do.
Second piece: every call is priced before it runs and carries its own ceiling, and a failed call costs zero. So the limit isn't one blunt number for the month, it's per action. A prepaid card can't decline call forty seven for costing more than you intended.
On credit, you're right that it's the hard part and I'm not claiming we've solved it. The GitHub line is deliberately tens of dollars, card-backed, and built with no external funding. It's a proof of concept whose real output is data. Once we have enough draw-and-repay history, that becomes the underwriting signal and GitHub drops to secondary. That's step two, and this is how we get the data to earn it.
@apoorv_khanna ,
Excellent answer and your buying wholesale and selling 2 cents worth is indeed a value prop on top of me not having to mange a million keys/accounts. So, might I suggest you clarify the product description and value with what you just told me since 90% of the fine folks who roll into PH, don't read these discussions and your comments are exceptionally clear when explaining what you're doing. I do miss those crazy days getting Aadhaar and all the KYC adventures. I truly hope you're successful; will be cheering you on!
@apoorv_khanna That's a fair answer - card-gated settlement plus deliberately small dollar amounts does neutralize the rented-account attack I was pointing at, since the payoff never clears the cost of acquiring the account. Good to see the FICO-equivalent roadmap is the actual plan rather than the GitHub signal being treated as the finished product. Curious to see how the spend-history model handles a legitimate account that just has thin early history versus one that's actually risky - that's usually where thin-file underwriting gets noisy.
@omri_ben_shoham1 That's exactly where it gets noisy, and I don't think there's a clever answer at t=0. A thin legit file and a thin risky file look identical on day one. Any model claiming to separate them is overfitting.
So we don't try. Everyone starts small, and the limit is sized so being wrong about you is cheap for us.
What protects you isn't a better score at signup, it's how fast we learn. Card-backed settlement means the first repayment event lands within a week, immediately once drawn credit crosses $50. Thin-file underwriting is brutal when your feedback loop is 30 to 90 days. When it's days, you can start almost blind and correct quickly.
What resolves the ambiguity is shape, not size. Legit thin files look like work: draw spread across different services, spend that tracks something actually being built, repayment that shows up. The risky pattern is a burst against the full limit on day one and then silence. And because every call is priced before it runs and a failed call costs zero, we see exposure per action as it happens rather than as one number at month end, so the shape shows up early.
When it stays genuinely ambiguous, we'd rather under-limit. Being too tight on a real developer costs them a prepaid pack and a week before the line grows. Being too loose costs us a write-off. That asymmetry is easy to respect, so we take the cheap error and let behavior buy the increase.
github profile as agentic credit score is clever 🙌 solo devs using it most?
@petrkovacik Mix of small teams and solo builders who are fed up with monthly Saas payments and use a basket of tools while building/ selling...also the reason why we seen people stick around is the ease at which the agent now does things. I simply cant work without vaaya installed on my claude code now. (early sign of PMF atleast for me, haha)
been exploring Vaaya recently the idea of giving agents access to real tools without managing a separate setup for everything is pretty interesting. Excited to see how this evolves. 🙌