Managing LLM Configs

Put an LLM call under remote, targetable config control — model id, parameters, and prompt served as versioned runtime config — with observability and safe fallbacks. Opinionated integration recipe, not a framework.

The thesis (lead with this)

This is not on/off feature flagging. On/off is the degenerate case. The capability is serving a bundle — model id, model parameters, and prompt — as targetable, versioned runtime config that can vary by user segment, rollout %, or experiment.

The architectural move: the model/prompt/params leave the deploy artifact and become runtime config. A reader who thinks "feature flag = boolean" will badly under-use this. Adopting it as your primary prompt-handling path is a deliberate commitment — see trade-offs.

Retrieval-first

SDK names and APIs move fast. Before writing wiring code, fetch current docs (the ctx7 CLI / find-docs skill) for: LD Cloudflare edge SDK, @launchdarkly/server-sdk-ai, @openfeature/server-sdk, Vercel ai + workers-ai-provider, PostHog. Do not trust memorized signatures. Versions verified at authoring time are noted inline as a starting point, not gospel.

Two LaunchDarkly products, wired together (don't conflate them)

LD exposes these as separate UI areas, reached by different SDKs: