Support for overriding `edit_prediction_provider` or `assistant` via project settings

[lougreenwood]

Summary

Currently Zed project settings cannot configure edit_prediction_provider or assistant settings. Certain projects may wish to restrict the use of LLMs to specific services.

Description

At work I need to use our Enterprise GH copilot, but outside of work I use Supermaven & open ai.

I tried to set supermaven & open ai as the default & override for my work project, but it seems that the local override is not applied:

{
  "features": {
    "edit_prediction_provider": "copilot"
  },
  "assistant": {
    "default_model": {
      "provider": "copilot_chat",
      "model": "gpt-4"
    },
    "version": "2"
  }
}

Environment

Zed: v0.148.0 (Zed Preview) OS: macOS 14.5.0 Memory: 32 GiB Architecture: aarch64

[rtfeldman]

@lougreenwood We talked about it, and decided that we don't want to enable project-specific overrides for assistant settings, because those get checked into code repositories and applied automatically whenever anyone (possibly a stranger) checks out that project.

For example, a user experience we'd like to avoid is:

• I check out a project which has project-specific assistant overrides, but I don't think to check for that
• I start using Zed normally, and suddenly I'm seeing unexpected outputs from the model I'm used to, and getting charged a different rate for my tokens.
• I eventually realize it's because there was a project-specific override, and now I need to override that override to get back to the settings I personally prefer.

I wonder if there's some other way we can address the use case you're describing, but I don't have a specific idea in mind so far! 😅

[lougreenwood]

Thanks for the reply @rtfeldman but I fear that this will become a deal breaker for me to continue to use Zed.

My job forbids me from using anything other than their instance of copilot enterprise - period. For legal & IP reasons copilot is the only allowed tool.

However, personally I use Claude (see the $20 of spend in the past few days on my Zed account 😉).

I can somewhat understand the concern WRT a contributor changing the model and that affecting the selected model, but also, that's the intention of project-specific settings - to override defaults for a given project.

I'm reminded of something like VSCode's safe mode.

Or maybe a subset of these kind of project specific settings are cached and the dev must agree to adopting updated settings (ie model / inline assistant etc).

I hope we can find a way to support this - I'm enjoying Zed tremendously for the past 9 months or so after switching from nvim!

[powersagitar]

@rtfeldman Can we at least disable the assistant in project overrides, or have a toggle in command menu to conveniently enable/disable ai assistants like VS Code does?

https://github.com/zed-industries/zed/issues/19272 was considered a duplicate of this issue (my bad), but now I think it is somehow less duplicated, and could be a separate issue to think about?

[ghost91-]

Seconding @powersagitar’s take.

@rtfeldman I understand the problems you described. However, in my opinion, for people that work on multiple projects, being able to control in which projects AI related features are enabled is essential.

As a consultant, I am frequently in the situation that I am allowed use AI functionality for some projects, but for others, it’s strictly forbidden. At the moment, Zed has an “all or nothing” approach. That makes it quite cumbersome to use when switching between projects.

One alternative solution to this would be if we could define a whitelist of projects in which agent and edit_prediction_provider should be enabled (by providing a list of absolute paths to those projects, or something similar). That has the benefit that it would still be in the main settings (so no weird surprises when checking out project specific settings), but the user still has full control over which projects AI related features are enabled in which project.

What do you think about this approach?

[ghost91-]

Now that we have disable_ai, Could we at least support setting that on a project level? That would allow people to either globally disable it, and then selectively enable it for specific projects, or the other way round, disable it for specific projects. That would be immensely helpful!

[forfudan]

Agree with @ghost91-. Some projects may contain sensitive information and it would be great that the AI can be disabled for specific projects.

[SLIB53]

If AI usage is meant to be a per-user setting (since we don't want projects enabling and disabling usage for user experience reasons), then I think it makes sense to give users a way to have per project configurations local only to them. I would expect those settings to be somewhere in or near ~/.config/zed/settings.json.

I know that is a bigger ask than the ticket, but I think this case shows that a number of us not only think about 1) global settings per user, 2) project settings for everyone, but also 3) per project settings per user.

