How do you express a per-user quota in Helicone's Helicone-RateLimit-Policy header?

## One header, four fields Helicone expresses a quota as a structured value on `Helicone-RateLimit-Policy`, borrowing the shape of HTTP's rate-limit header conventions: `[quota];w=[time window in seconds];u=[unit];s=[segment]` The leading number and `w` are mandatory. `u` and `s` are optional and have defaults, which is where most of the confusion comes from — a policy that looks like it is per user often is not, because `s` was never set. ## Units: requests or cents The default unit counts requests. `u=cents` instead counts spend, using Helicone's own cost calculation for the model and token usage of each call. That distinction matters more here than in a conventional API gateway, because LLM requests are not fungible: a thousand short classification calls and a thousand long-context summarization calls differ in cost by orders of magnitude. If what you are protecting is a budget, count cents; if what you are protecting is a downstream capacity or a fairness property, count requests. Note that a cent-denominated quota can only be evaluated once a response exists and its usage is known, so it bounds spend after the fact rather than pre-authorizing it — a single very expensive call can carry you past the line before it is enforced. ## Segments: global, user, or a custom property With no `s`, the policy applies to the whole organization: one bucket for all traffic. `s=user` gives every distinct `Helicone-User-Id` its own bucket, which is the multi-tenant case. You can also segment by a custom property you are already attaching for analytics, which is how you build a quota per workspace, per feature, or per environment without introducing a new identity concept — the property name goes in `s`. The dependency is easy to miss: `s=user` is meaningless unless `Helicone-User-Id` is present on the request. If your service already sends that header for cost attribution, segmented quotas are free to add; if it does not, adding the policy alone silently fails to do what you meant. ## What happens at the limit When a request would exceed its bucket, the Helicone proxy short-circuits it: the provider is never called, and the caller receives a 429. The response includes `Helicone-RateLimit-*` headers reporting the limit, what remains in the window, and the policy in force. Your client should read those rather than inventing a backoff, and — more importantly — your application has to decide what a 429 means in product terms. For an interactive feature that is usually a specific message and possibly an upgrade path, not a stack trace. For a background job it is a signal to defer. ## Where this sits relative to everything else This is a gateway-side quota, which has three implications worth stating in an interview. First, it requires the proxy integration — in async logging mode Helicone learns about the call only after your application has already made and paid for it, so there is nothing to block. Second, it only sees traffic that goes through Helicone; a service that calls the provider directly, a batch job with its own credentials, or a developer's laptop is invisible to the policy, so the quota is a partial view of spend rather than a hard ceiling. Third, it composes awkwardly with retries: a policy that trips will return 429s, and gateway retries treat 429 as retryable, so an unthinking configuration can spend its retry budget hammering its own quota. ## Rollout advice Quotas are the one feature here that can take a product down, because the failure mode is refusing your own customers' traffic. Introduce a policy in a low environment first, watch how many requests would have been rejected, and pick the number from measured p99 usage rather than from a round figure that felt safe. Send the policy from a config value rather than hard-coding it, so raising a limit for one large customer is a deploy-free change. And keep the gateway quota as a coarse backstop against runaway spend, not as the mechanism your billing model depends on — the latter needs to live somewhere you own end to end.