[Feature Request] 设想了一些建议，包括模型使用控制，多密码权限等等

[R917C]

🥰 需求描述

模型使用控制（结合）

目前，模型控制仅有1个：DISABLE_GPT4变量。这个变量是用来禁止使用 GPT-4 的。

我的设想

移除DISABLE_GPT4变量，添加DISABLE_MODELS变量，此变量的格式：

gpt-4@openai,gemini-1.5-pro@google,gpt-4o@openai,xxx@azure,xxx@baidu

结合"用户"权限控制

此处的用户是指Access code，比如：

定义了两个Access code：

CODE=pass1,pass2

结合DISABLE_MODELS变量，此变量结合了权限控制之后的格式：

pass1:gpt-4@openai,gpt-4o@openai|pass2:gemini-1.5-pro@google,xxx@azure,xxx@baidu

如上所示，密码1不允许使用 GPT-4 和 GPT-4o，密码2不允许使用 Gemini Pro 1.5 和 Azure、百度的xxx模型。两个密码的设置中间使用|分割。

🧐 解决方案

见上。

📝 补充信息

这是一个我的设想，并且是大工程。开发人员们可以参考一下，感谢你们的付出！

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically.

---

Title: [Feature Request] envisions some suggestions, including model usage controls, multi-password permissions, etc.

🥰 Description of requirements

Model usage control (combination)

Currently, there is only one model control: the DISABLE_GPT4 variable. This variable is used to disable the use of GPT-4.

My idea

Remove the DISABLE_GPT4 variable and add the DISABLE_MODELS variable. The format of this variable is:

gpt-4@openai,gemini-1.5-pro@google,gpt-4o@openai,xxx@azure,xxx@baidu

Combined with "user" permission control

The user here refers to Access code, such as:

Two Access codes are defined:

CODE=pass1,pass2

Combined with the DISABLE_MODELS variable, this variable combines the format after permission control:

pass1:gpt-4@openai,gpt-4o@openai|pass2:gemini-1.5-pro@google,xxx@azure,xxx@baidu

As shown above, password 1 does not allow the use of GPT-4 and GPT-4o, and password 2 does not allow the use of Gemini Pro 1.5 and the xxx models of Azure and Baidu. Use | to separate the two password settings.

🧐 Solution

See above.

📝 Supplementary information

This is my idea and a big project. Developers can refer to it, thank you for your efforts!

[m0rg5]

Looking for the same myself - simply want to disable numerous models in the list that i'll never use.

[ElricLiu]

Thank you very much for your advice

[R917C]

Looking for the same myself - simply want to disable numerous models in the list that i'll never use.

You can use this Variable: https://github.com/ChatGPTNextWeb/ChatGPT-Next-Web?tab=readme-ov-file#custom_models-optional

[R917C]

另：现在Issue区共有300多个Issue。所以感觉如果要加这个功能（或者其他类似的）要过好长时间。项目大了，Issue都看不过来（笑

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically.

---

Another note: There are now more than 300 issues in the Issue area. So it feels like it will take a long time to add this feature (or other similar features). The project is so big that even the Issue can’t even look at it (laughs)

[m0rg5]

Looking for the same myself - simply want to disable numerous models in the list that i'll never use.

You can use this Variable: https://github.com/ChatGPTNextWeb/ChatGPT-Next-Web?tab=readme-ov-file#custom_models-optional

Where exactly do I create the .env.local file for the macos client?

[ssli1]

Looking for the same myself - simply want to disable numerous models in the list that i'll never use.

You can use this Variable: https://github.com/ChatGPTNextWeb/ChatGPT-Next-Web?tab=readme-ov-file#custom_models-optional

Where exactly do I create the .env.local file for the macos client?

You just need use -all to disable models you never use.

[Tasselmi]

有没有类似分密码控制权限的功能呢，每个密码对应的其实类似于对应一个账户，那么每个密码应该需要隔离控制的。

1. 有效期，也就是TTL过期
2. 可以调用的次数控制，每小时、每天、有效期内一共
3. 模型控制，可以使用的模型的白名单，黑名单

泣血跪求上述功能。其实这个项目已经这么庞大了，后续是不是还是得按照功能解耦拆一拆。

[Issues-translate-bot]

Bot detected the issue body's language is not English, translate it automatically.

---

Is there a function similar to password-controlled permissions? Each password corresponds to an account, so each password should be controlled in isolation.

1. Validity period, that is, TTL expiration
2. Control the number of times that can be called, every hour, every day, and within the validity period.
3. Model control, whitelist and blacklist of models that can be used

I prayed for the above function with tears and blood. In fact, this project is already so huge. Will it still have to be dismantled according to functional decoupling in the future?