A model in the product is a record of where and how to ask for answers, and how much that work costs. With one record you describe both the connection to the vendor and the price by which spending is counted. Everything else — access keys, the log, analytics — builds on that record.
What a model describes
- The public name — the one programs put in the request. It is what appears in the model list and in the log.
- The provider label — free text for order: “openai”, “anthropic”, “own server”. It does not affect behavior; it is there for clarity.
- The base address — the vendor address the request goes to.
- The request address — an optional refinement for vendors with a non-standard path.
- The vendor key and the authorization method — what proves the request on the vendor’s side.
- The “enabled” switch — a disabled model stays in the settings list, but is not served to programs, and requests to it do not pass.
Prices per million tokens
Every model has four prices, all per million “portions of text” — that is, tokens. A token is a small piece of text: roughly a word or part of one. That is the unit in which a model’s work is measured.
- Input — for the text you send to the model.
- Output — for the text the model sends back. The hidden work of “reasoning”, when the model does it, counts here too.
- Reused input — for the part of the sent text the vendor has already seen before and does not recompute. Usually cheaper than plain input.
- Writing to temporary storage — for preparing text for reuse.
From these prices the product computes the cost of every request, and from the cost the spending limits and analytics work. If all prices are left at zero, the model counts as free: requests and tokens appear in the log, but the spending stays zero. For honest numbers, fill the prices in from the vendor’s rates.
A connection of its own for every model
Earlier, the connection was a separate entity shared by several models. That is gone now: every model has its own connection — its own address, its own key, its own authorization method. Life is simpler when models live with different vendors: nothing to coordinate or switch, every record is self-sufficient.
If a model needs its own permanent channel — for example, through your proxy — it can be pinned to the model (channels are created in the neighboring “HTTP proxies” section). That model’s requests then always go through the chosen channel, with no switching to another one or to a direct connection.
Cloning
If a model differs from an existing one in only a couple of fields, there is no need to create it from scratch — the “Clone” button is enough. The copy gets a name like “name copy”, “name copy 2” and so on, inherits the connection, the key, the prices, the settings and the enabled state, and you adjust what you need.
Checking the connection
The “Test” button sends a request along the model’s real route — through the pinned channel, if there is one — and shows the result: whether the vendor answers, how long it took and what code it returned. One useful thing to know: the check always presents itself to the vendor with an ordinary authorization header. If the vendor does not accept it for some reason, the check may fail even though real requests would work.
The key shows as a mask
The vendor key is never shown in full: the interface displays only a mask like sk-1...cdef. If you open a model and save it without changing anything, the key stays as it was — the mask is understood as “leave as is”. A key can be replaced only by typing a complete new value.
Deletion and restrictions
A model cannot be deleted while it is the last allowed one for some key. Otherwise a key that had a list of allowed models would quietly turn into an unrestricted key, and that is unsafe. The product names the keys that stand in the way and suggests lifting the restriction first. If a model is one of several allowed, it deletes fine, and the key stays restricted to the rest.
The same rule holds for channels: a channel will not delete while at least one model references it.
Special DeepSeek settings
DeepSeek models have one extra setting: what to do when a request needs “reasoning” but no suitable saved record exists. There are two options — refuse with the clear message “Start a new chat”, or substitute a fixed placeholder and continue. The first is more honest: you see right away that the dialogue has to start over. The second is more convenient when the break is not critical.
Next: how to reach the internet through your own proxy, SOCKS5, a VPN or a Happ subscription — in the Providers section (called “HTTP proxies” in the interface).