폭주하는 AI 에이전트 비용을 위해 로컬 최초의 TypeScript 가드를 구축하고 있습니다.

작성자

카테고리:

← 피드로
DEV Community · Assili Salim · 2026-06-16 개발(SW)

Assili Salim

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

원문에서 계속 ↗

코멘트

답글 남기기

이메일 주소는 공개되지 않습니다. 필수 필드는 *로 표시됩니다