Extend ACP to allow other features like /slashcommnads

[notpeter]

Discussed in #76

^{Originally posted by acoliver September 9, 2025}
I work on LLxprt Code a multi-provider fork of Gemini CLI. https://github.com/acoliver/llxprt-code/
Presently to use more than one model in zed you have to do this:

"llxprt-cerebras": {
  "command": "node",
  "args": [
    "/opt/homebrew/bin/llxprt",
    "--experimental-acp",
    "--profile-load",
    "cerebrasqwen3",
    "--yolo"
  ],
  "env": { "DEBUG": "llxprt:*" }
},
"llxprt-sonnet": {
  "command": "node",
  "args": [
    "/opt/homebrew/bin/llxprt",
    "--experimental-acp",
    "--profile-load",
    "claudecode",
    "--yolo"
  ],
  "env": { "DEBUG": "llxprt:*" }
}

This creates two new options for conversations in Zed. One for using Qwen/Cerebras and the other for Sonnet/Anthropic. And since then you need one for zai GLM 4.5, etc etc etc. What would be nice is if we could just use the same /profile load claudecode or /profile load cerebrasqwen3 inside of the Zed panel with ACP extensions. This would benefit gemini-cli and claude code as well. Claude lets you do /model among other things and Gemini has its /corgi mode which they felt was important.

This is what Qwen suggested:

Assistant

...

I notice from my analysis that:

1. The current ACP (Agent Communication Protocol) integration in Zed mode has limited capabilities compared to the TUI (Text User Interface) mode
2. The protocol version is 1, which may not support all the features available in the full llxprt implementation
3. In the initialize method of GeminiAgent, the agent capabilities are set to:

   agentCapabilities: {
     loadSession: false,
     promptCapabilities: {
       image: true,
       audio: true,
       embeddedContext: true,
     },
   }

   This doesn't include features like model switching capabilities that are available in the TUI mode.

Looking at the protocol schema, there don't seem to be specific methods for model switching or accessing other llxprt features. The current implementation primarily handles authentication, session management, and prompting.

To access more llxprt features in ACP mode, we could:

1. Instrument slash commands: Add support for slash commands like /model in the Zed integration. This would require implementing command parsing and execution within the ACP handler.

2. Extend protocol capabilities: Add new methods to the ACP protocol schema to support model switching and other llxprt features.

3. Use embedded context references: As you noted, references with @ work because Zed has a local implementation for them. We could leverage this pattern for other features.

Let me check how slash commands are implemented in the TUI mode to understand what would be needed to add them to ACP mode:

Tool Call: 'packages/cli/src/ui/commands/*.ts'
Status: Completed

Found 64 matching file(s)

Tool Call: ...ckages/src/ui/commands/modelCommand.ts
Status: Completed

Tool Call: ...ackages/cli/src/zed-integration/acp.ts
Status: Completed

