Standardized model init arg names

[baskaryan]

Privileged issue

• I am a LangChain maintainer, or was asked directly by a LangChain maintainer to create an issue here.

Issue Content

There's some discrepancies in the init args different models use to set the same params. It'd be a much nicer UX if common params could be set with a common set of init args

Suggesting that if a param in this list is present in a model integration, the below name should either be the actual attribute name or an init arg that can be used to set the attribute:

model: str  # model name
api_key: str  # api key
temperature: float  # temperature sampling
timeout: ...  # request timeout
max_tokens: int  # max tokens
stop: ...  # stop sequences
max_retries: int  # max num retries
base_url: str # base URL to send requests to

Importantly we should also use the above init args in the docs

[liugddx]

Do we need to refactor every llm?

[baskaryan]

Do we need to refactor every llm?

Ideally yes but we can do so incrementally, doesn't need to be all at once

[liugddx]

Do we need to refactor every llm?

Ideally yes but we can do so incrementally, doesn't need to be all at once

I see.

[sepiatone]

@baskaryan @liugddx

Do you think it's worth to set the above names as the actual attribute name (and have an alias for the current one)? eg., for OpenAI we have

param openai_api_key: Optional[SecretStr] = None (alias 'api_key')

which could be changed to

param api_key: Optional[SecretStr] = None (alias 'openai_api_key')

This will bring a common look and feel to the API references since sphinx(I think) arranges them in alphabetical order.

[sepiatone]

Also perhaps base_url (see #20170) -

Cohere

param base_url: Optional[str] = None

Anthropic

param anthropic_api_url: str = 'https://api.anthropic.com'

OpenAI

param openai_api_base: Optional[str] = None (alias 'base_url')

[liugddx]

@baskaryan @liugddx

Do you think it's worth to set the above names as the actual attribute name (and have an alias for the current one)? eg., for OpenAI we have

param openai_api_key: Optional[SecretStr] = None (alias 'api_key')

which could be changed to

param api_key: Optional[SecretStr] = None (alias 'openai_api_key')

This will bring a common look and feel to the API references since sphinx(I think) arranges them in alphabetical order.

We need to be compatible, we try not to modify the original code.

[baskaryan]

@baskaryan @liugddx

Do you think it's worth to set the above names as the actual attribute name (and have an alias for the current one)? eg., for OpenAI we have

param openai_api_key: Optional[SecretStr] = None (alias 'api_key')

which could be changed to

param api_key: Optional[SecretStr] = None (alias 'openai_api_key')

This will bring a common look and feel to the API references since sphinx(I think) arranges them in alphabetical order.

issue with this is it's a breaking change (unless we add some extra explicit properties) since the field name is the actual attribute by which the param is accessible. so if you switched eg openai then ChatOpenAI.openai_api_key would stop working

[sepiatone]

issue with this is it's a breaking change (unless we add some extra explicit properties) since the field name is the actual attribute by which the param is accessible. so if you switched eg openai then ChatOpenAI.openai_api_key would stop working

yes, you're right, should've put in some more thought

[dosubot]

Hi, @baskaryan. I'm Dosu, and I'm helping the LangChain team manage their backlog. I'm marking this issue as stale.

Issue Summary:

• The issue suggests standardizing initialization argument names across models for consistency.
• You and @liugddx discussed the feasibility of incremental refactoring.
• @sepiatone proposed using common attribute names with aliases for backward compatibility.
• Concerns about breaking changes and future implementation plans were raised.
• Discussion included aligning parameter names like stop_sequences with stop.

Next Steps:

• Please confirm if this issue is still relevant to the latest version of LangChain. If so, you can keep the discussion open by commenting here.
• If there is no further input, the issue will be automatically closed in 7 days.

Thank you for your understanding and contribution!