⚠️ No Changeset found

Latest commit: 10c8413

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

I think this may duplicate #2813

I think this may duplicate #2813

OK,can you answer a few questions for me?

I want to know how to correctly create a new LLM client in Kilo code. A while ago, after I updated, I noticed that the option to configure the LLM model for autocomplete disappeared. According to the contributor who deleted the code, Kilo currently does not actually use a mechanism for independent clients. The API directly points to the main API configuration, causing a bug that results in massive token consumption.

Additionally, I want to know why each provider's API key uses a different name instead of adhering to a unified interface. This makes it difficult for us to build an LLM API client based on a non-currently enabled API configuration.

thinks

I think this may duplicate #2813

OK,can you answer a few questions for me?

Probably, but its worth mentioning I'm not officially part of Kilo Code - just an interested constributor.

I want to know how to correctly create a new LLM client in Kilo code.

Here's an excellent sample PR the includes a bunch of best practices (like dynamic model fetching, good tests, etc) from @b3nw #2825

A while ago, after I updated, I noticed that the option to configure the LLM model for autocomplete disappeared. According to the contributor who deleted the code,

In that particular case, the code was such that it simply defaulted to the currently selected profile, which meant that people were using expensive, slow models for autocomplete if they didn't change the config.

Kilo currently does not actually use a mechanism for independent clients. The API directly points to the main API configuration, causing a bug that results in massive token consumption.

Not quite. Kilo does have mechanisms for different clients, but only 1 apiConfiguration can be 'active' at a time, which is used for the primary chat interactions. Secondary, non-chat use cases (like FastApply, Indexing, Autocomplete) should be built to point to a specific profileId rather the the current apiConfiguration.

Additionally, I want to know why each provider's API key uses a different name instead of adhering to a unified interface. This makes it difficult for us to build an LLM API client based on a non-currently enabled API configuration.

Yes, this is an artifact of history and a fast growing/changing codebase. I have a proposal for what I believe to be a better solution (#2670) but it has not yet gained traction or review from the Kilo team.

Or will the translation be done by the kilo official themselves?

We can do it for you, it's mostly AI generated.