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
Port autogpt.core.resource.model_provider
from AutoGPT to Forge
#7001
Labels
architecture
Topics related to package and system architecture
Forge
Roadmapped
Issues that were spawned by roadmap items
Comments
Pwuts
added
architecture
Topics related to package and system architecture
Forge
Roadmapped
Issues that were spawned by roadmap items
labels
Mar 11, 2024
This was referenced Mar 11, 2024
1 task
This issue has automatically been marked as stale because it has not had any activity in the last 50 days. You can unstale it by commenting or removing the label. Otherwise, this issue will be closed in 10 days. |
This issue was closed automatically because it has been stale for 10 days with no activity. |
Unstale @kcze |
This was
linked to
pull requests
May 12, 2024
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Labels
architecture
Topics related to package and system architecture
Forge
Roadmapped
Issues that were spawned by roadmap items
Actionable for 🚀 AutoGPT Roadmap - Empowering Agent Builders 👷 #6970
Proposed new module name:
forge.llm
Dependencies
autogpt.core.configuration
intoforge.config
andforge.state
#7000autogpt.core.utils.json_schema
from AutoGPT to Forge #7002TODO
autogpt.core.resource.model_provider
Notes
Configuration may need revision
We want Forge components to be portable and usable as stand-alone imports. Modules should be able to configure themselves if no configuration is passed in.
Example:
OpenAI
's constructor has anapi_key
parameter. If not set, it will try to read the API key from theOPENAI_API_KEY
environment variable.Our
OpenAIProvider
wraps anOpenAI
orAzureOpenAI
client, depending on the configuration. We think it makes sense to preserve this behavior.Why migrate this module?
The
model_provider
module provides functionality and extendability that is not available from any many-model client that we know of, e.g. LiteLLM. We would like to have support for as many models as possible, but:Because of these reasons, we want to keep our own client implementation for now.
The text was updated successfully, but these errors were encountered: