There are four common options: a vendor-hosted service, a vendor tool running in your own cloud account, a model on your own servers, and a local model on developer machines. Moving toward your own infrastructure keeps code closer to home, and moves more work and quality risk onto you.
The four options
1. Vendor-hosted service. Code or diffs go to the vendor, and often on to a model provider. Setup is quick. You depend on their contract, retention and sub-processors.
2. Vendor software in your cloud account. The vendor's tool runs inside your tenancy and calls a model endpoint you control or approve. Code stays within your account boundary, except for calls to the model service.
3. Model on your own servers. You run an open or licensed model on hardware you operate. Nothing leaves your network. You own patching, capacity, upgrades and evaluation.
4. Local model on a laptop. A smaller model on the developer's machine. Private and fast to start, but weaker, and hard to manage centrally. See a private code assistant on your laptop for a walk-through of what that looks like.
Comparing them
| Factor | Hosted | Your cloud account | Own servers | Local |
|---|---|---|---|---|
| Code leaves your control | Yes | Partly | No | No |
| Setup effort | Low | Medium | High | Low per person, high to manage |
| Control over data retention | Contract | Mostly yours | Yours | Yours |
| Model quality | Often highest | Depends on endpoint | Depends on what you can run | Usually lowest |
| Central logging and policy | Vendor dashboard | Yours | Yours | Hard |
| Ongoing work for you | Low | Medium | High | Medium |
Treat the quality row with care. Quality depends on the specific model, not the position, and you should measure it on your own cases with a test set.
How to choose
Start with the data. Classify the repositories: public, internal, sensitive, regulated. Then match:
- Public and low-sensitivity code: hosted is usually fine, with contract checks.
- Sensitive code: prefer options where retention and sub-processors are within your control.
- Regulated or export-controlled code: check legal constraints first. Some rules limit where data may be processed or who may access it.
Then add capacity. Running your own model needs people who can operate it and evaluate it. A team without that capacity may end up with weaker security by running something stale, than by buying a service with a good contract.
What to ask in each case
For hosted: the seven data handling questions.
For your cloud account: which calls leave the account, to where, and what is logged.
For your own servers: who patches the model server, how model versions are approved, and how you will detect quality drift.
For local: how settings are managed, how updates reach machines, and how you would know if someone disabled it.
Mixed approaches
Many teams mix: a hosted service for most repositories and a stricter option for a handful. That requires clear routing rules, so developers know which tool applies where. Write the rule down and enforce it with repository settings, not with memory.
Quick check
Does running a model myself make review safer?
It reduces data exposure, but you take on operations and quality risk. Safer overall depends on how well you run it.
Can I use a different option for different repositories?
Yes, and it is common. Write routing rules by data class and enforce them in repository settings.
Safeguard works across IDE, CLI, desktop and mobile surfaces, and its free scan at gold.safeguard.sh/scan is a way to see a result without installing anything.
Last reviewed: 19 October 2026.
