CherryHQ / CherryHQ/cherry-studio
[Feature]: OpenRouter Infrastructure-Provider Filtering (ZDR / Zero Data Retention)
- Dominant language
- TypeScript
- Stars
- 52k
- Forks
- 5k
- Avg merge
- 2d 7h
- Merged PRs (30d)
- 603
Description
## Background
When using OpenRouter as a provider, Cherry has no way to constrain which underlying infrastructure providers OpenRouter routes a request to, nor to require Zero Data Retention (ZDR). Users with compliance or privacy requirements need to ensure requests only go to infrastructure providers that meet their data-retention policy; today every request may be routed to any provider OpenRouter chooses.
## Goal
Users can restrict OpenRouter requests to infrastructure providers that meet their policy — including requiring Zero Data Retention — from the OpenRouter provider settings.
## Spec
- OpenRouter provider settings expose controls to filter or allow which infrastructure providers may serve requests.
- Users can require Zero Data Retention (ZDR), so requests are only routed to providers that don't retain data.
- The chosen policy is applied to every request sent through that OpenRouter provider.
- When no provider can satisfy the policy, the request fails with a clear reason rather than silently falling back to a non-compliant provider.
## Verification
- Enable "require ZDR" → requests are routed only to ZDR-capable infrastructure providers; a non-ZDR provider is never used.
- Restrict to a specific set of infrastructure providers → requests use only those.
- Set a policy that no provider satisfies → the request fails with a clear message, not a silent non-compliant fallback.
Contributor guide
Research direction
No files or tests are named. Start by locating the OpenRouter provider settings and the request-building entry point, then trace how provider policies are passed into each request. Done means users can require ZDR or select allowed infrastructure providers, and unsatisfied policies fail clearly without fallback.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- api, backend
- Issue type
- Feature
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 55/100