Your model, your choice: with Bring Your Own Model, you decide which AI powers your characters and where it runs – on your device or with a cloud provider. Here's some guidance to help you get started.
The model is the AI system behind your character. It writes the replies and shapes how natural the conversation feels, what knowledge it draws on, and how quickly it responds.
A few terms will help you compare models. Expand any topic you'd like to explore:
A model's size is usually expressed as its number of parameters, often also called weights. As a simple analogy, think of them as the strengths of connections between nerve cells. “B” means billion; “T” means trillion.
Among models of a similar generation, more parameters can mean more knowledge and better language skills, but also greater memory and computing requirements. Size alone doesn't tell the whole story: with MoE models, for example, both active and total parameters matter.
You'll often see two designs: a dense model uses all of its parameters during computation. A MoE model (Mixture of Experts) activates only a subset of its specialized “experts” at a time.
This allows a MoE model to work with considerably less computation than its total size might suggest. It combines the capacity of a large network with computational requirements closer to those of a smaller model. Its actual speed and language quality depend on the specific model and hardware.
For local use, keep in mind that inactive weights still need memory. The active parameter count therefore doesn't describe the model's full memory requirements.
In our tests, dense models have particularly impressed us with their depth and nuance in conversation. If that matters to you, our recommendations are worth a closer look.
The context acts as the model's short-term memory. It includes the conversation so far, the character description, and your current input. It's measured in tokens: pieces of text such as words or parts of words. 128K tokens is roughly the length of a long book.
Cloud providers often cap the usable context below the model's technical maximum. You don't need to fill that window, though: more context can increase costs and reduce response quality, as models sometimes overlook details in long conversations, especially in the middle.
A model's weights are often stored as floating-point numbers – number formats that can represent values of different magnitudes and fine increments. Labels such as FP16 or BF16 refer to formats that use 16 bits per weight.
Quantization makes this representation more compact. Many methods use small integer codes and shared scaling factors. Put simply, the values are mapped onto a coarser grid rather than preserving every fine distinction. This saves a lot of memory, often with only a small loss in quality.
Labels such as Q4, Q5, or Q8 give you a rough guide to the bit width. The smaller the number, the more compact the representation – and the greater the potential loss in quality. The exact memory requirements also depend on the method; the label alone doesn't tell the whole story.
For local use, 4-bit versions are a common compromise between size and quality. The hardware tips below explain how much memory to allow for.
Two models stood out in our everyday testing with CORVISH!: one for powerful local hardware or the cloud, the other primarily for cloud use.
Our favorite · local or cloud
Strong at roleplay, with natural language and a consistent sense of character. It's demanding at full precision, but a quantized version can run locally on a high-end consumer GPU with around 24 GB of VRAM. That combines good conversation quality with local data processing. If you have less VRAM, a cloud provider hosting the model is an alternative.
A strong conversationalist · best suited to the cloud
Despite its name, this is a large European model: 119 billion parameters, with only around 6.5 billion active. It delivers quick, fluid dialogue and follows instructions well, with language quality comparable to a good mid-sized model. All weights still need memory, so local use calls for very powerful hardware. For most people, the cloud is the more practical option.
Both are open-weight models: you can run them locally or use a cloud provider that hosts them. Either way, you connect them to CORVISH! in the same way. We'll keep adding recommendations for different devices and needs.
There are plenty of other capable models, especially in the cloud. If you'd like to explore, here are a few things to look for:
Check what the model is built for: Models have different specializations. For lively conversation and roleplay, general-purpose chat or instruct models are usually the best choice. Models tuned for programming are strong at code but often a little dry and stiff in open-ended dialogue – not necessarily the first choice for CORVISH! Models built for specific tasks, such as Llama Guard for content moderation, aren't intended as general conversational partners at all.
The name often offers a clue: look for terms such as Coder, Code, or Math. Chat or Instruct are good starting points, but don't guarantee an all-rounder – specialists can follow instructions too. Vision alone is no reason to rule a model out: it can understand images and still be a good conversational partner. Image understanding can even enrich a conversation, for example when a photo, sketch, or screenshot helps make your meaning clearer.
To process images you upload, CORVISH! needs a model with image understanding. The Vision ✓ label in the spec line shows you which models have it.
When in doubt, check the provider's model description – the “model card.” Its opening sentences usually explain what the model is intended for.
You don't have to find the perfect model right away. Start with one of our recommendations and get to know your characters – your favorite model might already be on the list.
Windows, Linux, macOS
A simple starting point: install Ollama, download a model, and connect it to CORVISH! A fully local model processes your conversations on your device and works offline too. For models beyond your hardware's capabilities, there's Ollama Cloud: they run on Ollama's servers, using the same connection.
Linux, dedicated GPU – for power users
For servers and workstations with a powerful GPU, including on your home network. vLLM is built for high performance, but takes more experience to set up.
You aren't limited to Ollama or vLLM. CORVISH! supports OpenAI-compatible interfaces, including those offered by local applications such as LM Studio, llama.cpp, or Jan, or by your own server on your home network.
A cloud provider lets you use powerful models without a powerful graphics card of your own – handy on mobile devices and older PCs. The provider generates responses on its servers, a process called inference. To connect, create an API key with the provider and enter it in CORVISH!
AI model routers bring models from several providers together under a single API key. Expand any provider in the overview below to learn more.
Privacy commitments vary considerably. We compare providers against five criteria. Here's what the symbols in the overview mean:
The provider commits not to use your API requests to train its models. This is an important commitment about data use, but it doesn't automatically mean the content isn't stored. The separate ZDR criterion covers retention.
When a service forwards requests to external model providers, it can shield your account details, IP address, and payment information. The model provider then receives the request through that service rather than under your own identity.
Important: this does not remove personal details you include in the conversation yourself. Anonymization alone also says nothing about content retention; the relevant privacy commitments govern that. Not every router offers this protection. See the individual provider entries for the differences.
Zero Data Retention is a commitment to discard conversation content after processing rather than keep it in persistent storage. Billing metadata, such as timestamps and token counts, may still be collected.
The specific terms matter: some providers make exceptions for abuse detection or legal obligations. ZDR is a commitment about data handling, not a technical barrier to access like a protected execution environment.
TEE (Trusted Execution Environment): The provider processes your requests in a specially protected environment called an enclave. Hardware isolates the computation from the rest of the system, including administrative access by the operator. Protection therefore doesn't rest on a privacy promise alone. What matters, however, is which processing steps actually take place inside that environment: data held outside the enclave before or after processing is not automatically protected by it.
Verifiable, not just promised: Cryptographic attestation makes it possible to verify which software configuration is running in which protected environment. This doesn't prove that the software is free of bugs or handles data responsibly. It does allow the deployed environment to be compared with a previously reviewed configuration. The app or independent experts can perform these checks. The important difference from a promise alone is that technical claims become verifiable. Whether and how that verification happens remains crucial.
The gap is often on the way in: TEE protects the computation, not automatically the entire transmission path. A normal HTTPS connection already encrypts your request in transit. But if that encryption ends at an intermediary server operated by the provider, that server can see the request in plain text before forwarding it to the enclave. If encryption ends only inside the enclave, that intermediary cannot read it – provided the connection really leads to the expected protected environment.
E2EE (end-to-end encryption): Here, this means encryption from your app all the way to the protected processing environment: intermediaries cannot read the conversation content. One approach is to encrypt the request on your device using a key belonging to the enclave. The app verifies the attestation and checks that the key belongs to the expected environment. Decryption happens only there. Additional application-level encryption isn't inherently necessary, however, if the transport connection is already verified to terminate directly inside the trusted enclave.
What this means for CORVISH!: CORVISH! currently uses standard provider interfaces. It does not yet implement its own encryption to an enclave whose attestation the app has verified; this E2EE support is planned. TEE protection applies only where the provider offers it for the selected model and access method. Whether intermediary servers can see conversation content depends on the provider's technical implementation – the TEE label alone doesn't answer that question.
TEE can significantly strengthen protection compared with a purely contractual commitment. Its scope depends on the entire processing chain. The additional overhead can affect speed; how much depends on the implementation.
These details describe a model: its context length, capabilities such as image processing or tool use, and pricing. Some providers also supply information about ZDR, TEE, or anonymization. CORVISH! can display the available privacy details directly in the model catalog to help you choose.
The details are based on the linked provider information and documented commitments. Technical safeguards are marked separately.
A privacy-oriented AI provider with a broad model selection and model-dependent privacy tiers. You decide which model fits your conversations and your privacy requirements:
Why we recommend Venice: Its broad model selection and clearly labeled privacy tiers are a good fit for CORVISH! The app can display those details directly in the catalog to help you choose.
Driver in CORVISH!: Native (Venice).
Sources: Website · Privacy policy · Privacy explained · Metadata API · As of September 2026
Decentralized network for confidential inference, based in the USA. Every model in the catalog runs inside a protected environment – privacy applies provider-wide:
Driver in CORVISH!: Native (Phala).
Sources: Website · Privacy policy · Documentation · ZDR documentation · Metadata API · As of September 2026
The cloud variant of Ollama: same app, same driver, but the models run on Ollama's servers and with NVIDIA Cloud Providers (NCPs) – handy for devices without a strong GPU. Hosting is primarily in the USA; to serve global demand, Ollama may additionally route to Europe and Singapore. The guarantees apply provider-wide, for all models:
Driver in CORVISH!: Native (Ollama).
Sources: Website · Privacy policy · Pricing & privacy FAQ · Metadata API · As of September 2026
A US provider offering low-cost inference for popular open-source models. Its privacy commitments apply to the models it hosts itself. For externally hosted models from providers such as Anthropic or Google, those providers' privacy policies also apply. ZDR in particular is not always guaranteed.
Driver in CORVISH!: Native (DeepInfra).
Sources: Website · Privacy policy · Data privacy documentation · Metadata API · As of September 2026
An AI marketplace offering dozens of models through one API key, from OpenAI and Anthropic to open-source alternatives. Useful if you want to compare models without opening an account with every provider. As with Venice, privacy commitments vary by model and are listed individually:
Driver in CORVISH!: Native (OpenRouter).
Sources: Website · Privacy policy · ZDR settings · Metadata API · As of September 2026
European provider (France) with strong open-weight models. Privacy under EU law (GDPR) – as an EU provider without a US parent, Mistral is not subject to the US CLOUD Act; government access is bound by EU law. Privacy at a glance:
Driver in CORVISH!: Generic (OpenAI-compatible).
Sources: Website · Privacy policy · Data usage for training · ZDR request · As of September 2026
The official OpenAI API: high performance, well-known models. The applicable privacy law depends on where you live: for customers in the EEA, Switzerland, and the UK, OpenAI Ireland Ltd. is the controller (EU GDPR, UK GDPR, or the Swiss FADP depending on the region), while for the rest of the world it is OpenAI OpCo LLC (US law); European customers can also use EU data residency. Privacy at a glance:
Driver in CORVISH!: Native (OpenAI).
Sources: Website · Training data usage · Data storage & ZDR · As of September 2026