Custom profiles

Bring the models and subscriptions you already use into Cloaky while keeping every provider, credential, and privacy boundary explicit.

Start with the job

Cloaky keeps threads, permissions, subagents, diffs, review, and cost records in one workbench. You choose the intelligence behind each session, and Cloaky keeps the provider and privacy tier visible from the start.

A useful order of operations is:

1. Choose local when the available model is capable enough. Ollama and LM Studio keep inference on this machine.
2. Choose Venice private for hosted capability with a zero-retention contract. Review the tier in the picker before starting.
3. Choose a direct provider when the task needs its model or your existing subscription. That provider’s terms apply.

This is what pseudonymous means in practice: different sessions can have different identity and data boundaries. Cloaky names the route instead of compressing every provider into one privacy claim.

Venice

Venice is the first hosted route to consider when you want cloud inference without prompt and response content being retained after the request. That is Venice’s private-tier contract. It does not remove operational metadata such as account, billing, model, timestamp, token, or IP information.

Some Venice models support E2EE + TEE for tool-free turns. Agent turns that require structured tools use Venice private because the encrypted route does not return tool calls. The session badge reports the route that ran.

Set up Venice in Settings → Providers & privacy. The model picker shows the provider, tier, context window, capabilities, and available cost information.

Local models

Enable Ollama or LM Studio, then open the local models gallery to find models that support tool use and fit the machine’s available memory.

Local is the strongest privacy boundary because inference terminates on a service you run. Capability and hardware still matter, so choose a model that fits both the task and the machine.

Direct providers

Connect a Claude subscription, a GLM or Kimi coding plan, or an OpenAI-compatible provider when that route is the right fit. The provider receives the session under its own account and data policy. Cloaky identifies the route without extending Venice’s guarantees to it.

Provider choice is fixed when a session starts. If the provider cannot start, Cloaky stops and explains the next action instead of falling through to a different service.

Create a custom profile

Custom profiles are for providers Cloaky does not configure for you, or for a subscription that needs its own endpoint and model mapping. A profile keeps those choices together so you can switch routes without rebuilding your setup for every session.

Open Settings → Providers & privacy → Custom profiles, then add:

1. A clear profile name. Use the provider and plan, such as “GLM Coding Plan” or “Kimi direct,” so the route is unmistakable in the session picker.
2. The provider’s compatible protocol and base URL. Copy the endpoint from the provider’s current documentation. Coding-plan endpoints can differ from metered API endpoints, even when both accept the same key.
3. The exact model identifier. Model names are provider-defined and case-sensitive. Confirm the current identifier before a long session.
4. A dedicated credential. Keep keys in Cloaky’s credential flow. Never put a key in a profile name, prompt, project file, issue, or support message.

Use Test connection before saving. Cloaky validates the route you entered; it does not silently replace a failed custom provider with Venice or another service.

Existing GLM and Kimi plans

GLM Coding Plan and Kimi platform accounts are good custom-profile candidates when you already pay for them or need a specific model. They are direct routes: z.ai or Moonshot receives the session under its own account and data policy. Venice’s private-tier terms do not carry across.

Use the endpoint assigned to your plan, not a similar-looking general API URL. For example, z.ai documents separate coding-plan and general-purpose endpoints. Provider endpoints and model IDs can change, so follow the provider’s current setup guide rather than copying an old value from a post or screenshot.

Once saved, start a short test session and confirm the provider badge, model, and privacy tier before sharing project context. A successful response proves the route works; the badge tells you who handled it.

Hybrid: hosted planning, local execution

Hybrid mode lets a Venice model plan, orchestrate, and review while a local model handles delegated work on this machine. It combines stronger hosted reasoning for key decisions with local inference for suitable subagent tasks.

The hosted portion follows Venice’s provider policy; the local portion remains local. Cloaky identifies hybrid sessions and reports when the local route is unavailable.

Before sensitive work

• Confirm the provider and tier in the model picker.
• Read Private as a provider contract, not an encryption or anonymity claim.
• Read Anonymized as identity protection, not prompt secrecy.
• Remember that approved web, search, MCP, and shell tools can access the network independently of model inference.
• Keep provider credentials out of prompts, issues, and support conversations.