goose icon indicating copy to clipboard operation
goose copied to clipboard

[research] using cli providers as LLM

Open michaelneale opened this issue 2 months ago • 1 comments

We need to decide if we keep:

  • claude cli
  • cursor agent
  • gemini cli and or add codex cli.

The CLI experience is not realy great (both from support/making it work, as it uses command line calls) but also as you don't get native MCP experience or many other things. I know @codefromthecrypt has some ideas on how we may to MCP (eg claude code calling back to goose as MCP server itself) which may yield some future results, but wanted to open this to collect these ideas.

Options:

1 Remove CLI providers

2 Find ways to do oauth with codex, gemini and claude (some do that with the latter, although they do sketchy against TOS things like steal the client id, and impersonate, but if it can be made legit then it means people can re0=use their subscriptions - IDEAL, but with real API access).

3 Make a single generic CLI provider people can put in anything (no guarantees)

4 Leave the ones we have

5 Advanced: look at adapting all CLIs to be treated as an LLM, with aggressive prompting to have them return well formed results which can then be shimmed to native MCP tool calls on the goose side (ie make them appear as a virtual LLM)

6 Have a local lite-LLM, and then use the CLIs to run command delegated from it (MCP tool sytle)

Myself, leaning to 1 or 6. 5 would be nice, but not sure it would work. 3 would be not that user friendly.

michaelneale avatar Nov 06 '25 01:11 michaelneale

Recent scars might be talking, but I feel 1. (remove the CLI providers) is the best. Instead, focus on a better sign-on and stay signed on experience for providers. I think a lot of folks would benefit if a. they don't think about copy/pasting api keys b. they aren't haunted by keychain requests.

I suspect some are using the CLI providers just to avoid these things.

The main issues in solving otherwise are pretty well captured above, the most prominent challenges front of mind to me are

  • there's no guarantee work done in any CLI for custom integration will persist (could drift or even be yanked later)
  • only providers that have a raw tunnel mode (e.g. OpenAI Chat Completions over stdio) would work out well, and I don't think they do that now.
  • choosing to defer to CLI defined tools means mid-response auth (approve/deny from their callbacks.. claude has something like this)
  • choosing to push our tools down and disable the CLI's tools might not work with their prompt defaults

hope the brain dump helps!

codefromthecrypt avatar Nov 06 '25 07:11 codefromthecrypt