Skip to content

feat: Add multi-tenant passthrough mode for per-user OpenAI API keys (#34)#37

Open
freedomkk-qfeng wants to merge 1 commit intofuergaosi233:mainfrom
freedomkk-qfeng:main
Open

feat: Add multi-tenant passthrough mode for per-user OpenAI API keys (#34)#37
freedomkk-qfeng wants to merge 1 commit intofuergaosi233:mainfrom
freedomkk-qfeng:main

Conversation

@freedomkk-qfeng
Copy link

Description

This PR implements multi-tenant support by adding a passthrough mode that allows each request to use its own OpenAI API key, addressing the billing and multi-tenancy concerns raised in issue #34.

Problem Solved

  • Issue: The current implementation uses the same OpenAI API key for all requests, making billing harder in multi-tenancy environments
  • Solution: Added support for per-user API keys while maintaining full backward compatibility

Implementation

Two Operating Modes

🔧 Proxy Mode (Default/Existing Behavior)

  • OPENAI_API_KEY is configured
  • All requests use the server's API key
  • Client validation via ANTHROPIC_API_KEY (optional)
  • Fully backward compatible - existing deployments continue to work unchanged

🔄 Passthrough Mode (New Multi-tenant Support)

  • OPENAI_API_KEY is not configured
  • Users provide their own OpenAI API keys via request headers
  • Client API keys are validated and passed directly to OpenAI
  • Perfect for multi-tenant environments with separate billing

Key Features

  • Zero Breaking Changes - Existing configurations work exactly as before
  • Automatic Mode Detection - Based on OPENAI_API_KEY presence
  • Secure API Key Validation - Validates OpenAI key format
  • Comprehensive Error Handling - Clear error messages and troubleshooting guidance
  • Complete Documentation - Updated README, help text, and configuration examples

aaaronmiller pushed a commit to aaaronmiller/claude-code-proxy that referenced this pull request Nov 19, 2025
…ion, passthrough mode, Docker improvements

This commit implements changes from PRs fuergaosi233#35, fuergaosi233#24, fuergaosi233#39, fuergaosi233#37, and fuergaosi233#32:

## PR fuergaosi233#35 + fuergaosi233#24: OpenAI Newer Models Support (o1, o3, o4, gpt-5)
- Add `is_newer_openai_model()` method to ModelManager to detect o1, o3, o4, gpt-5
- Add `is_o3_model()` method for specific o3 model detection
- Use `max_completion_tokens` instead of `max_tokens` for newer models
- Enforce `temperature=1` for newer OpenAI reasoning models
- Update test-connection endpoint to handle newer models correctly
- Fix compatibility with OpenAI's newer model API requirements

## PR fuergaosi233#39: Enhanced Conversion & Error Handling
- Add comprehensive input validation to request converter
- Validate Claude request structure before processing
- Add enhanced error handling in response converter
- Validate OpenAI response structure with detailed error messages
- Add prompt cache support for non-streaming responses
- Extract and include `cache_read_input_tokens` from prompt_tokens_details
- Improve error messages for debugging

## PR fuergaosi233#37: Multi-Tenant Passthrough Mode
- Add passthrough mode support for multi-tenant deployments
- Make OPENAI_API_KEY optional - enable passthrough mode when not set
- Add per-request API key support via `openai-api-key` header
- Update OpenAIClient to accept per-request API keys
- Add API key format validation (sk- prefix, minimum length)
- Update endpoints to extract and validate OpenAI API keys from headers
- Support both proxy mode (server key) and passthrough mode (user keys)
- Enable separate billing per tenant in passthrough mode

## PR fuergaosi233#32: Docker Improvements
- Add comprehensive .dockerignore file
- Exclude development files, tests, and sensitive data from Docker builds
- Reduce Docker image size by excluding unnecessary files
- Improve build performance with proper ignore patterns

## Additional Improvements
- Better error messages and logging throughout
- Enhanced API key validation
- Improved request/response handling

All changes maintain backward compatibility with existing deployments.
@elifarley
Copy link

@freedomkk-qfeng I've implemented a similar functionality whose rationale you can read.

As Vandamme Proxy offers simultaneous multi-provider access, I had to get a solution that would work at the provider level.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants