Hyper docs

Goal for this release

The last release rebuilt Hyper’s connector system, expanded what the agent could do across connected products, and brought Hyper to iPhone.

It also made the next limitation clear: Hyper could do substantial work when someone was actively chatting with it, but it could not continue doing recurring work after they left. Connector synchronization also needed to become faster and more reliable as the number of supported products and connected accounts grew.

Our goal for this release was to address those problems directly:

Let people create and manage automations entirely through chat.
Run work on a schedule or when something new arrives in a connected product.
Give automation owners explicit control over instructions, accounts, external actions, approvals, and sharing.
Add the connectors teams requested for messaging, engineering, email, databases, tasks, and scheduling.
Move every connector onto one faster and more reliable synchronization system.
Make chat history, navigation, and files easier to work with.
Upgrade the default model while preserving existing model selections.

We shipped 130 pull requests across these areas.

Automations are here

Hyper can now continue doing work after you close the app.

Start a new chat and describe something you want Hyper to do repeatedly. For example:

Every weekday morning, summarize the new emails that need a reply.

Every Friday, review our open Linear issues and write a project update.

When a new meeting appears on my calendar, prepare a briefing using the attendee, company, and previous conversations.

Hyper helps turn the request into an automation, asks a blocking question only when something important is missing, and shows a confirmation card before anything starts. The card states the instructions, trigger, connected accounts, sharing, and any external actions the automation may take. Nothing runs until the owner confirms it. (#515, #525, #552)

Scheduled automations

An automation can run:

Daily at a specific time.
On selected days of the week.
On a specific day of each month.

Schedules use the person’s actual IANA timezone rather than a fixed UTC offset. This keeps the local time correct through daylight-saving changes, travel, short months, and other calendar boundaries. A time skipped by a spring-forward transition moves to the next valid minute, while a repeated fall-back time runs only once. (#481, #522, #549)

Automations triggered by new information

An automation can also run when Hyper receives:

A new Gmail message.
A new Google Calendar meeting.
A new Linear issue.

For example, an automation can watch for a new finance email, file the invoice, and prepare a reply.

Event automations begin watching from the time they are created or resumed. They do not run against an old mailbox, calendar, or issue backlog. Each connected item can create at most one run, even if the provider delivers the same event more than once.

Burst controls prevent a busy source from flooding the chat list. An automation can run up to 12 times per hour from new items; additional occurrences are recorded as missed rather than queued without limit. (#532)

Every automation run is a conversation

Each run appears as a normal conversation in Hyper.

The conversation shows:

Which automation created it.
When the run was scheduled or triggered.
Whether it is running, delayed, waiting for approval, completed, limited, or failed.
The answer and tool activity produced by the run.

New runs appear with an unread indicator and synchronize across devices. Opening the conversation marks it as read for that person without changing its state for other workspace members. You can continue the conversation normally to ask a follow-up or refine the result. (#509, #550, #565)

Scheduled work is claimed transactionally, so one occurrence creates at most one run conversation. If a worker stops unexpectedly, Hyper can reclaim the existing run instead of creating another copy. Runs use durable leases, bounded retries, and explicit delayed and missed states. (#508, #522, #551)

External actions are decided before an automation runs

An unattended automation should not inherit every permission its owner has granted during unrelated conversations.

The confirmation card therefore lists every external action the automation may take, including the product, connected account, effect, and destination. The owner chooses how each action behaves:

Draft: Prepare the work and leave it for the owner.
Automatic: Perform the confirmed action without asking during every run.
Per run: Ask the owner each time.

An automation receives authority only for the actions confirmed on its own card. An earlier “always allow” answer from a normal conversation cannot silently expand what the automation is allowed to do. (#531)

When a run encounters an action that still needs approval, it parks instead of holding an open process. The approval remains in the run conversation. After the owner decides, Hyper resumes from the stored tool call and avoids executing an already completed action twice.

If an external action was sent but its result could not be recorded, Hyper reports that the outcome is unknown instead of retrying blindly. (#528)

Automations can be managed through chat

You can ask Hyper to:

List your automations.
Run one immediately.
Pause or resume one.
Delete one while keeping its previous run conversations.
Repair an automation that needs attention.

Hyper lists the current automations before acting and uses their exact IDs internally. If several automations could match a request, it asks which one you mean instead of guessing.

The automation list shows its trigger, next run, current state, owner, sharing, and whether it is running now. The same lifecycle controls are available from the list. (#490, #526)

Each automation also keeps its selected model. Scheduled, event-triggered, resumed, and manually started runs all use that model rather than silently falling back to the current product default. (#527)

Feedback can improve future runs

Feedback in a run conversation can apply only to the current result or become a proposed change to future instructions.

Hyper distinguishes between requests such as:

Rewrite this result with a shorter introduction.

and:

From now on, leave the introduction out.

When the intended scope is unclear, Hyper asks whether the feedback applies only to this run or to future runs too.

A future-facing change appears as a line-by-line instruction diff. The owner can apply or reject it. Applied changes create a new immutable instruction version, while previous runs remain attached to the instructions they actually used. Changes can also be undone without rewriting that history. (#529)

Automations can be shared with a workspace

An automation can remain private or be shared with the workspace.

Shared automation runs are readable by workspace members, but only the owner can:

Pause or resume the automation.
Run it manually.
Change its instructions.
Change its sharing.
Delete it.

Runs continue using the owner’s connected accounts and permissions. If sharing could expose information from one of the owner’s private connectors, Hyper warns the owner and requires an explicit acknowledgement before enabling workspace sharing.

If the owner leaves the workspace, their automations pause automatically rather than continuing under an identity that is no longer a member. (#530)

Failed runs explain what happened

A failed or limited run now leaves a note in its conversation explaining:

What failed.
Which connected source refused access, when applicable.
What the owner can do to repair it.

A reply produced without access to a required source is marked as completed with limitations rather than presented as fully complete.

After three consecutive failed runs, Hyper moves the automation into Needs attention and stops scheduling more occurrences. The owner can repair the underlying problem and resume it. Missed occurrences do not count as failures because no work ran. (#524)

Automations are available on iPhone

The iPhone app can now show automation proposals, lists, runs, instruction changes, approvals, and sharing choices.

Owners can choose Draft or Automatic for proposed actions, make an automation private or shared, run or pause it, repair failures, delete it with confirmation, and apply or reject instruction changes. Shared automations remain read-only for members who do not own them. (#554, #558)

GPT-6 Astra is now the default model

GPT-6 Astra is now Hyper’s default model.

New conversations use Astra automatically without requiring a settings change. Both agent paths use medium reasoning for Astra. Existing GPT models remain available, and existing model identifiers keep their previous wire values. (#566)

Claude Fable 5.1 also replaces Fable 5. Existing selections of Fable 5 continue working and now route to Fable 5.1 without requiring the user to select another model. (#468)

Eight new connectors

Hyper now connects to WhatsApp, Telegram, LangSmith, Datadog, Resend, Airtable, Todoist, and Cal.com.

Hyper can now connect to a personal WhatsApp account through a hosted QR or pairing-code flow.

The connector synchronizes the account’s existing chats and messages rather than using a separate business number. Hyper can search conversations, read messages and participants, and use supported messaging actions with approval.

WhatsApp connections and indexed conversations remain private. Reads are deliberately paced to reduce the risk of the provider restricting the connected phone number. (#440, #485)

Hyper can now connect to a personal Telegram account.

It synchronizes the account’s chats and messages, identifies people using their chosen name, username, or phone number, and supports approved actions through Telegram’s connected-account interface.

Telegram uses the same account-bound execution boundary as WhatsApp. A request prepared for one connector cannot be executed against an account from the other connector. (#447, #485)

LangSmith

Hyper can now connect to a LangSmith workspace through OAuth.

The connector can work with LangSmith runs, thread history, prompts, datasets, examples, experiments, engine issues, and usage information. Sandbox operations remain separately approval-gated because their effect depends on the command or action provided at runtime.

The connection is bound to the workspace selected during authorization, and renewal verifies that the token still belongs to that workspace. (#450)

Datadog

Hyper can now connect to Datadog and use its remote Model Context Protocol interface.

The connector covers Datadog’s available tools for logs, metrics, monitors, alerts, cases, error tracking, notebooks, incidents, and related operational analysis. The current exposed Datadog tool surface is read-only.

The connection is bound to the organization selected during authorization. (#454)

Resend

Hyper can now connect to Resend.

It can work with emails, broadcasts, contacts, audiences, templates, domains, API keys, webhooks, and other resources exposed by Resend’s remote interface.

Read operations can proceed normally. Sending email and changing or deleting Resend resources require per-run approval. The interface is pinned and classified operation by operation so a newly introduced write cannot silently appear as a read. (#466)

Airtable

Hyper can now connect to Airtable and work with bases, schemas, tables, records, and record comments.

It can inspect base structure, query records with fields, sorting, limits, and formulas, and perform approved record and comment actions. Airtable is an on-demand connector and does not copy bases into Hyper through background synchronization. (#534)

Todoist

Hyper can now connect to Todoist as a full read-write connector.

It supports tasks, projects, sections, labels, comments, and related task-management operations. Projects and tasks are synchronized into Hyper, while signed webhooks update individual items shortly after they change.

Create, update, complete, and delete actions remain subject to connector approval. (#535)

Cal.com

Hyper can now connect to Cal.com.

Bookings are synchronized into Hyper using incremental updates, and booking-created, rescheduled, and cancelled webhooks refresh the affected booking directly. Hyper can also use Cal.com’s supported API actions with approval.

Cal.com is available in both stable and nightly builds. (#539, #557)

Slack can send messages and search private direct messages

Hyper’s Slack connector can now perform checked message writes such as chat.postMessage.

Every Slack state change requires per-run approval for the exact method, path, and body. Hyper does not treat a general earlier approval as permission for a different Slack write. (#540)

Slack can also search and synchronize private direct messages. Direct messages remain private inside Hyper rather than becoming shared workspace information.

Existing Slack connections may need to reconnect to grant the additional direct-message scopes.

Connector synchronization is significantly faster

This release completes the move of connector synchronization onto one shared system.

Instead of repeatedly crawling an entire account, supported connectors now use the provider’s change feed, modification watermark, webhook, or item reference to read only what changed.

The new incremental paths include:

Gmail mailbox history and Google Drive change feeds. (#456)
Notion and Confluence modification watermarks. (#459)
Jira and GitHub update filters. (#463)
Slack history windows. (#464)
Attio webhook item reads. (#467)
Stripe event-directed reads and scheduled reconciliation. (#469)
HubSpot CRM and inbox watermarks. (#482, #484)
LinkedIn, Telegram, and WhatsApp message-window updates. (#483, #485)
PostHog insight modification times. (#488)

Scheduled incremental scans remain the correctness backbone. Webhooks lower the time between a provider change and Hyper seeing it, while periodic reconciliation catches missed deliveries and hard deletions.

Webhooks now use one verified ingress

Gmail, Google Calendar, Google Drive, Notion, GitHub, Jira, Linear, Slack, Stripe, HubSpot, Attio, LinkedIn, Telegram, and WhatsApp now route deliveries through one connector webhook system.

Each connector declares:

Which secret or unguessable lease identifies a valid delivery.
How the provider’s signature is verified.
Whether the provider expects a challenge response.
Which account or exact item changed.

Invalid deliveries are refused without revealing whether a secret, account, or route exists. Repeated events are safe because the provider notification points Hyper back to the current source of truth rather than being trusted as the final stored record. (#461, #465, #470, #471, #475, #476, #477, #486, #504)

Webhook registrations for Google, Attio, Jira, LinkedIn, Telegram, and WhatsApp also use one declared renewal engine. Registrations are renewed under a per-connection lock, with a new registration created before an old one is released. (#516)

Attio webhook signing secrets are now encrypted at rest. Existing plaintext registrations replace themselves with newly issued encrypted secrets during the normal renewal sweep. (#523)

Synchronization handles provider failures more reliably

Connector responses now preserve their status, headers, operation, bounded body, and protocol-specific signals until the connector classifies what happened.

The shared synchronization layer then decides whether to:

Retry a temporary failure.
Respect a provider’s rate limit.
Wait for the account to reconnect.
Expire an unusable checkpoint and perform a full reconciliation.
Skip an optional provider feature.
Remove an item the provider confirmed is gone.

This prevents a connector from accidentally treating a rate limit or server error as a missing item. (#444)

Model Context Protocol providers can report a rate limit inside an otherwise successful HTTP response. Granola, Krisp, and Wispr Flow now recognize those in-band refusals and back off instead of ending the sync as invalid data. (#520)

Workers now process batches of connector steps during one claim rather than waiting between every provider request. This substantially increases throughput for large Notion, Slack, PostHog, Gmail, and meeting imports while preserving connector-specific pacing.

Rate limits without an explicit retry time use escalating pauses, and server restarts avoid launching unnecessary catch-up work for recently completed connections. (#536, #561)

We also fixed production-specific failures involving Jira’s new bounded-query requirement, incomplete Notion Markdown exports, persisted Notion sync steps, and removals in Krisp and Wispr Flow. (#452, #513, #517, #518)

The old connector system has been removed

Every production connector now uses the same authorization, execution, synchronization, webhook, and lease foundations.

The complete connectors-v1 implementation has been removed, including its duplicate sync scheduler, webhook handlers, provider clients, OAuth paths, and hand-built agent tools. Stable now has one connector implementation rather than old and new systems running beside one another. (#500, #533)

Connector code is now separated into:

A shared connector library containing reviewed contracts, protocols, transports, and the execution kernel.
Provider adapters containing provider-specific API behavior.
The synchronization queue and worker pool.
The server-owned connection, credential, webhook, and lease state.

Each provider has one declaration covering its authentication, interface, execution guide, synchronization, webhooks, leases, and validation. Adding a new provider requires an explicit answer for every capability rather than updating several unrelated registries. (#510, #512)

Chat history is easier to search and navigate

The Search button and Command-K now search conversation titles and message content across the workspace. Results highlight matching words, show a relevant message excerpt, and open the selected conversation. An empty search shows recent chats. (#439)

Chats can now be added to Favorites from the conversation header or row menu. Favorites synchronize through the server and appear consistently across devices. (#480)

Desktop keyboard shortcuts now support:

Creating a new chat.
Reopening the last closed chat.
Switching between open chats.
Moving backward and forward through visited chats.

The chat core owns navigation history, so sending from the home screen, deleting a conversation, changing workspaces, and opening an in-progress chat keep the navigation stack consistent. (#451, #542, #567)

Files are easier to add and support more formats

Files can now be dragged directly into a conversation. Hyper shows an immediate pending attachment while it reads the file, then replaces it with the normal attachment once it is ready. (#455)

Hyper can also read:

Excel .xlsx workbooks, preserving separate sheets and tabular rows.
PowerPoint .pptx presentations, preserving slide order, slide text, and speaker notes.

Both formats use bounded archive extraction to limit entry counts and decompressed size before their contents reach the agent. Legacy .xls and .ppt files remain unsupported. (#448)

A file, pasted passage, or feedback comment can now be sent without typing an additional text message beside it. Hyper uses the attachment or comment itself as the user’s request context. (#449)

Feedback and navigation are more polished

Feedback comments now use the same compact chip treatment as file attachments. Writing and reading a comment opens beside the selected passage without covering it, and the highlighted text remains visible while feedback is being written. (#443, #451)

We also refined the sidebar, title bar, navigation controls, chat groups, search controls, shortcuts, themes, loading states, and compact interaction components. (#472, #567, #572)

Application state now lives in the shared Rust core and reaches the interface as revision-stamped state frames. A snapshot restores any update the frontend missed, while session generations prevent abandoned work from a previous account or workspace from replacing the current state. This addresses pages that could previously remain stuck because they missed one pushed event. (#266)

Existing conversations are more compatible

Some older Anthropic conversations contained unsigned reasoning history that newer provider APIs refuse.

Hyper now removes incompatible unsigned reasoning blocks while preserving valid signed, encrypted, and redacted reasoning. If an old assistant message contains no replayable content after repair, Hyper omits that message instead of making the entire conversation unusable. (#436)

We also upgraded Rig from 0.39 to 0.42. Existing stored messages are converted when loaded, strict tool schemas now use Rig’s native support, and old tool calls and results are paired into the shapes the current runtime expects. (#460)

Releases and connector health are easier to operate

Stable releases now come only from the protected stable branch.

The release system supports automated backports, explicit promotion pull requests, stable-branch CI, release-document validation, and rules preventing database migrations from entering a patch release accidentally. Promotion pull requests now include the complete merge, validation, and deployment procedure. (#437, #577)

Every connector sync now reports structured progress, completion, retry, and terminal failure events after the corresponding database transaction commits. A read-only CLI report combines those events with connection, job, lease, rate-limit, and configuration information to show the live health of each connector. (#499, #541)

Database-backed server and synchronization tests now run in CI against a real Supabase database. Generated TypeScript database types are also rebuilt from the migrations and checked for drift rather than being generated from a developer’s local database. (#555, #559, #568)

What this release enables

The last release made Hyper capable of doing substantially more work during a conversation. This release allows that work to continue after the conversation ends.

Automations turn recurring instructions into durable work that runs on a schedule or when new information arrives.
Confirmation cards make the automation’s instructions, accounts, sharing, and external actions explicit before it starts.
Run conversations make unattended work visible, reviewable, and easy to continue.
Approvals, action modes, retries, failure notes, and instruction versions give owners control without requiring them to supervise every step.
Workspace sharing lets a team benefit from one automation while keeping ownership and private-source warnings clear.
Eight new connectors bring personal messaging, agent observability, infrastructure monitoring, email delivery, databases, task management, and scheduling into Hyper.
Slack can now send messages and privately search direct messages.
Incremental synchronization and verified webhooks make connected information arrive faster and recover more reliably.
GPT-6 Astra gives every user the newest default model without breaking existing selections.
Search, Favorites, keyboard navigation, drag-and-drop, and Office file support make the everyday app easier to use.

Automations are one of the biggest features we have shipped. Hyper can now continue doing real work after you close the app while giving you clear control over its instructions, accounts, actions, permissions, and results.

We are continuing to expand the events that can trigger automations, the work they can complete safely, and the connectors available to every team.

If there is a connector, automation, or workflow your team needs, tell us at founders@heyhyper.ai.