Feature: support OpenAI API service tiers

[bridg109msu]

Describe the feature or potential improvement

For newer models in the OpenAI API (incl. GPT-5 and , you can give requests a "service tier", either "priority" (in which case they're processed more quickly but cost more) or "flex" (slower but cheaper). See here https://platform.openai.com/docs/api-reference/responses/create#responses_create-service_tier for what that looks like in the API, and here https://openai.com/api-priority-processing/ + here https://platform.openai.com/docs/guides/flex-processing?api-mode=responses for pricing in the different tiers.

Note that this works differently from the Claude API service tiers (like in this issue #8499). The priority tier doesn't trigger automatically, you have to set it in your API project settings or in each request.

As far as I can tell (though maybe I'm missing something), the current cost-tracking system in Langfuse doesn't have a built-in way to handle this. My team has started using the priority tier for API calls in one of our projects, and we should be able to find a workaround to make sure costs get tracked correctly (e.g. adding a custom model definition, "gpt-5-priority" or something like that, with the right prices filled in), but it would be nice if this could get handled automatically somehow.

Additional information

No response

[hassiebp]

Thank you for this idea! Are you consistently using a higher priority tier? In that case you can create a custom model definition for those OpenAI models and set the higher prices there manually.

[bridg109msu]

Thanks for the reply! Right now it's priority tier only, but soon we might switch to allowing the user to choose priority vs. regular tier when they invoke the LLM. So, we've been using the workaround I mentioned in my original post, where we have separate model definitions for regular and priority requests, and whenever we do a priority-tier call and create a generation in Langfuse to log it, we make sure that the generation uses the "-priority" model name. This seems to be working fine, and I'm sure anyone in a similar situation could use a similar workaround, so there's probably no especially urgent need to change Langfuse to handle it, but I figured I'd put it on your radar anyway.