bedrock-meter

Know the cost of every AWS Bedrock call — before it returns. Then cap, degrade, or alarm on it.

bedrock-meter is real-time, in-process, pre-flight AWS Bedrock spend metering and capping. You npm install it and wrap your BedrockRuntimeClient; a TypeScript CDK construct provisions the store, control flags, budget, alarms, and the correct Bedrock IAM.

Why

1. Finest granularity, immediately, and before the spend. It prices every Bedrock call per-request, in-process, before the call returns — versus AWS's own actuals, which trail: we measured CloudWatch token metrics arriving ~13–40s after a call, and Cost Explorer / CUR dollar data only settling next-day (~24–48h). bedrock-meter gives you the number pre-flight. This is the core differentiator.
2. Built on (1): throttle, fall back, alarm. Because the cost is known before the call, you can refuse or cap it (onCapExceeded) and alarm — enforcement, not just observation. You pick the model; the meter meters it.
3. A grounded $0 fallback instead of an outage. When the cap trips, calls can fall back to an embedded deterministic no-LLM engine (tmct) that answers from grounded memory or refuses honestly — continuity at zero spend, never a silent model swap.

30-second quickstart

import { meter } from "@polycode-projects/bedrock-meter";
import { BedrockRuntimeClient, ConverseCommand } from "@aws-sdk/client-bedrock-runtime";

const client = meter(new BedrockRuntimeClient({ region: "eu-west-2" }), {
  caps: { dailyGbp: 3 },       // refuse the call once today's £3 cap is hit
  onCapExceeded: "throw",
});
await client.send(new ConverseCommand({ /* ... */ }));   // metered + capped
const today = await client.meter.spentToday();

Packages

More

• Source (GitLab)
• Evidence: estimate vs. actual drift report