[eli-r-ph]

Adds capture_ai() so Rust callers can send LLM analytics events to the live POST /i/v1/ai/events endpoint. AI events ride their own isolated transport lane, so a multi-MB AI event can never delay or displace analytics events. Targets v1; all public API changes are additive.

• Adds capture_ai, capture_ai_batch, capture_ai_immediate, capture_ai_batch_immediate, and the global posthog_rs::capture_ai, mirroring the analytics entry points.
• Adds Endpoint::CaptureAi and CaptureFailure::endpoint() so an on_error hook can tell which lane failed.
• Adds capture_ai_compression (mirrors capture_compression; unset sends AI bodies uncompressed, zstd recommended) and capture_ai_max_queue_size (default 1000).
• The AI lane has its own worker, queue, and retry state, started on the first capture_ai* call, and drained by flush/shutdown/Drop alongside the analytics lane.
• The AI lane batches by serialized bytes (5 MiB soft target) and drops events whose properties exceed the backend's 8 MiB ceiling locally, logging only the event name and size.
  • The immediate variants send oversize events instead and return the backend's ai_event_too_big verdict.
• Neither capture nor capture_ai inspects the event name; the backend decides routing and reports per event, and that verdict already reaches on_error.
  • Deliberate: $ai_-prefixed custom names are legitimate analytics traffic, and the analytics lane will start refusing AI names once feat(capture): both v1 lanes refuse the other's events posthog#95466 lands.
• A 2xx with per-event drops and no on_error hook now logs one aggregate warning per batch on both lanes; it was silent before.
• The analytics lane is unchanged: the worker and pipeline are parameterized by a lane config whose analytics variant reproduces the previous behavior, and the existing tests pass unmodified.

🤖 Generated with Claude Code

[veria-ai]

PR overview

All previously flagged issues have been addressed. No open security concerns remain on this pull request.

Security review

No open security issues remain on this pull request.

Fixed/addressed: 2 · PR risk: 0/10

[greptile-apps]

Prompt To Fix All With AI

### Issue 1
src/client/async_client.rs:180-185
**Shutdown races AI startup**

A first `capture_ai` call can observe the analytics transport as open just before `shutdown` snapshots the existing lanes. If shutdown closes only the analytics lane, `get_or_init` can then create a new AI transport with its own open state. The event is delivered after shutdown returns, and the new worker remains alive until `Drop`, violating the shutdown contract. The blocking client has the same race at `src/client/blocking.rs:183-188`; lazy initialization and lane snapshots need a shared lifecycle synchronization point.

### Issue 2
src/client/transport.rs:1080-1089
**Envelope bypasses request limit**

The 8 MiB admission check covers only serialized `properties`, while fields such as `event`, `distinct_id`, and group values are unbounded. An event with small properties but a large envelope can therefore pass this check and be sent alone even when its complete body exceeds the endpoint's 20 MiB request cap. This makes the documented request-size margin unreliable and can cause the background event to be rejected. Please add a total serialized-size guard or otherwise handle this case, with coverage using a large non-properties field.

---

For each issue above, determine whether it is valid and should be fixed. If so, fix it directly.

_{Reviews (1): Last reviewed commit: "feat: add capture_ai() on an isolated AI..." | Re-trigger Greptile}

[marandaneto]

Advisory review: two reproduced behavioral defects. Existing library and AI integration tests pass for both client flavors.