[notpeter]

I was thinking about how this might be implemented and while "features": { "edit_prediction_provider": "copilot" }, in project settings seems straightforward, it's then unclear how an individual user could opt to disable those settings (even temporarily) because zed project settings take precedence of zed user settings. So if I have "edit_predictions_provider": "none" in my user settings should edit predictions be automatically enabled for such a project?

Similarly, what would be the result of disable_ai false / agent.enabled true be in project settings if my zed user settings had those features disabled? It would be possible to implement a custom merge strategy such that certain settings values were no-ops, but this would make these settings behave differently than all others (likely violating the principle of least surprise).

I also could imagine someone who might want to the existing (simple) settings merge strategy where by AI is disabled by default in their user settings and explicitly enabled on project-by-project basis via zed project setting -- and these two use cases directly conflict.

Perhaps it would be more appropriate to add dedicated settings:

  "allowed_providers": {
    "edit_predictions": ["copilot, "supermaven", "zed"],
    "agent": ["anthropic", "openai", "copilot"],
  }

But that too would likely require a custom merge strategy, so that my global settings could allow ["ollama", "openai", "athropic"], my project settings would allow ["openai", "anthropic", "copilot"] and the workspace would be allowed the intersection of those two two sets: ["openai", "anthropic"]. But then we're quickly into the territory of enterprise / MDM type features.

I know that is a bigger ask than the ticket, but I think this case shows that a number of us not only think about 1) global settings per user, 2) project settings for everyone, but also 3) per project settings per user.

@SLIB53: This has been tossed around internally as well. One of the biggest reasons against this is if it's inside the project folder, it has to be be in .gitignore; which makes it hard to version control. And you still have the complexity about merge strategies (am I allowed to override the per-project agent providers? No? Am I allowed to override the per-project LSP settings? Yes?) -- this strikes me as a UX nightmare. Not impossible, but difficult to get right.

I also have no idea what to do in a multi folder workspace. I don't have a clear sense of the best direction for this, but wanted to share some thoughts about the lurking complexity.

[SLIB53]

Thanks @notpeter , makes sense that there's complexity here. I'm not sure I'm understanding the mental model or paradigm of how settings are applied. I didn't consider that they were coequal configurations that merged, I solely assumed there's hierarchy / order of precedence allowing a cascade of configurations (from lowest to highest: default user settings < custom user settings < project settings).

Furthermore, I now see that there are 3 scopes of settings: 1) user, 2) workspace, 3) project.

Regardless, I think there's a root problem worth highlighting: Users would like to control the final configuration. Currently, the project owner(s) have the final say on a configuration, which leads to the UX problems described.

---

Theory:

• I think in principle, anywhere a user inherits settings (e.g. default user settings, project settings), they should be given a way to override it.
• I also think hierarchical configurations that cascade are more transparent to understand than a flat model where settings are merged.
• It appears that there's 3 scopes of settings: 1) user, 2) workspace, 3) project.

That gives the following expanded hierarchy of possible configuration points, from lowest precedence to highest (theoretical for the sake of explaining, actual solution can of course be simpler):

Precedence	Configuration	Author	Location
1	Default user settings	app	internal
2	Custom user settings	user	~/.config
3	Default workspace settings	app	internal
4	Custom workspace settings	user	~/.config
5	Default project settings	project owner	project folder
6	Custom project settings	user	~/.config

For each scope of configuration, the schema is not necessarily the same (ex. disable_ai is not available in project settings, but would be available in user settings and workspace settings).

Having workspace settings resolves your final point, and overrides would continue to work as expected if the paradigm is cascading configurations. Custom project settings may not have any real use cases after that, but I included it with respect to what I think is the root problem ("users would like to control the final configuration...").

---

References:

• Visual Studio Code Multi-Root Workspaces

[brian-mcnally]

@notpeter - could you confirm what the scope of Zed's AI access is currently? Anecdotally, it would seem to be confined to whatever is opened in the current project in the current window but I've not seen where this is documented.