litellm - 💡(How to fix) Fix Feature request: support multiple ChatGPT OAuth accounts in a single LiteLLM instance [1 comments, 2 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
BerriAI/litellm#23777Fetched 2026-04-08 00:49:07
View on GitHub
Comments
1
Participants
2
Timeline
7
Reactions
13
Timeline (top)
subscribed ×5commented ×1unsubscribed ×1

LiteLLM's current ChatGPT OAuth support appears to be effectively single-account per proxy process because the authenticator only reads one global CHATGPT_TOKEN_DIR / CHATGPT_AUTH_FILE pair.

This makes it difficult to run multiple ChatGPT subscription accounts in a single LiteLLM instance, even when users want to expose them as separate model groups / aliases.

Root Cause

LiteLLM's current ChatGPT OAuth support appears to be effectively single-account per proxy process because the authenticator only reads one global CHATGPT_TOKEN_DIR / CHATGPT_AUTH_FILE pair.

RAW_BUFFERClick to expand / collapse

Summary

LiteLLM's current ChatGPT OAuth support appears to be effectively single-account per proxy process because the authenticator only reads one global CHATGPT_TOKEN_DIR / CHATGPT_AUTH_FILE pair.

This makes it difficult to run multiple ChatGPT subscription accounts in a single LiteLLM instance, even when users want to expose them as separate model groups / aliases.

What I tried

I deployed LiteLLM database/admin mode and attempted to configure two ChatGPT-backed model groups in one instance, conceptually like:

  • gpt1/* -> ChatGPT account A
  • gpt2/* -> ChatGPT account B

At the container / config level, I mounted two auth directories, e.g.

  • /app/chatgpt-auth-gpt1
  • /app/chatgpt-auth-gpt2

and defined separate model groups in config.yaml.

However, after inspecting the running container, the ChatGPT auth path still seems globally bound by env vars:

  • CHATGPT_TOKEN_DIR
  • CHATGPT_AUTH_FILE

and the current implementation in litellm/llms/chatgpt/authenticator.py appears to initialize a single auth file path for the whole process.

Why this is a problem

For operators using ChatGPT subscription auth as an upstream, there are practical cases where multiple accounts are needed in one deployment:

  • separate personal/work ChatGPT accounts
  • quota isolation
  • resilience / account-level fallback
  • explicit routing between account A and account B using model aliases

Right now it looks like model alias separation alone is not enough, because both model groups still resolve through the same process-wide ChatGPT auth source.

Questions

  1. Is multi-ChatGPT-account support in a single LiteLLM instance currently supported?
  2. If yes, what is the recommended official configuration pattern?
  3. If not, is there an existing roadmap / planned feature for one of these approaches?
    • per-model or per-group ChatGPT auth binding
    • named ChatGPT provider instances
    • multiple CHATGPT_TOKEN_DIR sources in one process
    • provider-level credential objects stored in DB/admin mode

Suggested feature directions

Any of these would help:

  1. Allow per-model litellm_params to reference a named ChatGPT credential source
  2. Allow multiple named ChatGPT auth profiles in config/admin
  3. Support provider instances like:
    • chatgpt/account_a/gpt-5.4
    • chatgpt/account_b/gpt-5.4
  4. Expose an official "not supported yet" answer in docs, so operators don't spend time trying to force it through aliases alone

Extra note

From an operator point of view, single-instance multi-account support would be much cleaner than running one LiteLLM proxy process per ChatGPT account.

If needed, I can also share a sanitized compose/config example that reproduces the ambiguity around multiple ChatGPT auth directories in one LiteLLM deployment.

extent analysis

Fix Plan

To support multiple ChatGPT accounts in a single LiteLLM instance, we need to modify the authenticator to allow per-model or per-group ChatGPT auth binding. Here are the steps:

  • Modify litellm/llms/chatgpt/authenticator.py to accept a chatgpt_auth_file parameter for each model group.
  • Update config.yaml to include the chatgpt_auth_file parameter for each model group.
  • Create a new ChatGPTAuth class that initializes the auth file path based on the model group.

Example code:

# litellm/llms/chatgpt/authenticator.py
class ChatGPTAuth:
    def __init__(self, chatgpt_auth_file):
        self.chatgpt_auth_file = chatgpt_auth_file
        # Initialize auth file path based on chatgpt_auth_file

# config.yaml
model_groups:
  - name: gpt1
    chatgpt_auth_file: /app/chatgpt-auth-gpt1/auth.json
  - name: gpt2
    chatgpt_auth_file: /app/chatgpt-auth-gpt2/auth.json
  • Update the litellm container to mount multiple auth directories and define separate model groups in config.yaml.

Verification

To verify that the fix worked, you can:

  • Run multiple model groups with different ChatGPT accounts in a single LiteLLM instance.
  • Check that each model group uses the correct ChatGPT account by inspecting the auth file path.

Extra Tips

  • Consider adding support for named ChatGPT provider instances, such as chatgpt/account_a/gpt-5.4, to make it easier to manage multiple accounts.
  • Update the documentation to reflect the new configuration pattern and provide examples for operators.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING