I’m building a local-first TypeScript guard for runaway AI-agent costs

Assili Salim — Tue, 16 Jun 2026 10:07:36 +0000

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

GitHub:
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

DEV Community: Assili Salim

I’m building a local-first TypeScript guard for runaway AI-agent costs