Concepts

Prompt Hub is the dashboard workspace for authoring, versioning, and testing prompts. This page defines its objects and how they fit together; see Prompts and Playground for the workflows.

Prompt Hub is a development surface, not a runtime. Your application keeps deploying prompts the way it already does — see What Prompt Hub does not do.

A prompt is a named container; its content lives in versions. Nothing about a version is edited in place, so every revision stays reproducible.

Prompt                    name + type, unique within an application
├── Version 1             content, config, labels, tags, commit message
├── Version 2             ...
└── Version 3   [latest]  labels point at whichever version is current

The prompt object

Text and chat prompts

As a movie critic, summarize
{{title}} in one paragraph.

[
  { "role": "system",
    "content": "You answer questions about Kubernetes." },
  { "role": "user",
    "content": "Explain {{topic}} for a {{audience}} audience." }
]

The type is set at creation and cannot change afterwards — a text prompt and a chat prompt are different shapes, not different settings. To switch, create a new prompt.

Variables

Both types support {{variable}} placeholders, substituted at run time by your application or by the playground. Variables are the seam between the stable instruction and the per-request data: keep the wording in the prompt and the values in variables, so a version means the same thing every time it runs.

The version object

Version numbers are assigned under a row lock, so two people saving at once get consecutive numbers rather than colliding on one.

Content is never rewritten. Editing a prompt means creating a new version, which is what makes "the model regressed after Tuesday" a question you can answer.

Labels

Labels are pointers to a version, not properties of it. They let you promote a tested revision without renaming or copying anything.

latest is managed for you: every new version receives it, and it is removed from the previous holder in the same transaction. Exactly one version always carries it.

How a version is resolved

Tools and schemas

Tools and schemas are stored per application and reused across prompts in the playground.

A tool has a name, a description, and a JSON Schema for its parameters — the same shape providers expect in a function definition. The playground can call tools by ID, by name, or from an inline definition, and tool_choice controls whether the model may call one (auto), must not (none), must call some tool (required), or must call a named one.

A schema has a name, a description, and a JSON Schema describing the required response shape. Attaching one makes the model return structured output, so a malformed response is visible in development rather than in production.

Link a trace to the prompt that produced it

Prompt Hub does not attach prompt versions to traces automatically, but KubeSense reads the link from your spans when the application supplies it. Set these attributes on the generation and the trace list, filters, and detail view will show which prompt version produced each response:

Applications using Langfuse's own prompt management set these automatically. Everywhere else, set them yourself with the name and version you deployed:

from langfuse import get_client

langfuse = get_client()

with langfuse.start_as_current_observation(as_type="generation", name="answer") as generation:
	generation.update(metadata={"prompt_name": prompt_name, "prompt_version": prompt_version})
	...

For OpenLIT or raw OpenTelemetry, set the attributes directly on the span:

span.set_attribute("gen_ai.prompt.name", prompt_name)
span.set_attribute("langfuse.observation.prompt.version", prompt_version)

Whichever route you take, the value must be the version your application actually ran, not the newest version in Prompt Hub. Reading it from the same configuration that selects the prompt keeps the two from drifting.

What Prompt Hub does not do

Prompt Hub is a dashboard workspace, not a runtime. Compared with an SDK-integrated prompt registry it has no:

• Runtime client or caching — nothing fetches a prompt at request time, so there is no cache TTL or availability fallback to configure
• Prompt composition — a prompt cannot reference another prompt
• Message placeholders — a chat prompt cannot splice in a message array such as conversation history; use variables for text substitution
• Automatic trace linking — the prompt attributes above are yours to set

Version, label, and test prompts here; deploy and fetch them the way your application already does.

Where to next