Every model, one allowance

Portail v1.0.0 shipped on 2026-08-09 as a major release focused on every model, one allowance. Portail shipped the full OpenRouter catalog with credit-only model access. 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.

A major release deserves a longer record because it changes the shape of the product, not just one corner of it. v1.0.0 marked a point where Portail's public promise became larger than the build before it. The release moved the product into a new phase, and it should be possible to understand that shift without reading every commit in the repository.

This was more than a quiet maintenance pass. A major 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 headline for this version was every model, one allowance. In practical terms, that meant opened the full openrouter text model catalog, moved model access to a credit allowance model, and kept saved conversations working through legacy model aliases. Those are not decorative claims. They describe the pieces a user could feel: the model list they could choose from, the way account access was gated, the way context moved, or the way the product explained itself in public.

The main changes were direct: opened the full openrouter text model catalog, moved model access to a credit allowance model, and kept saved conversations working through legacy model aliases. 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.

Major versions also reset expectations for future work. Once a capability is public, the next release has to maintain it, explain it, price it correctly, and keep it from breaking adjacent flows. That is why this archive keeps the operational details close to the product details. A launch is not finished when the page renders once. It is finished when the route, metadata, billing copy, screenshots, and deploy process all tell the same story.

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 8216071. 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.

The version number itself matters here. Moving the first number says the product is no longer asking to be judged as a sketch. It can still be young, rough in places, and moving quickly, but the core promise has to be stable enough for users to build habits around it. For Portail, that promise was one conversation that can move between models without making the user start over.

That promise is also why the release log keeps mentioning surrounding systems instead of treating the web page as the whole product. A major Portail update can touch the public site, the chat shell, the server, the hosted agents surface, the Code experience, and deployment scripts in one pass. The visible headline is only one layer. The release is healthier when navigation, metadata, storage, build scripts, and operational checks all move with it.

For search, this post is indexed like the rest of the archive. It has a canonical URL, normal index and follow robots metadata, article metadata for previews, and BlogPosting structured data. The sitemap lists it explicitly. That is not decoration for a release log. It is how the record stays discoverable after the announcement moment is gone.

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. v1.0.0 moved that contract forward in its own narrow lane.

The screenshots here show the current public release record. For early versions, the archive was backfilled after the fact from git history and release copy. That is not as rich as a screenshot captured on release day, but it is real, reproducible, and tied to the page users can open now. From this point forward, deploy validation requires screenshots before release, so new entries will carry that evidence at the moment they ship.

The product lesson is also worth naming. Portail grew quickly through chat, admin, billing, Canvas, Omniverse, Agents, and the Portail Code 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.