**Tool Call: 'command|slash command' in /*.ts
Status: Completed

Found 4539 matches
[Showing first 50 of 4539 matches as requested]

Tool Call: 'ClientCapabilities' in packages/cli/src/zed-integration/*.ts
Status: Completed

Found 7 matches

Tool Call: ...packages/cli/src/ui/commands/types.ts
Status: Completed

Assistant

Based on the code I've reviewed, I can see that the ACP (Agent Communication Protocol) integration in LLxprt Code has limited capabilities compared to the full TUI (Text User Interface) mode. Let me summarize what I found and provide recommendations for improving model switching and other features in ACP mode:

Current Limitations in ACP Mode

1. Agent Capabilities Declaration:
   In the zedIntegration.ts file, the agent capabilities are declared as:

   agentCapabilities: {
     loadSession: false,
     promptCapabilities: {
       image: true,
       audio: true,
       embeddedContext: true,
     },
   }

   This shows that model switching capabilities aren't exposed explicitly through the protocol.

2. Client Capabilities:
   The client capabilities only cover file system operations:

   clientCapabilities: {
     fs: {
       readTextFile: true,
       writeTextFile: true
     }
   }

   There's no explicit capability for model switching or provider management.

Proposed Solutions

To improve access to llxprt features through the protocol, here are a few suggestions:

1. Enhanced Client Capabilities Schema:
   We could extend the client capabilities schema to include provider/model management abilities. In schema.ts, we might add:

   export const clientCapabilitiesSchema = z.object({
     fs: fileSystemCapabilitySchema,
     providerManagement: z.object({
       switchProvider: z.boolean().optional(),
       switchModel: z.boolean().optional(),
     }).optional(),
   });

2. Add New ACP Methods:
   Define new ACP methods for model/provider switching in schema.ts:

   export const AGENT_METHODS = {
     authenticate: 'authenticate',
     initialize: 'initialize',
     session_cancel: 'session/cancel',
     session_load: 'session/load',
     session_new: 'session/new',
     session_prompt: 'session/prompt',
     provider_switch: 'provider/switch', // New method
     model_switch: 'model/switch',       // New method
   };

3. Instrument Slash Commands Through ACP:
   We could modify the Session class in zedIntegration.ts to handle slash commands:

   // Add a method to handle slash commands
   private async handleCommand(command: string, args: string): Promise<Part[]> {
     // Parse command and route to appropriate handler
     // This would require implementing command parsing similar to the TUI
     // Could return a message to be displayed in the client
   }

4. Client Integration for Commands:
   The client would need to be modified to send command requests to the agent:

   // In the client implementation
   async switchModel(modelName: string): Promise<void> {
     await this.#connection.sendRequest('model/switch', { modelName });
   }

Why References with @ Work in Zed

References with @ work in Zed because:

1. The integration already handles file system operations through ACP
2. Zed has built-in file referencing capabilities that are exposed through the protocol
3. The #resolvePrompt method in the Session class processes these references

However, slash commands like /model are not currently handled because:

1. There's no ACP method defined for command execution
2. The client doesn't send command requests to the agent
3. The agent doesn't process slash commands in the ACP mode

Implementation Recommendation

To enable access to model switching and other features in ACP mode:

1. Add a new method to handle slash commands in the agent:

   async executeCommand(
     params: acp.ExecuteCommandRequest
   ): Promise<acp.ExecuteCommandResponse> {
     // Parse and execute slash command
     // Return appropriate response
   }

2. Update the #processMessage method in the ACP connection to handle these commands

3. Modify the client (Zed) to send command requests when slash commands are entered

This would involve extending the schema and protocol to include command execution capabilities while maintaining compatibility with existing implementations.

Thoughts?

[acoliver]

from the discussion:
@ConradIrwin said:
Nice! Would you mind moving this to https://github.com/zed/agent-client-protocol?

We'd love to be able to support multiple models. The way I was imagining that it works is that the agent replies to init with available_models: [{"name": "Blah", "id": "blah", default: true}] (kind of like auth_methods).

Then on each prompt call we add model_id: Option so that the prompt is handled by a specific model.

One open question is whether this should be per-prompt or per-session. I kind of like the idea of per-prompt (because you can do stuff and then when the model bails out, switch model and try again), but we should only do that if the agents support it.

response: so generally we want multiple models in a session but also different providers.

LLxprt Code lets you switch providers / models. i.e. I can switch to Anthropic & Claude and then switch to Cerebras / Qwen3 or ZAI and GLM 4.5. It's more powerful to be able to switch to multiple in a session because you can have a discussion with Qwen realize it isn't getting there, bring in Claude and switch back to qwen if you want. Cursor has always had this, and it is super powerful (I don't like much else about cursor, but that's nice). LLpxrt-Code is the only CLI I think that does.

People use MCPs for part of this but that's fine if you know you want Claude then have another cheaper model do execution. However, It stinks to be planning, realize the model isn't cutting it and have to start over. Or if you just want a different model to review you can just switch (I used to do that alot with Claude + o3).

For config: The thing is you can't just switch models. There are settings (context settings, thinking on/off, user preferences [emojifilter]) that all may be loaded. That's why we do "profiles" rather than models.

That said that's not the ONLY slash command. Maybe the most important besides (/set emojifilter auto).

[ConradIrwin]

Makes sense. I guess slash commands in general we have some experimental support for for Claude.

I think selecting the provider/model is a concrete enough concept we should have our own types for it (in the Zed UI, it's a separate dropdown).

I was under the impression that the model and the provider were pretty tightly coupled. Would it work to simplify this to just "model" over ACP, or do we need to have a separate provider selector and model selector.

supported_models: [
  {"model": "gpt-5o", "provider": "OpenAI", id: "openai-gpt-5o", default: true}
]

If we did this and then sent model_id in the prompt, would that let you do what you want?

[acoliver]

If Zed doesn't validate the model and it's just a string selected from a dialog, it could be fine...

This might be a workflow natively

/provider openai
/baseurl https://api.openrouter.ai/v1/
/keyfile ~/.mykey_file
/model somemodel
/set context-limit 128000
/set modelparam max_tokens 8196
/set streaming disabled
/profile save SomeModel

Next time I just do
/profile load SomeModel (and it comes preconfig)

I can switch to different ones in the same context. (we translate them all to an intermediary message format and translate in betwen)

So I suppose if Zed just gave LLxprt Code the model, it could interpret it as "profile" so long as you don't force it into a structure. that's probably better than "provider" and "model" because it still needs things like the key and model config...

(but if a user wants to create a new one from inside zed they need slash commands or to edit json files or soon a TUI dialog)

[ConradIrwin]

That makes sense.

It's interesting to think about both selecting a profile / model / w/e, which is a common use case in Zed, and seems nice to have UI for.

Right now all our setup/config is done out of band in JSON files.I believe we have some support for slash commands already, so you may be able to send an available tool update and have this exact flow work: https://agentclientprotocol.com/protocol/schema#param-available-commands-update

[agu-z]

Slash Commands and Session Modes are now stable.

Let's continue the model selection discussion in #42