Skip to content

Feature request: prompt fetches rate limited like feature flag local evaluation #106802

Closed

Description

@rubychilds

Is your feature request related to a problem?

Customer hitting an API rate limit for a prompt. Currently polling prompts on a 5min fixed interval. Have multiple backends polling.

Describe the solution you'd like

Prompt fetches could behave more like feature flag evaluation:

  1. One endpoint that returns all the prompts a client needs in one request (see Feature request: prompt management - fetch all prompts at a label in one request #95460 for the label-aware collection fetch).
  2. A rate limit for prompt reads that is separate from the general API limit and sized for many polling clients, like the flag definitions endpoint.
  3. Cacheable responses. Prompts do not have to be real time. Data that is a few minutes old is acceptable, so a CDN or HTTP cache layer (for example Cache-Control with a short max-age, or ETags so that an unchanged poll is cheap) is a good fit.

Describe alternatives you've considered

  • A customer-hosted shared cache or proxy. It works, but it adds infrastructure and a failure point.
  • Longer SDK cache TTLs. They lower the rate per process, but the total still scales with the process count.

Additional context

Top priority from customer feedback. Related: #95460 (fetch all prompts at a label in one request), PostHog/posthog-js#4353 (SDK batch fetch).

Activity

  1. jurajmajerik commented on Oct 15, 2026

    @jurajmajerik
    Contributor

    Closing. Here is where each ask landed:

    1. One request for all prompts. Shipped in Feature request: prompt management - fetch all prompts at a label in one request #95460. get_all() in posthog-python (7.55.0+) and getAll() in @posthog/ai (8.13.0+) fetch every prompt at a label in one call.
    2. Dedicated rate limit. Shipped in feat(llm-analytics): dedicated rate limit for prompt fetch endpoints #108384. Prompt reads (list, get by name, resolve by name) have their own 600/minute budget per personal API key, the same as feature flag local evaluation, separate from the general API limits. Docs: docs(api): list the prompt fetch rate limit posthog.com#21247.
    3. Cacheable responses. Not planned. The rate limit is applied before the view runs, so a 304 Not Modified would still count against it. A CDN cannot cache responses that are authenticated with a personal API key. The SDKs cache prompts for 5 minutes and, since fix(ai): coalesce concurrent prompt fetches and time out stalled requests posthog-js#5266 and fix(prompts): share one request between concurrent fetches of the same prompt posthog-python#1059, share one request between concurrent callers in a process, so the request rate scales with process count and poll interval only.

    With a 5 minute poll, the limit covers about 3,000 processes polling one prompt each, or 3,000 get_all() calls per label. If a fleet needs more than that, reopen this with the numbers.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions