[Request] modify codebase to not require to prefix for toapi routes.

[Jirubizu]

From the reading I have done it should be possible to simply move the router setup for toapi above where you define

.route("/v1/*path", any(official_proxy))

Axum does things in the order things are initialized / written. So if we do something like

.route("/v1/chat/completions", any(unofficial_proxy))
.route("/v1/*path", any(official_proxy))

the custom handler for completions will be prioritized under the normal v1 path. I am only making this suggestion as it appears to me it sometimes breaks third party applications where they require a base URL which is usually the one that first leads up to /v1.

[0x676e67]

In my opinion this is undesirable. The proxy contains the official API: https://platform.openai.com/docs/api-reference, /to/v1/chat/completions. The purpose is to allow users to distinguish between using the official API and ChatGPT to API

[0x676e67]

But it is not impossible to do this. The server distinguishes the user's Authenticate key type for forwarding.

[Jirubizu]

Would it be possible to potentially make it configurable via a command line argument? I personally would love this because it breaks a few applications where they just want a base URL instead of a completions url

[Jirubizu]

and I don't want to pay for the API when I already pay for pro :D

[0x676e67]

The next plan is to develop an account pool management (but relatively speaking, a front-end WebUI is needed for account management. Unfortunately, I am not familiar with html and js). It is to map Access-Token to API-Key, and then use it with the official API. After merging, the path will be consistent with the official one and will be insensitive to users.

[Jirubizu]

The next plan is to develop an account pool management (but relatively speaking, a front-end WebUI is needed for account management. Unfortunately, I am not familiar with html and js). It is to map Access-Token to API-Key, and then use it with the official API. After merging, the path will be consistent with the official one and will be insensitive to users.

Couldn't you do the api for this in the background, and if you dont have the time yourself, you could potentially have someone else make a frontend to call those endpoints exposed by ninja to map access tokens to api keys.

If need be, I can create a very basic UI for managing these but as a disclaimer, I will be super basic but functional

[0x676e67]

My plan is to only need a simple multi-account group management. Each group of accounts can generate several mapped API-Keys, and some pages for adding, deleting, checking and modifying will be enough.

[Jirubizu]

If you can provide me with an API which handles this in rust. I can then create a barebone UI for you. but I cant do anything unless I know what api calls to make

[0x676e67]

It takes a while to design the data model

[Jirubizu]

It takes a while to design the data model

That's fine, keep this issue open to track the progress, once your side of things are done you can let me know and I'll make something barebone

[0x676e67]

OpenAI is facing the risk of employees running away. I am considering whether to continue the plan.

[Jirubizu]

OpenAI is facing the risk of employees running away. I am considering whether to continue the plan.

with the recent changes and them getting the ceo back. do you think you will get back to this project?

[0x676e67]

I'll be back, now toapi has been merged into /v1/chat/completions

[spammenotinoz]

The next plan is to develop an account pool management (but relatively speaking, a front-end WebUI is needed for account management. Unfortunately, I am not familiar with html and js). It is to map Access-Token to API-Key, and then use it with the official API. After merging, the path will be consistent with the official one and will be insensitive to users.

For account Pooling via API, use OneAPI https://github.com/songquanpeng/one-api in-front of Ninja. OneAPI can load-balance across multiple channels. Each Channel can send a unique access token key to Ninja. Can even have multiple instances of Ninja, as you can set Ninja up as a proxy for each Channel.

In my setup I have chat going straight to Ninja backend-api, but API I send to OneAPI first then back to Ninja.
I realise I can go straight to Ninja /toapi/ but this way I can pool accounts. (Not that I need to, I just try various setups to have fun).

[0x676e67]

I don't like putting things related to different AI agents together

[Jirubizu]

I don't know what you want me to do with this issue? I am happy with the change you made so we could close it or do you want to keep it here? @gngpp

[0x676e67]

stay here until done

[OsemDing]

The next plan is to develop an account pool management (but relatively speaking, a front-end WebUI is needed for account management. Unfortunately, I am not familiar with html and js). It is to map Access-Token to API-Key, and then use it with the official API. After merging, the path will be consistent with the official one and will be insensitive to users.

For account Pooling via API, use OneAPI https://github.com/songquanpeng/one-api in-front of Ninja. OneAPI can load-balance across multiple channels. Each Channel can send a unique access token key to Ninja. Can even have multiple instances of Ninja, as you can set Ninja up as a proxy for each Channel.

In my setup I have chat going straight to Ninja backend-api, but API I send to OneAPI first then back to Ninja. I realise I can go straight to Ninja /toapi/ but this way I can pool accounts. (Not that I need to, I just try various setups to have fun).

Can one-api automatically update access token? Or manually?