Saving the previously selected LLM settings

bolt.diy [bolt.diy] New Features Discussion
1

Would be great if the dropdown boxes were populated with the LLM’s previously chosen options.

Then you could just type and press enter without having to change the LLM settings each time.

I’m willing to work on this one but I wanted to put the idea out there first for discussion.

What do you guys think?

1 Like
2

Taking a note for roadmap, low effort and this makes a lot of sense as once you’ve got your desired model you will probably only want to change models explicitly, i.e. if something you are attempting requires a larger one.

3 Likes
3

Ou yeah, really want that too, wanted to even sneak in but should be separate PR, if no one will do it I may add a PR with that tomorrow
Though I have 3 PRs open as is already…

1 Like
4

Turned out it was there already, in cookies, just due to bugs not picked up

2 Likes
5

Kudos for looking at what’s already there

6

Really stupid question but where do I find the roadmap?

1 Like
7

Not a stupid question, we’ll be working on a public-facing version in the near future.

1 Like
8

Here is PR where it should work, spent whole day today making a new version I host work
Here is PR with fixes

And here is my version I host, it has some differences but LLM settings are preserved there

10

I tried to run this but the list of LLMS don’t seem to be populated anymore?

I see this console error:

image
image843×52 3.41 KB

If I go to the constants file I see

export type ProviderInfo = {
  staticModels: ModelInfo[],
  name: string,
  getDynamicModels?: () => Promise<ModelInfo[]>,
  getApiKeyLink?: string,
  labelForGetApiKey?: string,
  icon?:string,
};

Hmmm, very strange.

11

interesting, typecheck, build, start, dev commands work for me without that error

12

I’m running it with dev.
I thought it might be a caching issue but I have disable cache checked in the network tab. The interesting thing is even the browser dev tools show it’s there at least in the source mapped version. Hmm I wonder if the JS version is missing it but the sourcemap somehow resolves?

image
image997×520 47 KB

I also did pull the repo again from scratch today.

13

@wonderwhy.er I dropped a short diff on comments for your PR based on seeing this as well, I also use disable cache so it’s likely related to that.

14

Hit me up with any thoughts there, the diff does allow the branch to work great

15

I see this when I try to apply that patch. It looks like it might be incomplete?

I used the copy button to ensure that I’d not missed anything:

❯ git apply ./mahoney.patch
error: patch failed: app/utils/constants.ts:234
error: app/utils/constants.ts: patch does not apply

We are talking about this comment right?

16

I pushed type fix, but its not for that export problem, I sadly do not get that export problem.

What node.js version, operating system, environment you have?

I am wondering how to reproduce
May be record a video of what you are doing and where you are getting the problem. Would really help if I can get error locally.

17

Ah okay that makes sense, I understand.

What version of node are you using? I’m not at my machine right now but I can let you know. I was doing a pnpm run dev. I’m happy to make a video a bit later or we can jump on a call and look at it together also.

18

Wait, I just reproduced it.

1 Like
19

Oooo, I love it when that happens. What did you change? Your node version?

20

Perhaps when I wrote pnpm that might have been the thing you tried?

Here are my node, npm and pnpm versions:

bolt.new-any-llm on  addGetKeyLinks [?] via  v20.16.0 
❯ node -v
v20.16.0

bolt.new-any-llm on  addGetKeyLinks [?] via  v20.16.0 
❯ npm -v       
10.8.1

bolt.new-any-llm on  addGetKeyLinks [?] via  v20.16.0 
❯ pnpm -v     
9.12.2
21

No, it just that I use use built + start not dev command.

And in dev it did fail.

Just pushed in the fix

Seems like we can’t export types from all of the files in current setup.
Needed to move type declaration to separate file in types folder.

1 Like