I have a litellm deployment and I use two model openai and openai-dev to split the use of openai key with access group. Then I have dev and prod access group. Each one of then access openai for prod and openai-dev for dev to split the api keys with different expenses. This split made that when people use litellm virtual keys associated to these access group in langchain they facing problems in langfuse tracking costs. Because the model-name associated to openai-dev change and langfuse cannot longer tracking correctly the name. Can you propose scenarios to solve this problem

Grok 4.3

Answer: Configure consistent model aliases in LiteLLM combined with Langfuse's model name normalization to preserve accurate cost tracking across dev and prod access groups.

The core issue arises because LiteLLM maps 'openai' and 'openai-dev' to different keys via access groups, causing the effective model name seen by Langfuse to vary and break cost aggregation. Introduce LiteLLM model aliases that always report the same logical name (e.g., 'gpt-4') regardless of the underlying key, while routing traffic based on virtual keys. In Langfuse, enable model-name mapping rules to normalize any residual variations back to the canonical name used in dashboards. This approach maintains separation of API keys and expenses without sacrificing observability, and can be extended with environment tags passed through LiteLLM's custom metadata for finer-grained filtering if needed.

Gemini 3.5 Flash

Answer: To resolve the Langfuse tracking issue, you should either define custom model prices for 'openai-dev' directly within Langfuse, or transition to using standard model names in LiteLLM while segmenting environments via metadata tags.

This tracking problem occurs because Langfuse relies on the exact model string (e.g., `gpt-4o`) returned in the LLM response to match its internal pricing database. When LiteLLM exposes a virtual model named `openai-dev`, Langfuse fails to find a matching cost profile. Here are three distinct scenarios to resolve this issue, ranging from the easiest config fix to architectural best practices: **Scenario 1: Define 'openai-dev' Pricing in Langfuse (Quickest Fix)** You can resolve this directly within the Langfuse UI without changing your LiteLLM or application code. Go to Langfuse > Settings > Models, and create a new model definition for `openai-dev`. You can define its cost per 1k tokens to match the corresponding OpenAI model (or use a regular expression like `openai-dev` to map to `gpt-4`). This allows Langfuse to calculate costs accurately for the custom model name. **Scenario 2: Standardize Model Names and Segment via Metadata Tags (Best Practice)** Instead of renaming the models to `openai-dev` and `openai` to split costs, use the actual model names (e.g., `gpt-4o`) for both configurations in LiteLLM. To track costs separately, use LiteLLM's virtual key metadata or Langchain's native Langfuse integration to pass tags like `environment: dev` and `environment: prod`. In Langfuse, you can then filter, group, and track costs by these tags while maintaining automatic, out-of-the-box model cost tracking. **Scenario 3: Utilize LiteLLM's Model Aliasing or Langchain Callbacks to Override the Model Name** If you must keep the separate model names in LiteLLM, you can intercept and override the model name during the Langchain-to-Langfuse serialization. In your Langchain application, when initializing the Langfuse callback handler, you can programmatically map the model name back to the standard OpenAI name (e.g., replacing `openai-dev` with `gpt-4o`) before the payload is dispatched to Langfuse.

GPT-5.5

Answer: The best solution is to keep a canonical model name for observability while separating billing/routing through LiteLLM aliases, metadata, tags, or Langfuse price mappings rather than exposing environment-specific names like "openai-dev" as the tracked model.

