You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Prompt management: support fetching multiple prompts in a single call (batch fetch) #4353
The prompt management SDK (@posthog/ai, and posthog-python) currently only supports fetching one prompt at a time via prompts.get(name). Retrieving N prompts means N separate calls. Add a way to fetch multiple prompts in a single request.
Why
Requested by a customer using @posthog/ai who is loading several prompts and would like to fetch them together rather than issuing one request per prompt. They noted this would be an improvement over competing tools (Langfuse doesn't offer batch fetching either), so it's a potential differentiator.
Benefits:
Fewer round trips when an app depends on multiple prompts
Simpler consuming code (no need to Promise.all a set of individual get() calls)
Shared client-side cache across the batch
Proposed shape
Something like a batch method that returns multiple compiled prompts in one call, keeping the existing single get() backwards-compatible:
Exact API/naming open to design — an array/comma-separated name param on a new method would work. Should reuse the existing caching and fallback behaviour.
Context
Raised via a support ticket about the newly released prompt configuration feature.
Conclusion: Valid enhancement request, but true batch fetching requires a supporting PostHog API endpoint before SDK work can deliver the requested single network call. Confidence: 93% Suggested labels:enhancement, team/ai-observability
Thanks — this is a valid prompt-management enhancement. The current SDK fetches exactly one prompt through a name-specific endpoint, so adding a getMany() wrapper that simply calls get() would not meet the requested single-round-trip behavior.
A complete implementation needs a batch API contract on the PostHog side first, including the response shape and behavior for missing prompts or partial failures. Once that exists, the SDK can add a small getMany() surface that consults the existing per-prompt cache, requests uncached/stale prompts in one batch, and preserves the established stale-cache and fallback semantics.
Investigation
Prompts.get(name, options) is the only retrieval method exposed by packages/ai/src/prompts.ts; it obtains one PromptResult at a time.
The only implemented API request is GET /api/environments/@current/llm_prompts/name/:name/, which encodes a single prompt name and validates a single prompt-object response.
Caching is already keyed per prompt name and version, label, or latest selection, so it can be reused by a future batch method but does not itself coalesce network requests.
The existing tests cover single-prompt cache hits, stale-cache recovery, code fallbacks, version/label selection, and response validation; there is no batch endpoint, batch response type, or batch behavior coverage.
Adding getMany() as Promise.all(names.map(name => get(name))) would preserve client behavior but still issue N requests, contrary to the issue's primary requirement.
Reason: The JavaScript SDK change is localized only after a backend batch endpoint exists. The required server request/response contract and partial-failure semantics are not present in this repository, and the request also calls for corresponding Python support. Implementing an SDK-only approximation would not provide a single request.
Fix PR skipped: feature requests require an explicit trusted fix command or mode: fix before opening a draft PR
Activity
github-actions commentedon Jul 31, 2026
AI triage for #4353
Conclusion: Valid enhancement request, but true batch fetching requires a supporting PostHog API endpoint before SDK work can deliver the requested single network call.
Confidence: 93%
Suggested labels:
enhancement,team/ai-observabilityThanks — this is a valid prompt-management enhancement. The current SDK fetches exactly one prompt through a name-specific endpoint, so adding a
getMany()wrapper that simply callsget()would not meet the requested single-round-trip behavior.A complete implementation needs a batch API contract on the PostHog side first, including the response shape and behavior for missing prompts or partial failures. Once that exists, the SDK can add a small
getMany()surface that consults the existing per-prompt cache, requests uncached/stale prompts in one batch, and preserves the established stale-cache and fallback semantics.Investigation
Prompts.get(name, options)is the only retrieval method exposed bypackages/ai/src/prompts.ts; it obtains onePromptResultat a time.GET /api/environments/@current/llm_prompts/name/:name/, which encodes a single prompt name and validates a single prompt-object response.getMany()asPromise.all(names.map(name => get(name)))would preserve client behavior but still issue N requests, contrary to the issue's primary requirement.Relevant files:
packages/ai/src/prompts.ts,packages/ai/src/types.ts,packages/ai/tests/prompts.test.ts,packages/ai/CHANGELOG.mdFix assessment
Fix PR skipped: feature requests require an explicit trusted fix command or mode: fix before opening a draft PR
Pi session
The JSONL pi session file(s) for this run were saved to a private gist: https://gist.github.com/marandaneto/3a85954c6b17e70a11c8909c2f3dc1ac
Download one locally, then fork it into your own pi session:
Saved session files:
call-1-1-2026-07-31T11-25-00-984Z_019fb7eb-a2b8-7aab-b3e3-e194b8979462.jsonlClose proposal
None. No issue close action was taken.
Generated by posthog-watcher-action using pi.