I'm 17, building from Lagos — just shipped hard spending limits for AI agents
AI agents were going over budget and nobody had built a real fix. Token limits don't stop tool calls. Prompt budgets are just suggestions. Monitoring alerts fire after the money is already gone.
So I built Valta — a pre-call enforcement layer that sits inside your agent framework and blocks any LLM call or API action before it fires if the agent is over budget.
Three weeks ago I published pip packages for LangChain, CrewAI, and OpenAI Agents SDK. Last week we got our first user. This week we integrated with the ANP2 protocol as their official enforcement layer — our signed gate events now settle real credit on a public ledger.
I'm 17. I'm in Lagos. I taught myself everything — cryptography, blockchain, distributed systems. No funding, no team, no visa.
Free to use: valta.co
pip install langchain-valta
Would love feedback from anyone building with AI agents.
This is a great solution and i will definitely try it out 👍
Yeah, the pre-call gate seems right. The money question always sneaks in because the check tends to happen after the call’s already been dispatched, which isn’t the point. I’m curious how you’re handling concurrency: if an agent fires a few tool calls in parallel (which most multi-agent setups push), do you lock the budget check per call or batch it somehow? Two calls could individually pass, but together push past the limit before any cost is actually deducted. And what about latency? Slapping a synchronous gate in front of every LLM and tool call adds a hop every time, how noticeable is that in agent loops that chain dozens of calls? The ANP2 ledger part is the most interesting to me, signing gate events for settlement on a public ledger is a way bigger hurdle than a simple allow/deny log, so if that’s really under pressure with real traffic, that’s a genuinely hard problem solved.
Hii i am 19 and also starting business , tho i am a bit late than you are , i have a bit of problem understanding the director of how i do things in early stage businesses , can you help me know how to be sure , what you’re doing is right?
Honestly the only thing I've found that works: ship something real as fast as possible and let users tell you what's wrong. You'll never be certain you're doing the right thing — the feedback loop from real usage is the only signal that matters.
This is inspiring — 17, Lagos, no team, self-taught cryptography and distributed systems. I'm building from Abuja myself, shipping AI subscription platforms and Telegram bots from just a phone and Termux. The pre-call enforcement angle is smart — reactive monitoring is always too late. Rooting for you bro 🇳🇬
Building from Abuja on a phone is harder than anything I'm dealing with. Reactive monitoring being too late is exactly it — by the time the alert fires, the damage is done. Keep shipping bro 🇳🇬
token limits not stopping tool calls is the specific failure mode that makes AI agent cost control genuinely hard. an agent can be well within its token budget and still make fifty API calls to external services that cost more than the LLM calls combined. solving the enforcement layer for the whole action surface rather than just the model calls is the right scope for this problem
Exactly right — and most teams don't realize this until they get a bill where the LLM cost is $20 and the tool call cost is $800. The enforcement has to sit at the action surface, not just the model layer.
Good stuff! On OpenRouter, you can pre-load your wallet in order to set a spending limit. Is this different from that?
OpenRouter's wallet is account-level — one limit across everything. Valta is per-agent, per-framework, enforced before the call fires in your own code. If one agent hits its limit, the rest keep running normally.
Real problem, real solution. I run 10+ AI-powered apps and hit the exact pain point you're describing — my monthly API bill hit $10K before I got serious about cost control.
What I found is that enforcement (what Valta does) and efficiency are two sides of the same coin. Hard spending caps stop the bleeding. But the thing that actually brought my bill from $10K to $3K was routing — sending simple tasks (boilerplate, tests, docs) to cheaper models instead of defaulting everything to the most expensive one.
The combination would be powerful: route intelligently to maximize what each dollar buys, then enforce hard limits as a safety net so a bad loop can never run away regardless.
The "enforcement vs efficiency" distinction Debo made in the comments is sharp. Most people conflate the two. Valta solves enforcement cleanly. Routing solves efficiency. You need both.
Impressive execution for 3 weeks, especially the multi-framework support. Keep shipping.
When the limit is hit, Valta raises a typed exception —
BudgetExceededError— that the calling code can catch and handle. The agent doesn't stall, it gets a clean signal it can respond to. Graceful degradation is a first-class concern, not an afterthought.Pre-call gate is the right call, monitoring tools just hand you the receipt after the damage is done. Quick question: when an agent hits the limit mid-task, does the calling code get a structured error to catch and recover from, or does it just stall?
Amazing 😍
Thank you, means a lot, keep watching 🙏" — don't overthink these.
Congrats man. Keep up the progress!
awesome stuff bro, rooting for you
This is awesome, I'm 15 and building my own app (an iOS marketplace connecting indie devs with creators), so it's cool to see another young founder shipping real stuff.
The AI spending limits feature is smart, feels like something a lot of people will need as more apps integrate AI agents that can rack up costs without anyone noticing. Did you build this after running into the problem yourself, or did it come from talking to other users first?
Insane stuff, man! Building this at 17 is pure inspiration. I'm also deep into AI tools and automation suite setup. Definitely locking this on my radar. Keep shipping! 🚀
at 17? damn, massive respect for shipping this. managing spend limits for AI agents sounds like a nightmare honestly, especially with how random token usage can get. real talk though — since you're dealing with financial logic and API limits, a single logic bug or race condition could get pretty expensive. how are you testing those spend paths? just self-reviewing the code, or are you thinking of getting a quick manual sanity check before you start scaling up?
The pre-call position is what makes this real. Token limits and alerts all land after the money already moved, like you said, so putting the gate before the call fires is the only spot that stops anything. The thing I keep thinking about: your gate already holds the call before it executes, which is the one place you could enforce on more than spend. A budget cap stops the expensive mistake. The same chokepoint is also where you'd catch an in-budget action the agent got talked into by something it read. Curious whether the gate sees enough of the call's intent to go past cost, or if that's deliberately out of scope for now.
When the limit is hit, Valta raises a typed exception —
BudgetExceededError— that the calling code can catch and handle. The agent doesn't stall, it gets a clean signal it can respond to. Graceful degradation is a first-class concern, not an afterthought.A typed BudgetExceededError the caller can catch is the right shape for spend, that part's clean. What I'm still chewing on is whether the gate sees what a call is trying to do, not just what it costs. That same pre-call spot is the only place you could also stop an in-budget action the agent got talked into by something it read. Is intent visible at that layer, or is it cost-only by design for now? Either answer is fair, just curious where you drew the boundary. Wild that you're shipping this at 17, by the way.
The pre-call gate is the right model. Monitoring tools give you receipts. You're building the actual control layer.
One edge case I'd be curious about: what happens when an agent hits the limit mid-task? Valta blocks the next call, but does the calling code get a structured error it can catch and recover from, or does the agent just stall? The graceful-degradation story is probably what closes enterprise deals.
The execution is what stands out more than the feature: pip packages for three frameworks plus an ANP2 integration in three weeks, self-taught, no team. That pace is the thing I'd bet on. One thing to get right early: sitting in the critical path is both your wedge and your biggest adoption risk. Devs will trust a hard gate until it false-blocks once in production, then they rip it out and never come back. So the roadmap priority isn't more frameworks, it's making a wrong block impossible to cause real damage (dry-run mode, soft caps before hard caps, a clean override). Nail that and the burned-dev buyer becomes a permanent install instead of a trial.
Dry-run mode and soft caps before hard caps are going on the roadmap this week because of this comment. The false-block risk is exactly the adoption killer I hadn't fully articulated — devs forgive slow, they don't forgive wrong. Thank you for this.
Moving on it the same week is the instinct that matters, most people just nod and forget. Keep that line, "devs forgive slow, they don't forgive wrong," because it's also your positioning. One add: make the soft cap loud. Log every time it would have blocked and surface it, so a dev watches it catch real overruns for two weeks before they ever flip on the hard cap. Trust in a kill switch is earned by watching it almost fire and be right. You're 17 building infrastructure devs will actually depend on. Keep going.
This comment was deleted 3 months ago
Solo builder here, I run agentic coding tools daily (Cursor) so runaway spend is a real fear for me. The "$5 not $25" framing is what makes this click — it's insurance, not optimization. One thing I'd watch from the buyer side: your strongest converts are devs who already got burned once. The proof that sells isn't the architecture, it's a screenshot of "I set $10 and it stopped at $10." Put that front and center. Respect for shipping ANP2 integration at 3 weeks old, that's fast. Rooting for you.
Screenshot of "I set $10 and it stopped at $10" — adding this to the landing page this week. That's the proof that matters, not the architecture diagram.
Great job, Do you use semantic caching and context explosion to reduce the token costs as well?
Wow, this is a massive milestone, Debo! You solved a real problem. Current observability tools are purely reactive—they just tell you after you’ve already racked up a $500 bill. A pre-call enforcement layer is exactly what the agent ecosystem needs right now.
The ANP2 protocol integration is huge for a 3-week-old project. Since you are handling signed gate events, how are you managing latency? Does Valta add any noticeable delay to the agent’s execution loop?
Kept it up, definitely starring the repo!
Strong idea, especially the shift from reactive monitoring to true pre-execution enforcement — that’s exactly where most budget tools fail today.
Blocking LLM and API calls before they fire is a much more reliable way to control spend than after-the-fact alerts, especially in autonomous agent workflows where costs can scale quickly.
The biggest challenge will likely be trust and adoption, since you’re effectively sitting in the critical execution path of multiple frameworks. Any latency, false blocks, or edge cases will matter a lot.
Fair point. Valta doesn't abstract the SDK — you still call LangChain or CrewAI directly. The gate wraps the spend decision, not the model call. So if OpenAI deprecates a model, your agent breaks the same way it would today — Valta just ensures it broke within budget. SDK abstraction is a different product and a harder one.
cost enforcement is the easy part. the model itself getting deprecated or killed - that's the harder risk. does Valta abstract the SDK layer too, or are users rebuilding gates every time a vendor changes their API?
You're right that framing matters. The current bet: developers who've already been burned by a surprise bill are the buyer, not developers evaluating abstract governance. The proof that matters is "I set a $10 limit and it stopped at $10." That's a very short sales cycle. The philosophical question of what they think they're buying gets answered by the bill they didn't get.
yeah, burned devs convert faster than curious devs - they're not evaluating the concept, they're buying insurance against repeating the mistake. '$10 stopped at $10' is perfect for that buyer.
Interesting build.
The thing I'd be careful with is that the challenge may not be whether agent builders need stronger budget enforcement.
The harder question may be what decision they believe they're making when they adopt it.
That sounds subtle, but it can quietly shape the buyer, the proof that matters, and how future adoption gets interpreted.
I wouldn't make that call casually this early.
Good question — it raises an exception before the next call fires, so the agent stops at the boundary between calls, not mid-generation. Whether that leaves things in a broken state depends on how your agent handles exceptions. We're working on a graceful shutdown hook that lets you define what "stop cleanly" means for your workflow.
Possibly.
The reason I'd still be careful is that I don't think the interesting part is the budget boundary itself.
I think there's a more important decision sitting underneath it.
That's one of those things that can quietly shape who adopts the product, what proof matters, and which signals end up looking like validation.
I wouldn't try to unpack that properly in a thread.
If you're curious, drop your email and I'll put together the tighter version.
Appreciate it — what's the core point? Happy to discuss it here.
The problem is that the core point is the part I'd be careful trying to summarize in a couple of comments.
Once it's reduced to a quick thread answer, it usually loses the reasoning that makes the decision useful in the first place.
If you're curious, drop your email and I'll put together the tighter version properly.
As someone who uses Claude Code daily,
runaway AI costs are a real thing.
Curious — when the spending limit kicks in
mid-task, does the agent stop cleanly or
does it leave things in a broken state?
You're describing a different problem — efficiency, not enforcement. Valta stops the runaway spend. It doesn't make the agent smarter or guarantee results per token. Those are separate problems. But burning 2,500 credits on a broken agent would have been capped at whatever limit you set — you'd have lost $5 not $25. The project still needs fixing, but at least you're not broke while you fix it.
That reframe helps — enforcement vs efficiency is a cleaner way to think about it.
The "$5 not $25" framing is exactly the kind of thing that makes a product click.People don't need it to be perfect. They need it to stop the bleeding while they figure out what's wrong.Makes sense. Rooting for it 🙌
u has a good idea, and it's definitely a real problem. But for someone building a critical project — an independent developer — does this approach actually help? If the tool just stops the agent from spending tokens, doesn’t that also stop the project from moving forward?
I ran into this myself with WorkBuddy. I tried to solve two problems and burned through 2,500 credits in no time — and still didn’t get a working solution. In the end, I just had to delete the agent and focus on making the project work first, without worrying about cost control.
So yes, preventing runaway costs is important. But what we really need is not just a "budget cut-off" — we need a way to ensure that the tokens we spend actually lead to results. Otherwise, a hard budget cap just forces you to choose between going over budget or killing progress entirely.
Latency is sub-millisecond — it's a DB read, not an API call. False blocks only happen if you set your limit wrong, same as any budget tool. The enforcement is synchronous by design — sitting in the path is the point. That's what makes it a hard stop vs a dashboard you check later.
Rooting for you my bro
Thanks. I Would really appreciate a signup
Cool website, but why don't u just get an Api key and set limit for it
API key limits work at the provider level — but if your agent is using multiple providers (OpenAI + Anthropic + tool APIs), you'd need separate limits on each one. Valta enforces across all of them from one place, at the agent level, before any call fires.
I would really appreciate a sign up