You have a routing and accounting problem, not really a model problem: "openai" and "openai-dev" are probably the same underlying OpenAI model or provider, but you renamed one of them to split API keys and access groups. That is useful for LiteLLM routing, but it breaks Langfuse because Langfuse cost tracking usually depends on recognizing the model name. Scenario 1: Use the same public model name and separate the API keys internally in LiteLLM. For example, users call the canonical model name such as "gpt-4o-mini" or "openai/gpt-4o-mini", while LiteLLM chooses the real OpenAI API key based on the virtual key, team, access group, or metadata. In this setup, LangChain and Langfuse always see the real model name, so cost tracking works normally, while LiteLLM still separates dev and prod spend internally. Scenario 2: Keep "openai" and "openai-dev" as LiteLLM aliases, but configure both aliases to report or map to the same underlying model for observability. In LiteLLM, you can define aliases such as "openai-dev" pointing to the real model, for example "gpt-4o-mini", but ensure that the actual model sent to Langfuse is the canonical model. The routing name can remain internal, while the observed model name should be the OpenAI model name that Langfuse knows how to price. Scenario 3: Add explicit pricing for "openai-dev" in Langfuse. If you want Langfuse to see "openai-dev" as a distinct model, then configure a custom model price in Langfuse for that exact name. This is a good option if dev and prod should appear as separate cost lines in Langfuse. The downside is that you must maintain pricing manually whenever OpenAI prices or model names change. Scenario 4: Use Langfuse metadata, tags, or trace/session attributes to separate dev and prod, instead of encoding the environment in the model name. For example, send model as "gpt-4o-mini" and attach metadata like environment="dev", environment="prod", access_group="dev", or access_group="prod". Then Langfuse can calculate costs correctly from the canonical model name while still allowing you to filter dashboards by dev/prod. Scenario 5: Use separate LiteLLM virtual keys, budgets, or teams for dev and prod, but expose the same model name to clients. This is probably the cleanest architecture: virtual key A belongs to the prod group and routes to the prod OpenAI key; virtual key B belongs to the dev group and routes to the dev OpenAI key. From LangChain's point of view, both call the same model name. From LiteLLM's point of view, billing and key usage remain separate. Scenario 6: If LangChain is overriding or forwarding the model name, explicitly set the model name used for callbacks/tracing. In some LangChain integrations, the model string passed to the LLM object is also what appears in Langfuse. If the LangChain client is initialized with "openai-dev", Langfuse may record that instead of the real model. You can keep the LiteLLM base URL and virtual key, but initialize LangChain with a canonical model name when possible. Scenario 7: Create a normalization layer before sending traces to Langfuse. If changing LiteLLM or LangChain behavior is hard, add a small mapping step: "openai-dev" -> "openai", or better "openai-dev" -> "gpt-4o-mini". This can be done in your tracing wrapper, callback handler, or middleware. This is practical, but less elegant than fixing the model naming at the source. My recommended design is: keep canonical provider model names for anything that goes to Langfuse, use LiteLLM virtual keys/access groups to choose the correct OpenAI API key, and send dev/prod as metadata or tags. That gives you correct cost tracking, clean dashboards, and separated expenses without making observability depend on artificial model names like "openai-dev".

Claude Opus 4.7

Answer: The cleanest fix is to decouple the LiteLLM routing name from what Langfuse sees by using model aliases or a normalized model field, with several fallback options depending on how much control you have over LiteLLM and Langfuse.

Your root cause is a naming collision: LiteLLM exposes two logical models (openai and openai-dev) so you can attach different API keys per access group, but Langfuse keys its cost lookup off the model name returned in the trace. As soon as a dev key calls openai-dev, Langfuse no longer matches it against its built-in OpenAI pricing table. You have basically three families of solutions. Scenario 1 — Same public model name, different deployments (recommended). In your LiteLLM config.yaml, define two entries that share the same model_name (e.g. gpt-4o-mini) but different litellm_params.api_key and different tags or access_groups. LiteLLM supports multiple deployments under one model name and will route based on access group, tag, or routing strategy. From Langchain's perspective the model is always gpt-4o-mini, so Langfuse maps costs correctly. Cost separation per environment is then done in Langfuse via tags/metadata (environment=dev|prod) or via LiteLLM's own spend tracking per virtual key, which is actually more accurate than Langfuse for billing anyway. Scenario 2 — Keep two model names, normalize at the Langfuse layer. Add custom model definitions in Langfuse (Settings → Models) that match the pattern openai-dev (and openai if needed) and point them to the same pricing as the underlying OpenAI model. Langfuse will then compute costs correctly for both. This is the lowest-effort fix if you don't want to touch LiteLLM, but you must maintain those custom model entries whenever OpenAI pricing changes. Scenario 3 — Rewrite the model name in metadata before it reaches Langfuse. Use a LiteLLM callback or custom logger, or a Langchain callback wrapper, to overwrite the model field sent to Langfuse with the canonical OpenAI model name, while keeping the LiteLLM-internal name for routing. You can also push the original openai-dev value into a metadata.environment tag so you keep the dev/prod distinction for filtering, without breaking cost tracking. In LiteLLM this can be done with litellm.success_callback or by setting metadata with langfuse_tags and model fields from Langchain. My recommendation: go with Scenario 1 as the structural fix (one logical model name, multiple deployments behind access groups), and rely on LiteLLM virtual-key spend reports for the per-environment expense split — that's exactly what LiteLLM was built for. Use Langfuse purely for observability and per-call cost attribution, tagging traces with environment dev or prod so you can still slice spend there. Scenario 2 is a good quick patch while you migrate, and Scenario 3 is useful if organizational constraints force you to keep distinct model names in LiteLLM.

Final Summary

The AI Roundtable identifies the issue as an identity crisis: by naming your models 'openai-dev', you've broken Langfuse's ability to recognize them in its pricing table. GPT-5.5 and Claude Opus 4.7 recommend a structural fix where both environments use the same canonical model name (like gpt-4o), while LiteLLM handles the background routing to different API keys based on virtual key metadata. Gemini 3.5 Flash and Grok 4.3 suggest that if changing the names is impossible, you should manually define 'openai-dev' as a custom model within Langfuse's own settings to restore cost visibility.

All 4 models agreed