# I’m building a local-first TypeScript guard for runaway AI-agent costs > Source: > Published: 2026-06-16 10:07:36+00:00 I’m building AI CostGuard, a local-first TypeScript / Node.js runtime safety layer for AI agents. The problem I’m working on is not model quality or prompt engineering. It is the boring failure mode where an agent keeps making provider calls because of bad control flow: retry storms similar prompt loops max-step explosions unknown model pricing accidental budget overruns repeated calls with no useful progress The goal is to block risky calls before the provider API execution happens. The current API is centered around guard() and guardFunction(). The package currently includes: local-first runtime checks CLI budget checks local-only dashboard opt-in JSONL event logs structured errors mocked runnable examples for OpenAI, Anthropic, Vercel AI SDK, LangChain-style usage, Mastra-style runners, CrewAI budget gating, and CI checks Why this matters: A lot of tooling shows what happened after the agent already spent money. I’m interested in the smaller pre-call question: “Should this agent be allowed to make another provider call right now?” Limitations: token estimation is approximate provider pricing can change false positives are possible false negatives are possible local-first state has limits this is not a SaaS this is not a billing ledger this is not a hard security boundary this does not replace provider billing alerts or production observability npm: [https://www.npmjs.com/package/@salimassili/ai-costguard](https://www.npmjs.com/package/@salimassili/ai-costguard) GitHub: [https://github.com/salimassili62-afk/ai-costguard](https://github.com/salimassili62-afk/ai-costguard) I’d appreciate technical feedback on: whether guard() / guardFunction() feel natural how false positives should be handled whether local-first state is actually useful in real agent systems what pricing assumptions are dangerous what failure modes I’m missing whether this should stay small or become more configurable