Your AI calls are already fetch() calls. Track them with one flag.

If you ship an app with AI features, you probably know roughly what you spend per month the provider dashboard tells you that. What you usually don't know is which feature, which route, or which user is burning the tokens. The provider dashboard aggregates.

Your app doesn't.

And your error tracker doesn't fill the gap either. It'll tell you a request failed, but it has no idea that request was a GPT-4o call that cost you four cents and took eight seconds.

That's the problem FlareLog's AI observability is built around: treat AI calls as first-class log events with tokens, latency, cost in USD, tool calls, and errors without wrapping every call site in your codebase.

Here's how it actually works, starting from the documented quick start.

Start with zero config

npm install @flarelog/sdk

import { flarelog } from "@flarelog/sdk";

const logger = flarelog({});
logger.info("Hello!"); // → console (zero config)

No API key means it just logs to the console. Add a key and it ships to the dashboard:

FLARELOG_API_KEY=fl_your_key

I like this setup because you can try it in an existing project without signing up for anything first. Console logging isn't exciting, but it means "install the SDK" isn't a commitment.

The one flag that matters: ai: true

This is the part worth understanding. From the docs:

import { flarelog } from "@flarelog/sdk";

const logger = flarelog({
  apiKey: process.env.FLARELOG_API_KEY,
  ai: true, // one flag — every fetch() to OpenAI/Anthropic/etc. is captured
});

One flag. No provider wrappers, no logAiCall() sprinkled through your handlers. Under the hood it instruments fetch, so every call to OpenAI, Anthropic, Cloudflare Workers AI, the Vercel AI SDK, or any OpenAI-compatible gateway gets captured tokens, latency, cost in USD, tool calls, and errors.

Because it sits at the fetch level, your existing client code stays untouched. If your app already works, this doesn't change how it works

it changes what you can see.

When you want more control

ai: true is the zero-config path. When you need fine-grained behavior, pass a config object instead:

const logger = flarelog({
  apiKey: process.env.FLARELOG_API_KEY,
  ai: {
    captureSamples: true,
    priceOverrides: { "gpt-4o": { input: 2.5, output: 10 } },
  },
});

Two things worth calling out here:

priceOverridesexists because pricing is a moving target. If you're routing through a custom gateway, running a fine-tuned model, or a provider changed their rates before the SDK caught up, you set the per-token prices yourself and the cost math stays honest.

captureSamplesgives you request/response samples, which is the fastest way to answer "why did this specific call behave weird?"

Attach it manually (and detach it)

If you'd rather control instrumentation explicitly say, only in certain environments — there's a direct API:

import { flarelog, flarelogAI } from "@flarelog/sdk";

const logger = flarelog({ apiKey: process.env.FLARELOG_API_KEY });
const handle = flarelogAI(logger);
// handle.dispose() to remove instrumentation later

Handy for tests, or for turning AI tracking on and off at runtime without rebuilding the logger.

The streaming gotcha you'll want to know early

This is the kind of detail you'd normally discover in production, so here it is up front: OpenAI streaming doesn't report usage by default. If you want token capture on streamed responses, you have to opt in on the request itself:

await fetch("https://api.openai.com/v1/chat/completions", {
  method: "POST",
  headers: { Authorization: `Bearer ${process.env.OPENAI_API_KEY}` },
  body: JSON.stringify({
    model: "gpt-4o",
    stream: true,
    stream_options: { include_usage: true }, // ← required for streaming token capture
    messages: [{ role: "user", content: "Hello" }],
  }),
});

Anthropic and Workers AI report usage automatically — no changes needed there. But if your streaming OpenAI calls show tokens of zero, this line is why.

Why this works on edge

The SDK is zero-dependency, so there's nothing to audit and nothing to conflict with your bundle. It runs on Cloudflare Workers, Vercel, Node.js, and browsers. On Workers specifically, flushing uses ctx.waitUntil, so your logs actually survive after the response is sent — a classic edge gotcha that most logging tools don't handle.

It also does W3C trace propagation, so an AI call shows up in the context of the request that triggered it, not as an isolated event.

The lock-in question

Fair to ask: does your observability data now live in one vendor's dashboard? FlareLog is OTLP-compatible, so it ships to Grafana, Honeycomb, Datadog, or any OTLP backend. The instrumentation lives in your code; where the data goes is your call.

Wrapping up

The pitch is simple: AI calls are already fetch()calls flowing through your app, and one flag turns them into structured, costed, searchable events. The full flow is four lines of setup, and the only real gotcha — streaming usage on OpenAI is one line in your request body.

Links if you want to dig in:

FlareLog
SDK on npm
Docs
AI observability dashboard

How are you tracking AI spend per feature right now provider dashboards, spreadsheets? Curious what's actually working for people.