Bring your own OpenRouter key
A new way to keep chatting without waiting for a reset: your own key. Open Settings, choose Your own key, paste an OpenRouter API key, and your chats are paid for there instead of with Portail credits. Chat, Council and Ratchet all use it, and because you are the one paying, models above your plan's line open up too. We check the key with OpenRouter before we save it, encrypt it before it is stored, and only ever send it to OpenRouter. After you save it you never see it again, just its last four characters, and you can replace it, switch it off or delete it whenever you like. Set a spending limit on the key at OpenRouter and it can never cost more than you mean it to. If the key is refused or runs out of credit, you decide what happens next. By default that one message is paid with Portail credits and is marked so you can tell, and a key OpenRouter has refused is switched off so it stops getting in the way. Turn the fallback off and you simply see a plain message saying what is wrong with the key. Images, Canvas, Telegram and scheduled tasks keep using Portail credits. Everything is in English and Russian.
836 words
New Your own key tab in Settings: add an OpenRouter key and chat, Council and Ratchet are paid for there, with no Portail credits spent.
Models above your plan's line open up while your own key pays for them.
Your key is checked before it is saved, encrypted at rest, only ever sent to OpenRouter, and never shown again.
If your key is refused or runs out of credit, that message can fall back to Portail credits. You can turn the fallback off.
Portail v2.10.0 shipped on 2026-11-06 as a minor release focused on bring your own openrouter key. A new way to keep chatting without waiting for a reset: your own key. Open Settings, choose Your own key, paste an OpenRouter API key, and your chats are paid for there instead of with Portail credits. Chat, Council and Ratchet all use it, and because you are the one paying, models above your plan's line open up too. We check the key with OpenRouter before we save it, encrypt it before it is stored, and only ever send it to OpenRouter. After you save it you never see it again, just its last four characters, and you can replace it, switch it off or delete it whenever you like. Set a spending limit on the key at OpenRouter and it can never cost more than you mean it to. If the key is refused or runs out of credit, you decide what happens next. By default that one message is paid with Portail credits and is marked so you can tell, and a key OpenRouter has refused is switched off so it stops getting in the way. Turn the fallback off and you simply see a plain message saying what is wrong with the key. Images, Canvas, Telegram and scheduled tasks keep using Portail credits. Everything is in English and Russian. The work is recorded here because small releases are still product history. They change how people sign in, read responses, pay for access, share conversations, open files, or trust the system when something goes wrong.
This was more than a quiet maintenance pass. A minor release changes how a visible part of Portail behaves, how a larger workflow is framed, or how a user understands the product. The important part is not only that the feature exists. The important part is that it joins the rest of the system without making the chat harder to use. Portail is useful because context travels with the user. Every larger release has to protect that feeling.
The main changes were direct: new your own key tab in settings: add an openrouter key and chat, council and ratchet are paid for there, with no portail credits spent, models above your plan's line open up while your own key pays for them, your key is checked before it is saved, encrypted at rest, only ever sent to openrouter, and never shown again, and if your key is refused or runs out of credit, that message can fall back to portail credits. you can turn the fallback off. That list is intentionally plain. It names what changed without turning the release into theatre. When a release fixes a build, a redirect, a storage path, or a UI edge case, the value is often that users stop noticing the problem. The archive keeps that invisible work visible enough for future debugging and for anyone checking whether Portail has cared about the details over time.
For this release, the archive points back to the verified commit trail instead of relying on memory. The title, date, and highlights come from the repository history around v2.10.0. That matters because a release log should be boringly checkable. If someone wants to know why a feature appeared, why a page changed, or why a billing rule behaves differently, the public record and the engineering record should not disagree.
This version also fits into the wider Portail contract. One account, one chat history, and one model picker only work if the smaller pieces keep their promises. Authentication has to fail clearly. Billing has to count honestly. Uploads have to arrive in a form models can read. Admin tools have to show the operator what happened instead of hiding it behind a blank screen. v2.10.0 moved that contract forward in its own narrow lane.
The product lesson is also worth naming. Portail grew quickly through chat, admin, billing, Canvas, Omniverse, Agents, and the coding hand-off bridge. Features landed close together, and some releases bundled polish with deeper infrastructure. This post separates the user-facing promise from the implementation noise. It says what the release changed, why that mattered, and where it sits in the product timeline.
The screenshots attached to this entry show the public release record as it now appears on portail.cc. For older releases, this archive was rebuilt from the git history, package version changes, release modal text, and commit subjects. That means the page is honest about its source: it documents the shipped change and preserves the record going forward, even when the exact old production screen cannot be recreated from a single saved image.
The practical result is simple. Someone landing on this page can see the version number, date, release tier, headline, highlights, and a real rendered screenshot of the archive page. Search engines can index the post through the canonical URL, sitemap entry, and structured data. Future releases now have a standard to meet before deploy, so the history should get cleaner from here instead of fuzzier.
Screenshots
