Propagate selected prompt version and tag to model provider request in Run experiments

[okaditya84]

Describe the feature or potential improvement

Feature Request: Include Prompt Version & Tag Metadata in Custom Provider Requests

Description of the Feature / Potential Improvement

When running an experiment from Datasets using the Run experiment modal, the UI allows a user to:

• Select a Prompt
• Select a specific Prompt version
• Optionally select a Tag (if using prompt management)

If the user selects a custom Model provider (e.g., a wrapper API configured in Settings as an LLM connection), the request sent to the provider includes:

• The resolved prompt content
• Some prompt metadata

However, it does not include:

• The selected prompt version
• The selected prompt tag

Problem

This creates several issues:

• The wrapper API cannot reliably determine which prompt version was executed when:
  • Prompt content is identical across versions
  • The wrapper stores its own run logs
• It becomes difficult to correlate provider-side logs with Langfuse experiments when multiple prompt versions are tested.
• Reliable auditing, routing, and version-based logic inside wrapper APIs becomes fragile.

Requested Change

Enhance the provider request payload for experiment runs to include:

1. The selected prompt version
2. The selected prompt tag (when applicable)
3. Stable identifiers in addition to display fields

This ensures providers can store and reference metadata reliably.

---

Proposed Request Fields (Example)

{
  "langfusePromptName": "string",
  "langfusePromptVersion": 3,
  "langfusePromptVersionId": "string",
  "langfusePromptTag": "string or null",
  "langfuseExperimentId": "string",
  "langfuseDatasetId": "string",
  "langfuseDatasetRunId": "string"
}

### Additional information

## Additional Information

### Relevant Code References

The concept of **prompt version** is already treated as a first-class entity in the codebase. Some examples:

- **Experiments utilities**
  - `promptName` and `promptVersion` are used together (e.g., for default experiment name and description generation).
  - This indicates that version is already logically coupled to experiment identity.

- **Prompt version handling**
  - `web/src/features/prompts/server/handlers/promptVersionHandler.ts`
  - `web/src/pages/api/public/v2/prompts/[promptName]/versions/[promptVersion].ts`

These references demonstrate that:

- Prompt versions are explicitly modeled and handled at the API and server layers.
- Version selection is already part of the internal architecture.
- Extending the provider request payload to include version and tag metadata would align with existing system design rather than introducing a new concept.

This proposed enhancement would therefore surface already-available version metadata to custom model providers, enabling stronger auditability and traceability without architectural disruption.

[jannikmaierhoefer]

Thanks for adding this @okaditya84 !

[okaditya84]

Welcome.
@jannikmaierhoefer Am I allowed to build this and contribute?