Extend ACP to allow other features like /slashcommnads

[acoliver]

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?

[ConradIrwin]

@acoliver 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<String> 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.

[notpeter]

Moved here:

• Extend ACP to allow other features like /slashcommnads #77