Jev Logs

It stays local, and is explicitly a development tool rather than a hosted collector. You run npx jevlogs --live in your project root, it binds to loopback only, and the receiver listens on http://127.0.0.1:4318/v1/logs until you stop it. Your existing archive and export pipeline stays exactly where it is; keep batches around 16 records and let your exporter handle backpressure, since concurrent batches get 503 with Retry-After.

Only the body, severity, and service.name, and only after the SDK's redaction. Other resource attributes, the scope, and trace IDs stay on the callback record and are never sent. If you embed the server instead of running the CLI, note the asymmetry: redaction applies to model input while your onLog callback receives the original record, so your own storage policy has to handle it. The README calls default redaction a starting point, not a complete sensitive-data policy.

No, it stays eligible for analysis. A per-record timeout (two seconds by default), input larger than maxInputChars, and hitting maxModelCalls all leave the record routed as eligible rather than dropped, with a reason attached. Errors and records marked jev.protected=true bypass inference entirely, and confident low-value events are the only ones that can skip the analysis branch.

Yes, that is the sharp edge. HTTP success acknowledges that your callback completed, not that anything reached durable storage, so persist inside the callback if delivery matters, and expect to deduplicate yourself because retried requests are not deduplicated. The CLI receiver itself prints one JSON decision per record and stores nothing, which keeps it safe for local experiments but means the archive is still your job.

The worked example takes analysis from $200 a month to $49.40 on one million monthly logs by routing the 10% it judges low-value, with GPT-4.1 mini as the deeper model. Filtering happens before analysis on Jev's actionable probability, so the saving scales with how much of your traffic is genuinely not worth analysing.

AI_GATEWAY_API_KEY, and it is a Vercel AI Gateway key, not an OpenAI key and not a Jev Logs account. Provider usage is charged to your Gateway account and the AI SDK reads it server-side. Applications that only send OTLP logs never see the key, and it belongs in a git-ignored .env named by envFile rather than in jevlogs.config.json.

JSON and protobuf both work over HTTP, with or without gzip, up to 1 MiB and 100 records per request. Java, Go, Python, and the Collector default to protobuf and need no protocol override, while the JavaScript exporter sends application/json. gRPC is not supported and returns HTTP 501. GET /health checks the receiver, not model availability.