Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

OPENAI_ENDPOINT support #46

Merged
merged 9 commits into from
Apr 9, 2024
Merged

OPENAI_ENDPOINT support #46

merged 9 commits into from
Apr 9, 2024

Conversation

Slahser
Copy link
Contributor

@Slahser Slahser commented Apr 7, 2024

No description provided.

@Slahser
Copy link
Contributor Author

Slahser commented Apr 7, 2024

#16

@danenania
Copy link
Contributor

Thank you, this looks good! I'll test and merge tomorrow most likely.

@AxDSan
Copy link

AxDSan commented Apr 8, 2024

Question, what if I add an OpenAI compatible endpoint like from a model provider like OpenRouter @ https://openrouter.ai/api/v1 and I want to modify or select an alternative/different model to carry out the ops? just adding the endpoint will not be suffice right? will this need to turn into an issue itself?

@danenania
Copy link
Contributor

Question, what if I add an OpenAI compatible endpoint like from a model provider like OpenRouter @ https://openrouter.ai/api/v1 and I want to modify or select an alternative/different model to carry out the ops? just adding the endpoint will not be suffice right? will this need to turn into an issue itself?

@AxDSan Yes for this purpose I want to allow for adding dynamically configured models to supplement the default OpenAI models. These would then integrate with the plandex models and plandex set-model commands. Apart from the endpoint, I think they would also need to specify an associated environment variable to read the api key from.

But until that's done, I think the OPENAI_ENDPOINT in this PR is a good and simple stopgap measure.

@AxDSan
Copy link

AxDSan commented Apr 8, 2024

Yup totally understandable, I'd also assume the OPENAI_API_KEY environment variable can be interchangeable with the OpenRouter key, but for sake of SOC it would be good to just do what you say instead, which is introducing a way of reading the env var to read the api key from. OPENROUTER_API_KEY or something.

@danenania danenania mentioned this pull request Apr 9, 2024
@danenania danenania merged commit 6f4f6f2 into plandex-ai:main Apr 9, 2024
@ErikBjare
Copy link

I saw in #65 that the OPENAI_API_BASE was rejected in favor of this OPENAI_ENDPOINT.

However, OPENAI_API_BASE is the convention used by OpenAI's Python library etc. Ideally it should be the same here, to keep things consistent.

@danenania
Copy link
Contributor

Thanks @ErikBjare, I didn't realize that. I'll add support for OPENAI_API_BASE in the next release for standardization, and make that the default in the readme/docs, but still keep support for OPENAI_ENDPOINT as well to avoid a breaking change for anyone who starts using it in the meantime.

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.

5 participants