Connectors, gifted subscriptions, and a live look at how the model thinks

Until this release, Portail's chat was a closed room. It could reason about your calendar or your inbox if you described them, but it could not open either one. Every fact had to arrive by hand, typed into the composer, which is fine for a question and tedious for anything that repeats. v2.0.0 opens two doors out of that room: Google Calendar and Gmail, reachable from Settings > Connectors, with the chat acting on them directly instead of just talking about them.

The mechanism matters as much as the feature. Portail does not run its own OAuth flow for Connectors and does not store a Google token anywhere in its database. Connecting an app hands the sign-in to Composio, the same managed-auth provider Portail Agents has used since agents.portail.cc launched. Composio's hosted `connectedAccounts.link()` flow does the whole dance and redirects the browser straight back to the chat when it finishes; the server re-fetches connector status rather than catching a callback itself, because there is no `/oauth/callback` route to catch it. When the assistant needs to create a calendar event or send an email, it calls a stable tool name like `google_calendar.create_event`, and connectorTools.js resolves that against Composio's toolkit on the user's behalf. If Composio ever changes its underlying API, that indirection is what keeps a schema change from becoming a breaking change for anyone who has already connected an account.

Two connectors are live today: Google Calendar, which can create and remove events with a request cap so one loose date range can't wipe a calendar, and Gmail, which can read and send mail. Slack, Notion, and GitHub are already defined in the same registry, each with its own toolkit slug and tool map, and each waiting on nothing but an auth config on the server side. Turning one on will not need a client release, because the Connectors tab already renders whatever the server reports as available. That is a deliberate shape: the hard part of adding a connector was building the registry and the tool-execution path once, so that adding the next app is mostly configuration.

Gift subscriptions ship in the same release because they share a shape with Connectors that is easy to miss: both let Portail extend trust to someone who has not fully joined yet. A gift is a real one-time Dodo charge, not a coupon dressed up as a present. The giver picks a plan, from Standard through Ultra++, and a length from one to twenty-four months, and pays for it once. Nothing about the purchase auto-renews, and the recipient never enters a card, because there is nothing recurring to bill them for. The redemption code is the access control, deliberately not a user id: the recipient may not have a Portail account yet, so the code has to work the way the share id for a shared conversation works, as a bearer credential that stands in for identity until identity exists. Redeeming a code at the public /gift/<code> page stamps an expiry on the recipient's billing record, and a daily sweep quietly downgrades them back to Free once that date passes, the same kind of scheduled job that already runs the win-back and daily-tips email sweeps.

For the person sending the gift, the flow lives inside the Billing tab of account settings, next to the existing Upgrade button, and asks for the plan, the number of months, the recipient's email, and an optional name and message. For the person receiving it, an email arrives with the code and, on redemption, the plan is active immediately with no signup form in between if they choose to keep using an existing session, or a normal signup if they are new. An admin Gifts tab lists every gift sent, whether it has been redeemed, and when it expires, which matters because a gift is real revenue and a real support surface: someone will eventually ask where their code went, and the admin tab is where that question gets answered instead of guessed at.

The third change is smaller in code and larger in how the product feels moment to moment. Reasoning models have always taken a beat before their answer starts, and until now that beat was covered by a synthetic "Thinking…" placeholder, static text standing in for work actually happening on a server somewhere. This release streams the model's real reasoning tokens, gated on a per-model `reasoning` flag in the model catalogue, straight into the interface. While the model is still reasoning and no visible reply has started, the raw reasoning text scrolls live in an accent-tinted panel. Once the reply itself starts, or the turn finishes, that panel collapses into a small "Thought process" chip that matches the existing web-search and memory-lookup chips, so the transcript does not get longer just because you now get to see more of it. The distinction is not cosmetic. A placeholder can only ever say "the model is thinking"; real reasoning tokens can show you that it correctly noticed the bill needs splitting unevenly, or that it dismissed an obvious answer for a reason worth reading before you receive the reply that reason produced.

Quote-reply is the smallest change in this release and the easiest to explain: select any text inside a reply, and a Reply button appears above the selection. Clicking it drops that exact text into the composer as a quoted reference for your next message, instead of you copying it, pasting it, and adding your own quotation marks to make clear what you are asking about. It is a small amount of friction removed from a very common motion, asking a follow-up about one sentence out of a long answer, and it is implemented as a floating popup keyed off any element marked `data-quotable`, which means it will pick up new quotable surfaces automatically as they are added rather than needing its own wiring each time.

None of these four features individually would have justified moving the first number in the version string. Together they do, because they change what kind of thing Portail is willing to be responsible for. A chat that can only talk about your calendar is an assistant with an opinion; a chat that can create an event on it is an assistant with access, and access has to be earned with a security story that holds up, which is why the token-never-touches-our-database property of Connectors is not a footnote but the point. A subscription that only the account holder can buy is a product; a subscription someone else can buy on your behalf, sight unseen, with a code instead of a login, is a product that has started thinking about the people around its users and not just the users themselves. Major versions are where Portail gets to make that kind of claim in public and then has to keep it true in every release after.

This entry follows the same rule the rest of the archive follows: real screenshots taken from the running product, not mockups assembled after the fact. The release notes modal, the Connectors tab with Google Calendar and Gmail listed, the expanded Thought process panel sitting next to a quote-reply popup, and the Gift a subscription form are all captured from Portail as it actually renders. The version post itself, the screenshots, and this file are what future releases are now measured against before they ship, which is a better place for the record to live than in a commit message that nobody reads after the fact.