DEV Community: Lightning Developer

Run OpenCode from Any Browser: The Definitive Pinggy Setup Guide

Lightning Developer — Thu, 12 Nov 2026 12:52:39 +0000

Are you tired of being tied to your desk just to use your AI coding agent? Imagine you are on a train, at a coffee shop, or using a tablet at home, and you need to check on a long-running refactor, start a new session, or continue where you left off. With Pinggy and OpenCode, you can access a full terminal on your remote machine from any browser, without setting up an SSH server, opening a port, or assigning a public IP address. This guide walks through everything you need to know, from initial setup to advanced session management, security best practices, and troubleshooting.

Why a Browser Terminal?

Developers often need to reach a powerful workstation or server from a lightweight device. Traditional solutions like SSH require the target machine to expose a port and have a public IP, which is not always possible behind NAT, CGNAT, or strict corporate firewalls. You could use a VPN, but that adds complexity and can be blocked by network administrators. Pinggy solves this problem by having your machine make a single outbound connection to the Pinggy dashboard. Your browser talks to the dashboard, and the dashboard relays keystrokes through that connection to a shell on your machine. This is a form of remote terminal that works regardless of your network topology.

The beauty of this approach is that there is no inbound connection. The Pinggy CLI, running as a background agent, keeps a persistent WebSocket connection to the Pinggy servers. When you open a terminal tab in the Pinggy dashboard, the browser sends input events to the server, which forwards them over the existing connection to a pseudo-terminal on your machine. The output is streamed back in real time. The result is a responsive terminal in your browser that feels local, even across continents.

For developers working with AI coding agents, this is particularly useful. AI tools like OpenCode often run long tasks, generate large files, and need to execute tests. You do not want to keep a laptop lid open and a terminal session active just to watch a progress bar. With a browser terminal, you can start a task, close the tab, and check back later. The process continues because it is running on your remote machine, not in the browser.

How Pinggy Devices Work

Pinggy Devices is a feature that arrived in Pinggy CLI v0.6.2 on November 2, 2026. The CLI runs on your machine as an agent and maintains one outbound connection to the dashboard. That connection is authenticated with a device token, which is bound to your Pinggy account. When you open a browser terminal, the Pinggy front end communicates with the agent through a relay that is similar to a WebSocket bridge. The agent accepts the connection and spawns a shell process (usually /bin/bash or /bin/zsh) on the host operating system.

The system is designed to work behind NAT and CGNAT because the agent only initiates outbound connections. There is no need to configure port forwarding on your router. The agent periodically sends keepalive pings to detect dropped connections. If your internet goes offline and comes back, the agent should reconnect automatically, unless the network change is too severe or the machine goes to sleep.

Since v0.6.4, released on November 5, the agent runs in the background by default. This is a significant improvement because it means you can close the terminal window that launched the agent, and the device remains online. The background agent is managed as a user-level daemon, so it does not require administrator privileges. It stores its configuration in your user configuration directory, typically ~/.config/pinggy/ on Linux and macOS, or %USERPROFILE%\.config\pinggy\ on Windows.

The device token is stored in device.json within that directory. Permissions are set to read-only for the current user, preventing other local accounts from stealing the token. The agent never logs the actual keystrokes or terminal content. Instead, it forwards the rendered output to the dashboard, which means the dashboard cannot inject commands or extract data from the terminal. It is a pure remote display protocol, similar to how a VNC client works but optimized for text.

Understanding OpenCode's Client-Server Model

OpenCode 2 is not just a single binary that runs in the foreground. It is split into a client and a server. The opencode command you type is a terminal client that connects to a background server. This server, which starts automatically when you first run OpenCode, is responsible for managing sessions, permissions, and tool execution. It listens on 127.0.0.1:49374 on macOS and Linux. This design is what makes OpenCode an ideal companion for a browser terminal.

When you open a shell through Pinggy and run opencode, the client attaches to the existing background server. If your browser tab crashes, the shell might be terminated, but the server stays alive. Your active session continues running in the background. You can later open a new shell, resume the session, and see exactly where you left off. This separation is powerful, especially for long-running AI code generation tasks that might take several minutes. You can even close the browser entirely and come back hours later to find the task completed.

The background server also centralizes permissions. When OpenCode wants to run a command or modify a file, it asks the user through the TUI. But when you are running in a browser terminal, you interact with the TUI as usual. The server enforces the same permission rules even if the client disconnects and reconnects. This means a long-running task will not accidentally execute a command that you did not approve. You can also revoke permissions through the TUI before disconnecting.

OpenCode is MIT-licensed and has gathered an impressive 225,629 GitHub stars as of November 9, 2026. The project has rapidly evolved, and v2 introduced a more robust plugin system and a new TUI. The background server model was added specifically to support scenarios like this, where the client and server can be separated across time and space.

In my test run on November 9, I used an Apple Silicon MacBook with Pinggy CLI 0.6.4 and OpenCode 2.2.6, released on November 6. I added the machine using the dashboard's token command. Most screenshots in this guide come from that run, and a few were taken on November 10 in the dashboard's dark theme. Two images come from our Claude Code guide. All tokens, emails, hostnames, and usernames are placeholder values. Plan numbers and limits were checked against the Pinggy Devices documentation.

Prerequisites

Before we dive into the setup, let us make sure you have everything needed. You need a machine where your code lives. This could be a MacBook, a Linux server, a Windows PC, or even a Raspberry Pi. The Pinggy CLI supports all of these platforms. You also need a modern web browser, such as Chrome, Firefox, Safari, or Edge. Finally, you need an OpenCode installation. The setup process takes about five minutes, and most of it is just running two install scripts and signing in with your email.

Network requirements are minimal. The machine must be able to reach the internet and maintain an outbound connection to the Pinggy servers. The browser, likewise, needs internet access and a WebSocket-capable connection. There is no need for a static IP, router configuration, or VPN. This is one of the biggest advantages of using Pinggy instead of traditional remote access tools.

You should also have a Pinggy account, which you can create for free during the sign-in process. If you plan to use OpenCode with custom AI providers, make sure you have your API keys ready. For local models, you need a tool like Ollama installed on the machine.

Step 1: Install Pinggy CLI and Sign In

The first step is to install the Pinggy CLI on the machine you want to reach from the browser. This is a simple one-liner. On macOS and Linux, open a terminal and run:

curl -fsSL https://pinggy.io/install.sh | sh

On Windows, open PowerShell and run:

irm https://pinggy.io/install.ps1 | iex

The install script does not require sudo. It downloads the CLI, places it in your user directory, and then runs the login flow. You will be prompted to enter your email address, after which Pinggy sends a six-digit verification code. Type that code into the terminal. Alternatively, you can click the "Approve sign in" button in the email, but only if the page displays the same device code that your terminal printed. This prevents phishing and ensures the request is legitimate.

A quick note on typo awareness: some users recieve the code in their spam folder, so check there if you do not see it within a minute. The code expires after a short window, and you can request a new one if needed.

If you do not have a Pinggy account, the email address you provide automatically creates a free account. The machine is then added to your account with a device name that matches its hostname. You can change this name later from the dashboard. The device entry shows the hostname, OS, CPU, and memory, which helps you identify the machine when you have multiple devices.

After successful sign-in, the CLI prints a link and a QR code to the device's page in the dashboard. Starting with CLI version 0.6.4, the agent runs in the background by default. This means the CLI process exits but the agent continues running, maintaining the outbound connection. You can close the terminal window and the device stays online. After a reboot, the agent does not start automatically. You will need to run pinggy device connect again. Since your token is saved, it will not ask for credentials again. If you have an older CLI version, the agent might run in the foreground. Simply run the install script again to update.

If you already have a Pinggy account and want to add a new machine, go to the Devices page in the dashboard and click "Add device." Give the machine a name. The dashboard will show a command that includes a unique device token. You can run this command directly on the machine. This method does not require email or a verification code, which makes it perfect for servers or machines that you only reach through a script. The exact command looks like this, with a placeholder token:

pinggy device connect --token YOUR_DEVICE_TOKEN

On a machine that already has the CLI installed, this command will connect immediately. It might also check for updates and inform you if a newer version is available. If the machine was already registered as a device on another account, the CLI will say so and leave the old device in the other dashboard, offline. You can remove the old device from the previous account if you have access to it.

One common question is whether you can run the agent alongside another Pinggy tunnel. The answer is yes, they are independent features. You can have an existing localhost tunnel active while the device agent runs in the background. The device agent uses a different authentication flow and does not interfere with your tunnel configuration.

Step 2: Install OpenCode on the Machine

Now that your device is connected to Pinggy, you need to install OpenCode. You have two options: run the install command in a local terminal on the machine, or wait until you have opened a browser shell in Step 3 and run it there. The latter is particularly useful if you want to set up a new machine completely from your tablet or phone.

The easiest installation method is the official installer. Run this in your terminal:

curl -fsSL https://opencode.ai/v2/install | bash

This installs the OpenCode 2 binary. If you already have OpenCode 1 installed, the v2 installer will replace the old binary. That is exactly what happened on my MacBook, where version 1.3.10 was replaced by OpenCode 2.2.6. If you installed OpenCode 1 through a package manager, it is recommended to uninstall it first to avoid conflicts. The v2 installer preserves your existing configuration, including your default model. However, v1 plugins do not run in OpenCode 2, so you may need to find replacements.

Alternative installation methods include:

npm install -g @opencode/cli

and, on macOS with Homebrew, you can run:

brew install anomalyco/tap/opencode-v2

Both methods work well. The npm package is particularly convenient if you already have Node.js installed, but the standalone installer is more self-contained. Windows package managers are not yet supported. Instead, the OpenCode documentation provides a standalone Windows build that you can download and run. OpenCode 1 also works in the browser terminal. If you still have a v1 installation and want to keep it, that is fine. In fact, here is what OpenCode 1.3.10 looked like in the Pinggy terminal tab, running with a local Ollama model:

However, the rest of this guide focuses on OpenCode 2 because its background server architecture provides seamless session persistence. For the best remote experience, I highly recommend upgrading to v2. If you need to migrate, copy any custom configuration from ~/.config/opencode/ to the new location that v2 uses. The installer usually handles this, but it is good to verify.

One of the first questions people ask is whether they need an account to use OpenCode. You do not. The free tier includes access to several free models, such as Big Pickle, DeepSeek V4.1 Flash Free, and GLM-5.3-Flash Free. You can start coding immediately with these models. That said, OpenCode stores your data when you use free models. If you are working with proprietary or sensitive code, connect your own provider. Use the /connect command inside the OpenCode TUI, or run opencode auth login from the shell. API keys can be pasted easily into the browser terminal. For providers that use OAuth or browser-based sign-in, it is a good idea to authenticate while you are still at the machine, before you start relying on remote sessions.

Step 3: Open the Browser Terminal and Run OpenCode

With both Pinggy and OpenCode installed, it is time to open the terminal in your browser. Go to the Pinggy Devices page and click on your device's name. The Overview tab shows whether the device is online, along with its hostname, operating system, CPU, and memory. The screenshot below shows the dark theme of the dashboard, which is easy on the eyes for late-night coding sessions.

Click the Terminal tab and then click "New shell." A new terminal tab will open, connected directly to a shell on your machine. This shell runs as the same user that ran the pinggy command. That means it has access to your user's files, git configuration, and saved provider logins. This is critical because OpenCode needs to see your SSH keys, your project directories, and your API tokens.

Once the shell is up, navigate to your project and start OpenCode:

cd ~/code/storefront   # your own project folder
opencode

The first time you run OpenCode 2.2.6 after an update, it may show a "What's new" dialog. You can close it by pressing Esc. In my case, OpenCode opened on the local Ollama model from my existing configuration. I wanted to use Big Pickle, so I pressed Ctrl+X, then M, typed "big pickle" and pressed Enter. The Ctrl+X key sequence went through the browser terminal without any issues.

Then I asked OpenCode to write a test file, specifically "Write cart.test.js with three node:test tests for cart.js." Big Pickle wrote the file and ran the tests in 11.3 seconds. The latency was barely noticeable, even though the browser tab was communicating through the Pinggy relay. The entire experience felt just like a local terminal.

Once you are inside OpenCode, the usual keybinding s work. Here are a few commands to help you get started:

/models to switch models. This opens an interactive picker where you can browse all available models, including local ones.
/connect to add a provider. You can enter an API key or choose an OAuth provider.
! at the start of an empty prompt to run a shell command directly. This is handy for quick file checks.
Ctrl+P to open the command palette. From there, you can run actions like session list, continue, or toggle permissions.

You can also use Ctrl+X and then M to select a model, as I did. The browser terminal supports all standard terminal key combinations, including Ctrl+C to interrupt, Ctrl+L to clear, and Ctrl+R to search shell history.

One tip: if you are using an iPad or tablet, make sure you have a keyboard connected. The browser terminal works with touch, but the AI coding TUI is much easier with a physical keyboard.

Step 4: Resume Sessions Later

One of the best parts of this setup is that closing the browser tab does not kill your shell. The Terminal tab in the Pinggy dashboard lists all shells that are still running on the device. Each shell has its own tab, and the list shows the program currently running in each. Clicking on a shell reopens it with the screen redrawn. This is incredibly useful when you accidentally close a tab or need to switch devices.

There is, however, a timeout limit. A dashboard shell will end after 30 minutes with no activity, and it will definitely end after 8 hours, regardless of activity. When the shell ends, the OpenCode client running inside it also ends. But because OpenCode's background server holds the session, you can simply open a new shell and resume.

To test this, I deliberately hung up the shell from the machine's side, which is exactly what a timeout does. The OpenCode client exited, but the session was still alive. In a new shell, I ran:

cd ~/code/storefront     # sessions belong to a project folder
opencode session list    # list sessions; it opens in a pager, press q to leave
opencode -c              # continue the last session

The output of session list looked like this:

ses_e40039520ffev5jRWwjsz0uEAl  Three node:test tests for cart.js       11/9/2026, 4:36:04 PM

Then opencode -c opened the session exactly where I had left off. You can also open a specific session by ID with opencode -s . Inside the TUI, /sessions (or Ctrl+X, then L) lists all sessions as well.

What about work in progress? I ran an experiment. In a local terminal, I killed the opencode client eight seconds into a task, using the same hang-up signal that a closing shell would send. The background server kept running, and the file that OpenCode was writing appeared about 16 seconds later, with no client attached. This means you can start a long task, close the browser, go for a walk, and come back later to see the result. As long as the machine stays awake and connected, the task will complete.

There is a subtle edge case. If the shell times out due to inactivity, the OpenCode client receives a SIGHUP. The client might not have time to flush its output buffer, but the background server handles all file writes and tool executions. Therefore, you will not lose any generated files. The only thing you lose is the in-memory UI state, which includes the scrollback and any unsubmitted prompt. The session history is preserved on disk.

Another useful feature is the ability to run multiple shells simultaneously. With the Pro plan, you can have up to three shells per device. For example, you can run OpenCode in one shell, a dev server in another, and tail logs in a third. Each shell is an independent process group, so commands do not interfere with each other.

Advanced Session Management

OpenCode's session system is more powerful than it first appears. Sessions are tied to a project folder. If you run opencode in a subdirectory, it will still find sessions from the parent folder. You can use session IDs to programmatically continue a session, which is useful for scripts and automation. For example, you can write a shell alias:

alias oc='cd ~/code/storefront && opencode -c'

This makes it quick to resume your last session from any shell. You can also archive old sessions to keep the list clean. The /sessions command has an archive option.

One recurring issue is that sessions can become orphaned if the server crashes. The server stores session metadata and file changes incrementally, so you rarely lose data. If you ever need to kill a hung session, you can restart the OpenCode server with opencode service restart. This will not delete sessions.

Setting Up Local Models with Ollama

One of the best ways to get low-latency AI assistance in a remote terminal is to run a local model. Ollama is a popular tool for running open-source language models on your own hardware. To install Ollama on the remote machine, use the install script:

curl -fsSL https://ollama.com/install.sh | sh

Once installed, pull a model such as qwen2.5-coder:14b or llama3.1:8b:

ollama pull qwen2.5-coder:14b

Then start the Ollama server. It runs as a background service by default. In OpenCode, you can select Ollama as the provider and pick the model you pulled. The interaction happens over the localhost server, so even the browser terminal will see negligible latency. This setup is particularly useful when you are using a remote machine with a powerful GPU. You can leave the GPU at home and use a thin client elsewhere. However, make sure the model fits in memory. The qwen2.5-coder:14b model needs about 10 GB of RAM. If the machine has 16 GB or more, you are fine.

Ollama also supports multiple models and can switch on demand. You can use /models inside OpenCode to list them. The first request will load the model into memory, which might take a few seconds. Subsequent requests are fast. If you notice slow performance, check the CPU and memory usage with htop.

Running the Pinggy Agent as a Service

If you want the Pinggy device to be always available, especially on a server, you should run the agent as a service. On Linux, you can create a systemd user unit. First, make sure the agent is not already running. Then create the unit file:

mkdir -p ~/.config/systemd/user
cat > ~/.config/systemd/user/pinggy-device.service <<EOF
[Unit]
Description=Pinggy Device Agent
After=network-online.target
Wants=network-online.target

[Service]
ExecStart=%h/.pinggy/pinggy device connect --foreground
Restart=on-failure
RestartSec=5

[Install]
WantedBy=default.target
EOF

Then enable and start it:

systemctl --user daemon-reload
systemctl --user enable --now pinggy-device.service

Make sure lingering is enabled for your user so the service starts at boot without you logging in:

loginctl enable-linger $(whoami)

This setup ensures that the Pinggy agent is always running and reconnects automatically after a crash or reboot. On macOS, you can do something similar with a launchd LaunchAgent. On Windows, use Task Scheduler.

OpenCode Configuration Tips

OpenCode stores its configuration in ~/.config/opencode/. You can edit the opencode.json file to set default models, theme, and permission policies. For example, to set a default provider and model:

{
  "model": "big-pickle",
  "provider": "opencode"
}

You can also define custom prompts and agent behaviors in a prompts/ directory. This is helpful when you have recurring tasks, such as "create a commit message" or "write unit tests." The configuration files are plain text, so you can version them with git. If you are using OpenCode through a browser terminal, you might want to increase the terminal font size for readability. You can do that in the TUI settings.

Permission policies are particularly important in a remote environment. You can configure OpenCode to ask for permission only once per session, or to auto-approve certain commands like npm test and git status. This reduces the number of interruptions while you are away from the keyboard.

OpenCode's Own Remote Access, and Why a Shell

OpenCode has its own remote access feature. The command opencode pair prints a one-time link and a QR code to its web UI. This link is valid for 5 minutes. With opencode pair --remote, you can pair from anywhere through an OpenTunnel address. This option exposes your OpenCode server to the internet. It is end-to-end encrypted and protected by a password, and OpenCode asks for confirmation before turning it on. On a phone, the OpenCode web UI or mobile app is arguably nicer than a TUI in a browser tab. If you only need to interact with OpenCode, this might be enough.

But a Pinggy shell is a whole terminal, not just an OpenCode session. You can restart the OpenCode service, run git pull, restart a dev server, or even run Claude Code in a seperate tab. Nothing about the OpenCode server is exposed to the internet. The shell is just a terminal. This is especially valuable if you want to inspect system logs, edit configuration files, or perform maintenance tasks in the same environment. Our Claude Code guide covers the same setup for Claude Code, and you can run both tools side by side. The screenshot below shows Claude Code 2.1.318 running in the same Pinggy terminal tab, from the Claude Code guide.

Having a full terminal also means you can use tools like htop, vim, tmux, or any other command-line utility. You can start a local web server and test it by opening another tunnel. The possibilities are endless. If you are a sysadmin, you can even use the browser terminal to manage nginx configuraton files, restart services, and read logs, all without leaving the browser.

Free vs Pro

The browser terminal is available on every Pinggy plan, including the free one. The free plan includes one device and one concurrent shell. That is enough for a single developer with one machine. The Pro plan costs $2.50 per month if billed annually, or $3 per month if billed monthly, as of November 3, 2026. It raises the limits to 25 devices, three concurrent shells per device, and ten open shells per seat. Three shells is a comfortable number for most workflows: one for OpenCode, one for the dev server, and one for git operations. For a more detailed breakdown, check the Pinggy pricing page.

If you are collaborating with a small team, each seat gets its own device and shell limits. You can also share devices across the team if you all sign in to the same account, though that raises security concerns that we will address shortly. The Pro plan also includes priority support and higher bandwidth limits. If you are using the browser terminal for heavy output, such as test suites that print thousands of lines, you will appreciate the increased throughput.

One thing to note is that the free plan's single shell can be a limitation if you want to run OpenCode and a dev server concurrently. You can work around this by using tmux inside the single shell, but the Pro plan's three shells are more ergonomic. You can always upgrade or downgrade at any time, and the pricing is transparent.

Security Best Practices

When you give remote access to your development environment, security becomes paramount. The device token is stored in a file called device.json under ~/.config/pinggy/. The file is readable only by your user account. Pinggy documents that the agent never logs what you type. The Activity tab in the dashboard lists device events, including source IP addresses, so you can monitor for suspicious access.

Here is the important part: anyone who is signed in to your Pinggy account can open a shell on your devices. And since the shell runs as your user, that person has access to your source code, your provider keys, and your entire user environment. Therefore, you must enable two-factor authentication (2FA) on your Pinggy account immediately. Do not share screenshots of the dashboard's connect commands, because they contain the device token. Treat those tokens like SSH private keys.

If you need to revoke access, you have two options. You can delete the device from the dashboard, which severs the connection and prevents it from connecting again with the old token. Or you can rotate the device's token from the dashboard. The local pinggy device remove command only forgets the token on your machine; it does not revoke it remotely. Make sure you understand the difference.

For an extra layer of security, consider using a dedicated service account for background agents, or limit the permissions of the user that runs the Pinggy CLI. On Linux, you can use systemd to run the agent under a separate user with limited access. On macOS, you might want to use the built-in firewall and app sandboxing. If you are working with highly sensitive code, you can also combine Pinggy with your own authentication proxy, but that is probably overkill for most developers.

Another good practice is to set a short screen lock timeout on the machine that runs the agent. If an attacker gains physical access to the machine, they could read the device token and use it to access your Pinggy account. Full disk encryption is also recommended. The agent itself does not store any plaintext credentials beyond the device token and your shell environment variables.

Troubleshooting

Even with a smooth setup, you might encounter issues. Here are some common problems and how to resolve them.

Terminal tab is greyed out

The most likely cause is that the Pinggy CLI on your machine is too old to support the browser terminal. The terminal tab becomes available in CLI version 0.6.2. If you have an older version, run the install command again to update the CLI. The command is the same one you used for installation.

This machine already runs as device in the background

If you try to run pinggy device login or pinggy device connect --foreground while a background agent is already running, you will see this message. Stop the background agent first with pinggy device stop. Then you can run the foreground command. This is a common mistake when you are testing multiple authentication methods. The background agent already holds the connection, so the foreground command cannot establish a second one.

opencode -c shows an error about "ses"

When you run opencode -c in a folder that has no OpenCode sessions, you might see an error like Expected a string starting with "ses" followed by an empty session. This happens because you are in the wrong directory. In a fresh browser shell, you start in your home directory, not in your project folder. You need to cd into the project folder first. Alternatively, open a session by its ID with opencode -s .

OpenCode can't reach its server

If the OpenCode client cannot connect to the background server, you will see a connection error. Run opencode service status to check the server's state. If it is stuck, use opencode service restart. This usually resolves the issue. If the server is not running at all, starting a new opencode command should launch it automatically. Sometimes the server's port, 127.0.0.1:49374, is occupied by a different process. You can check with lsof or netstat.

Input lag or slow key response

The browser terminal should feel snappy, but if you notice latency, check your network connection. The Pinggy relay is optimized for low-latency, but a poor internet connection on either end can cause delays. You can also try using a wired connection on the machine side, or switching browsers. Some browser extensions might interfere with WebSocket connections, so try disabling them temporarily.

Clipboard issues

Copying and pasting large amounts of text between your local machine and the browser terminal can sometimes be flaky. Use the terminal's own copy and paste shortcuts. In most browser terminals, Ctrl+Shift+C and Ctrl+Shift+V work. For very large pastes, consider echoing the text into a file first. If you are using a Mac, Cmd+C and Cmd+V may work instead.

The machine goes offline unexpectedly

If the device shows as offline in the dashboard, the agent might have crashed or the network connection was lost. Check if the machine is awake and has internet access. You can restart the agent by running pinggy device connect again. If the machine rebooted, the agent will not start automatically, so you need to launch it manually.

Permission denied when running opencode

The shell user may not have execute permission for the OpenCode binary, or the binary may be in a directory that is not in the PATH for the shell that Pinggy starts. Use an absolute path like ~/.opencode/bin/opencode or add the directory to your shell profile. You can also reinstall OpenCode with the official installer, which handles PATH configuration.

"Device code" mismatch

During login, the email shows a device code that should match the code displayed in your terminal. If they do not match, do not approve the access. This is a safeguard against session hijacking. The code changes on every attempt.

Performance and Reliability

The Pinggy agent maintains a single outbound connection, which is remarkably stable. In my tests, it survived network changes and sleeps on the laptop, though a reboot will obviously disconnect. The connection uses TLS, so all data is encrypted in transit. The relay servers are distributed, but the latency depends on the physical distance between your browser, the Pinggy relay, and your target machine. For most development tasks, the latency is negligible.

To get the best performance, close unnecessary browser tabs and keep your machine awake. On macOS, use caffeinate if you want to prevent sleep during a long task. On Linux, you can adjust the power settings. You might also want to use a tool like tmux inside the shell to create persistent sessions that survive shell disconnects. Although OpenCode's server provides session persistence, tmux gives you a more general solution for any process.

Network quality matters. If you are on a cellular connection, you may experience occasional jitter. The terminal protocol is text-based, so the bandwidth usage is low, but packet loss can cause lag. Try to maintain a stable Wi-Fi or Ethernet connection on both sides. If the machine is in a region with high latency, you can still use OpenCode comfortably, but the initial render of a large scrollback might take a second or two.

Another performance factor is the model you choose. Local models running on the machine, like those served by Ollama, do not depend on internet speed and can be very fast. Cloud models, on the other hand, require streaming iterations over the internet, and the browser terminal adds a tiny overhead. In practice, the overhead is less than 10%, which is not noticeable.

Real-World Use Cases

The combination of Pinggy and OpenCode is perfect for several scenarios.

Road warrior developer: You are working from a tablet or a borrowed laptop. You connect to your powerful desktop at home and run OpenCode exactly as if you were sitting in front of it.
Server maintenance and AI assistance: You have a headless server that hosts your application. You can run OpenCode on the server to refactor code, inspect logs, and run tests, all from a browser.
Temporary workstations: You are at a client site and need to access a development environment behind their strict firewall. The client machine initiates the outbound connection, so no firewall changes are required.
Pair programming across locations: Two developers can sign in to the same Pinggy account and open separate shells on the same device. They can even run tmux and attach to the same session for collaborative debugging.
Cost efficiency: Instead of carrying a heavy laptop around, you can use a thin client or a Chromebook and offload all computation to your main machine.

Let me give you a concrete example. I often leave my MacBook Pro at home, plugged into a dock with multiple monitors. When I am traveling, I use an iPad Pro with a keyboard. I open the Pinggy dashboard, start a terminal shell, and run opencode. The iPad is now a full development environment. I can also use the local Ollama model to avoid sending code to third-party servers, which is useful for confidential projects.

For teams, the ability to access shared servers remotely from a browser can reduce the need for VPNs. A QA engineer can open a shell on the staging server and run OpenCode to debug an issue, while a backend developer is simultaneously connected to the same device through another shell. This is much simpler than coordinating SSH keys and jump hosts.

Comparing with Alternative Remote Dev Tools

There are other ways to access a remote terminal, such as SSH with port forwarding, VS Code Remote, or tools like ngrok. SSH is secure and reliable, but it requires the target machine to be reachable, which is often not the case behind CGNAT. VS Code Remote is excellent for editor integrations, but it is heavier and still requires a tunnel for clients. Pinggy provides a lightweight, browser-based terminal that works everywhere and does not require agent installation on the client, only on the host. It does not offer a full IDE, but for a terminal-based AI coding tool like OpenCode, that is all you need.

OpenTunnel, mentioned earlier, is great for exposing a specific service to the internet, but it exposes the service itself. With Pinggy, you are not exposing any service; you are exposing a login-protected terminal endpoint. This is a fundamental difference.

We should also mention that Pinggy supports SSH access through a different feature. If you prefer a native SSH terminal, you can configure Pinggy to provide an SSH host. However, for browser-based access, the Devices terminal is the simplest.

Common Pitfalls and How to Avoid Them

Even experienced developers can stumble when setting up a remote terminal. Below are some mistakes I have seen, and how to avoid them.

Forgetting to update the CLI: The browser terminal feature is relatively new. Always use the latest Pinggy CLI to get the most up-to-date features and security fixes. Re-run the install script periodically.
Using the wrong shell: The dashboard terminal spawns the user's default shell. If you have customized your shell with a startup script that expects a TTY or specific environment variables, make sure the script does not hang. Some shell profiles display messages that can confuse the terminal emulator. Keep your profile scripts robust.
Assuming the background agent starts after reboot: It does not. You must add it to your startup items if you want it to persist. On macOS, you can use launchd. On Windows, use Task Scheduler. On Linux, use systemd user units.
Running heavy AI tasks on a weak machine: The browser terminal is just a front end. The actual AI processing happens on the remote machine. Make sure that machine has enough CPU, memory, and GPU resources. Otherwise, tasks will be slow even with a fast connection.
Not securing your provider API keys: If you connect a provider and save the API key in OpenCode's config, anyone with access to your Pinggy shell can use it. Limit the damages by using short-lived keys or a dedicated billing account.

Frequently Asked Questions

Do I need to keep the Pinggy CLI running in the foreground?

No, starting from version 0.6.4, the agent runs in the background by default. It will persist until the machine reboots. If you want to stop it, use Pinggy device stop.

Can I use the free plan for this?

Yes, the free plan includes one device and one shell. That is sufficient to run OpenCode and do meaningful work. If you need multiple shells or more devices, consider upgrading to Pro.

Does OpenCode 2 work with all of my existing plugins?

No, v1 plugins are not compatible with v2. You will need to migrate them or find alternatives. The core functionality, including model selection and tool execution, is built-in.

Can I run OpenCode on a Windows machine?

Yes, OpenCode has a standalone Windows build. The Pinggy CLI also works on Windows through PowerShell. The browser terminal works exactly the same way. The background server listens on a local port, and the client connects as usual.

Is it safe to leave the browser terminal tab open?

It is as safe as any terminal session. However, you should always lock your screen when away from your device, and enable 2FA on your Pinggy account. The terminal shell has full access to your user account, so treat it with the same caution as a local terminal.

What if my machine goes to sleep?

If the machine goes to sleep, the Pinggy agent will disconnect. When it wakes up, it may reconnect automatically, depending on your settings. OpenCode's server should resume, but if the machine was asleep for a long time, you might need to restart the agent.

Can I use multiple Pinggy tunnels and the device agent at the same time?

Yes, the features are independent. The device agent does not interfere with localhost tunnels. You can have one terminal for OpenCode and another tunnel for your web app simultaneously.

Does the browser terminal support tmux and other GUI tools?

It supports terminal-based tools, including tmux, vim, htop, and most command-line applications. It does not render graphical X11 applications, but there is no need for that in this context.

Recap

Let us summarize the entire setup in a few commands. First, install Pinggy and sign in:

curl -fsSL https://pinggy.io/install.sh | sh

Then install OpenCode 2:

curl -fsSL https://opencode.ai/v2/install | bash

Open the Pinggy Devices page, click your device, go to the Terminal tab, and start a new shell. Then run:

cd ~/code/storefront
opencode

To resume a previous session later, use:

opencode -c

That is all there is to it. You now have a full OpenCode environment that follows you anywhere, without any port forwarding, SSH daemons, or public IP addresses. The only requirement is that your development machine stays powered on and connected to the internet.

We hope this guide helps you become more productive and flexible. Whether you are a solo developer, a remote worker, or a team lead, the ability to run AI coding tools from any browser is a game changer. If you run into problems, refer to the official documentation and leave a comment below.

Reference

Port 0: The Magic Number That Asks Everyone to Choose

Lightning Developer — Tue, 10 Nov 2026 13:44:21 +0000

Every networking developer eventually runs into a strange inconsistency. You can bind a socket to port 0 and the operation succeeds. But if you try to connect to port 0, the connection is refused. The same number appears in SSH remote forwarding commands like ssh -R0:localhost:3000 free.pinggy.io, and it somehow tells the remote server to choose a free port. Port 0 is reserved, meaning it is not supposed to exist on the wire, yet it is one of the most useful values in the entire sockets API. This post explains what port 0 actually means, why the kernel and the SSH server treat it as a request to pick a port, and how you can use this trick in real development workflows.

I ran a few small experiments on a Linux 6.18 box to see where that convention holds, where it breaks, and what it has to do with tunnels. All output shown below is real unless it says otherwise. Pinggy relies on this exact behaviour for its TCP tunnels, so understanding port 0 helps you understand how tools like this work under the hood.

Summary

Here is what you need to remember from this article:

In the sockets API, bind(0) asks the kernel for a free ephemeral port. You read the port back with getsockname(). On Linux the default pool is 32768-60999.
On the wire, port 0 is reserved. TCP has no use for it, and trying to connect to it fails. UDP has one oddity: RFC 768 lets a sender put 0 in the source port when it does not want a reply.
ssh -R0:... uses the same trick on a remote machine. The SSH protocol lets the client ask the server to pick the listening port and report it back, which is how a Pinggy TCP tunnel gets its port.
The practical rule: ask for port 0 when you do not care which port you get, then read the real port back before you tell anyone else about it.

What bind(0) Does

Binding a socket normally means listen on this exact port. Passing 0 changes the question to give me any free one. The kernel picks a port from its ephemeral range, binds the socket to it, and you ask the socket afterwards what it got.

Python shows it in four lines:

import socket

s = socket.socket()
s.bind(('127.0.0.1', 0))
print(s.getsockname())

The output on my machine was:

('127.0.0.1', 60681)

Run it again and you get a diferent number. The second socket I opened got 44627. Node.js does the same through listen(0):

const s = require('net').createServer().listen(0, '127.0.0.1', () => {
  console.log('listening on', s.address().port)
})

Output:

listening on 44909

The range comes from a sysctl. On the machine I used:

cat /proc/sys/net/ipv4/ip_local_port_range

Output:

32768   60999

That is the Linux default. IANA's suggested ephemeral range in RFC 6335 is 49152-65535, and Windows and the BSDs follow that one, so the same program lands in a different part of the port space depending on the operating system.

The port number exists only after bind returns, so the program has to read it back. Why bother? Because hard-coded ports collide. Test suites that start a server per test, CI jobs that share a runner, and two dev servers that both want 3000 all trip over each other. Letting the kernel choose means nobody collides, since the kernel will not hand out a port that is already bound.

There is a catch: the port is only free at the moment you bind. Code that picks a port with bind(0), closes the socket, and then passes the number to another process has a race. Something else can take it in between. Keep the socket open and hand the process the socket, or have the server itself listen on 0 and report the port.

Inside the kernel, bind(0) triggers the ephemeral port allocator. The allocator scans the local port range, skips ports already in use by other sockets or reserved by listening services, and returns the first available candidate. Different kernels have different allocation strategies. Linux tends to allocate ports sequentially and wrap around, which makes large scale systems predictable. FreeBSD and macOS use a random offset to make it harder for remote attackers to guess the next port. This matters for security because predictable ephemeral ports can make certain spoofing attacks easier.

Why You Can't Connect to Port 0

The sockets convention is a local trick. Port 0 is still marked reserved in the IANA registry, and TCP does not use it. If you try to connect to it, you get an instant failure:

import socket
socket.create_connection(('127.0.0.1', 0), timeout=2)

Output:

ConnectionRefusedError: [Errno 111] Connection refused

A UDP sendto() to port 0 is rejected before it leaves the machine, with EINVAL (Invalid argument) on my run. So 0 is a valid argument to bind and an invalid destination for everything else.

The nuance is the UDP source port. RFC 768 calls the source port optional: it indicates the port of the sending process, and if it is not used, a value of zero is inserted. In practice it means do not reply to me. It is legal on the wire, and some firewalls drop it anyway. The IETF mailing lists have argued for years over whether reserved means forbidden or just unassigned; one FreeBSD thread covers the firewall angle, and an Austin Group bug report covers whether POSIX should specify the bind behaviour at all. POSIX itself does not say much on this subject.

For SCTP the rule is stricter: RFC 4960 section 3.1 forbids 0 as a source or destination port.

The takeaway: nobody should be listening on port 0 and nobody should be dialing it, and no real service will recieve your packets if you do. When you see traffic to port 0 in a firewall log, it is almost always a probe or fragments that lost their port information, not a service.

At the packet level, a TCP header with source or destination port 0 is not generated by normal kernels. The TCP stack treats port 0 as an invalid destination and returns ECONNREFUSED without sending a SYN. That is why the failure is immediate. UDP is different. The kernel checks the destination port locally and rejects the sendto call with EINVAL before the packet hits the wire. Destination port 0 is therefore not a network problem, it is a local policy decision built into the protocol stack.

The Other Port 0: ssh -R0

If you have used Pinggy, you have probably typed this:

ssh -p 443 -R0:localhost:3000 free.pinggy.io

The 0 in -R0 is the remote port to listen on, and it is the same idea as bind(0). The format is -R [bind_address:]port:host:hostport, so -R0:localhost:3000 reads as listen on any free port on the server, and send what arrives to localhost:3000 on my machine.

The SSH protocol has this built in. In RFC 4254, section 7.1, the client sends a tcpip-forward request, and if the port to bind is 0 and the client asked for a reply, the server allocates the next available unprivileged port and returns it. The client then knows where the forward lives.

With a plain OpenSSH server, you can see it directly. This is OpenSSH's own behaviour, not something that is specific to Pinggy:

Allocated port 41873 for remote forward to localhost:3000

OpenSSH prints that line on stderr when the server picks the port. With a Pinggy HTTP tunnel the port is hidden behind a hostname, so you get a URL such as https://abc123.a.pinggy.link. For a TCP tunnel you get the host and port itself:

ssh -p 443 -R0:localhost:22 tcp@free.pinggy.io

Pinggy prints a tcp:// address with a port the server allocated, and that port is what a friend types into their SSH client. With -R0 the Pinggy server picks the public port and tells the client which one it got.

The key detail is that SSH does not use the TCP port 0 destination mechanism. The SSH protocol is a control protocol with its own message types. Port 0 inside the SSH request is interpreted by the SSH server as a special value, not as a network destination. This is why port 0 can mean pick one for me in SSH even though it is invalid on the wire.

When the server receives the tcpip-forward request, it begins listening on the requested interface. If the requested port is 0, it asks its own ephemeral port allocator for a free number. The server then sends a success response that contains the allocated port. The client can use that number later when it opens data channels. The same pattern appears in tools like ssh -R and in tunnelling services like Pinggy.

I could not run the two Pinggy commands from the sandbox I wrote this in, because the sandbox has no ssh client. The output of those commands is therefore untested here, but the command forms match the Pinggy documentation.

Port 0 is not limited to remote forwarding. You can also use it with -L to make the local SSH client choose a free local listening port. The client prints a message similar to the remote one. The important idea is that port 0 is a signal to the SSH machinery, not a literal port number.

Using Both Zeros in One Workflow

Here is a worked example: a Node.js dev server picks its own port, and a tunnel points at whatever port it got.

First, create server.js:

const http = require('http')
const s = http.createServer((req, res) => res.end('hello'))
s.listen(0, '127.0.0.1', () => console.log(s.address().port))

Run the server in one terminal and read the port it prints:

node server.js

Output:

Then start teh tunnel from another terminal:

ssh -p 443 -R0:localhost:44909 free.pinggy.io

Swap 44909 for the port your server printed. Two kinds of pick a port for me are now stacked: the kernel chose 44909 locally, and the Pinggy server chooses the public side. Neither number was in your config, and nothing had to be free in advance.

The main thing to watch is the local race from earlier. If you script this, have the server write the port to a file after it is listening, and start the tunnel after the file exists.

For a more robust script, server.js can write the port itself:

const http = require('http')
const fs = require('fs')
const s = http.createServer((req, res) => res.end('hello'))
s.listen(0, '127.0.0.1', () => {
  fs.writeFileSync('port.txt', String(s.address().port))
})

Then the shell script can wait for the file:

node server.js &
until [ -s port.txt ]; do sleep 0.1; done
PORT=$(cat port.txt)
ssh -p 443 -R0:localhost:$PORT free.pinggy.io

This prevents the race because the server is already listening when the file is created. The tunnel also uses its own 0, so the public port is dynamic.

When you need a predictable public port for clients, a dynamic port can be inconvenient. Some tunnel services let you reserve a subdomain or a fixed port. Pinggy supports fixed ports on certain plans, but the free flow is designed around the zero trick.

Seeing It on Your Own Machine

Three quick checks, all of which work without root:

python3 - <<'PY'
import socket
s = socket.socket()
s.bind(('127.0.0.1', 0))
print(s.getsockname()[1])
PY

cat /proc/sys/net/ipv4/ip_local_port_range

On macOS, use:

sysctl net.inet.ip.portrange.first net.inet.ip.portrange.last

You can also inspect the ephemeral range on Linux with:

sysctl net.ipv4.ip_local_port_range

The output should match /proc/sys/net/ipv4/ip_local_port_range. Finally, to see which sockets are listening on your machine:

lsof -iTCP -sTCP:LISTEN -P -n

Run the Python snippet several times and watch the number change. Then try nc 127.0.0.1 0. The copy of netcat on my box rejected it before touching the network, printing nc: port number too small: 0, so the Python connection test above is a better way to demonstrate the failure.

Real World Patterns and Gotchas

The port 0 trick is not just an academic curiosity. It appears in many production tools and workflows.

Docker and Containers

Inside a container, listen(0) works exactly as it does on a host. The container kernel allocates an ephemeral port, and the process can read it back. However, if you publish a container port to the host, you generally need a known port for service discovery. Docker's -P flag publishes every exposed port to a random host port, which is a similar idea but not directly related to port 0. If you need a random host port with a fixed container port, you can run docker run -p 127.0.0.1::8080 ... and let Docker choose a host port.

CI Pipelines

CI systems often run multiple test jobs on the same physical machine. A test suite that binds to a fixed port can fail with EADDRINUSE when two jobs run at the same time. Using port 0 removes this class of failure. The challenge is that the test framework has to expose the chosen port. Some frameworks read it from the server object, while others require you to inspect the logs. Many load balancers and sidecars also need a predictable port, so the zero trick is most valuable in isolated environments.

Hot Reload and Dev Servers

Modern development servers can use port 0 to avoid the infamous EADDRINUSE error. The terminal prints the real port after startup. This is particularly useful when you have multiple projects open at the same time and you do not want to remember which port belongs to which project.

Ephemeral Port Exhaustion

Every time you bind to 0, you consume one entry from the ephemeral port range. If you do this many times without closing sockets, you can exhaust the available pool. This can happen in test suites that create thousands of sockets in a short time. On Linux, the default range contains roughly 28,000 ports. A busy server that also makes outbound connections shares the same pool. Use ss -s or netstat -s to monitor socket usage and port allocation. If you see failures like EADDRNOTAVAIL, you may have run out of ephemeral ports.

Firewalls and Security

Dynamic ports make firewall rules harder to write. If you know that a service always listens on port 3000, you can allow TCP 3000 in your security group. With port 0, you have no fixed port to allow, so you must either allow a wide range or use a service mesh that handles registration. For SSH tunnels, the remote side picks the port, which is fine for temporary sharing but impractical for a production API endpoint. A tunnel service like Pinggy manages the public port for you, so you do not need to update firewall rules on your laptop.

IPv6

The zero trick works with IPv6 as well. You can bind a socket to [::1]:0 and the kernel selects a port from the same ephemeral range. The address family does not change the semantics of port 0. The same ss or netstat commands will show the assigned port.

Orchestrators and Kubernetes

Kubernetes and other orchestrators usually do not allow port 0 in container port definitions. The port is part of the pod spec and must be a valid integer between 1 and 65535. A process inside the container can still bind to port 0 and later register itself with a service discovery agent, but the container port metadata cannot say 0. This can be a source of confusion when moving from a local test with port 0 to a deployment manifest.

Port 0 Across Languages

The port 0 convention is part of the sockets API, so every language that exposes sockets supports it. Here are a few examples.

Go

In Go, net.Listen accepts port 0 and the listener address contains the assigned port:

package main

import "net"

func main() {
    ln, _ := net.Listen("tcp", "127.0.0.1:0")
    println(ln.Addr().(*net.TCPAddr).Port)
}

Ruby

Ruby uses TCPServer.new with port 0:

require 'socket'
server = TCPServer.new('127.0.0.1', 0)
port = server.addr[1]
puts port

Rust

In Rust, you call local_addr to discover the port:

use std::net::TcpListener;

fn main() {
    let listener = TcpListener::bind("127.0.0.1:0").unwrap();
    println!("{}", listener.local_addr().unwrap().port());
}

All of these use the same kernel feature. The language does not change the meaning of port 0; it only changes how you read the assigned port.

Port 0 in Web Frameworks

The same idea applies to high level web frameworks. Express in Node.js accepts 0 as the port parameter:

const app = require('express')()
app.get('/', (req, res) => res.send('hello'))
const server = app.listen(0, () => {
  console.log(server.address().port)
})

In Python, the standard library http.server can run on port 0 if you create the server object directly:

from http.server import HTTPServer, BaseHTTPRequestHandler
import socket

class Handler(BaseHTTPRequestHandler):
    def do_GET(self):
        self.send_response(200)
        self.end_headers()
        self.wfile.write(b'hello')

httpd = HTTPServer(('127.0.0.1', 0), Handler)
print(httpd.server_address[1])
httpd.handle_request()

The kernel assigns the port only after the server socket is created. The framework hands you the address object so you can discover the port.

Common Misunderstandings About Port 0

There are several confusing ideas about port 0 that show up in developer discussions.

Port 0 Means Disabled

Some configuration files use port 0 to mean do not listen. That is an application-level convention. In the sockets API, port 0 always means kernel, choose. A server program may treat 0 differently from the raw socket API, so check the documentation before assuming.

Port 0 Is a Wildcard

In bind(), port 0 is not a wildcard. The wildcard address is 0.0.0.0 for IPv4 and :: for IPv6. Port 0 is a request to allocate a concrete port. After the call, the port is no longer zero.

Port 0 Can Be Connected To

Some developers think that if a process binds to port 0, another process can connect to port 0 and reach it. That is false. The bound socket has a real ephemeral port, not port 0. A connection to port 0 is invalid and will fail before it reaches any listener.

Port 0 Is a Secret Port

Port 0 is reserved, not secret. If someone tells you to connect to port 0, they are probably talking about a dynamic port that needs to be discovered. Do not hard-code it.

Troubleshooting and Common Questions

Why does bind(0) return the same port twice?

If you close the first socket and then bind a second one immediately, the kernel may reuse the same port because it is the first free port in the sequence. This is not a bug. The kernel has no memory that you do not want the same number twice.

Can I put port 0 in a URL?

No. A URL like http://localhost:0/ is invalid for practical purposes. Browsers ignore the port or reject it. Port numbers in URLs must be between 1 and 65535.

Does port 0 work with UDP servers?

Yes. You can call bind() on a UDP socket with port 0 if you want the kernel to pick a source port. This is useful for clients that need a unique source port. The server will see a nonzero source port in the packet header after the kernel replaces the 0.

What happens if a TCP SYN arrives with destination port 0?

It should not happen. If it does, the receiving stack will almost certainly drop it. Some network monitoring tools may flag it as abnormal traffic. There is no service registered on port 0, so there is nothing to handle it.

How do I get the assigned port in a shell script?

If your server prints the port to stdout, capture the output. If it does not, write the port to a file. The file-based approach is safer because it avoids the race where the port is read before the server is listening.

Can ssh -R0 fail?

Yes. The remote SSH server must allow remote forwarding. OpenSSH's AllowTcpForwarding remote or PermitOpen settings can block it. The server may also have a restricted port range. If port 0 is not allowed, you will see an error such as remote port forwarding failed for listen port 0.

Why do some packets show source port 0 in UDP?

RFC 768 permits a sender to use source port 0 when a reply is not wanted. This happens in some network boot and discovery protocols. Many firewalls treat source port 0 as suspicious and drop the packet.

Is there a way to avoid the race when using bind(0)?

The safest approach is to keep the listening socket open in the same process that needs the port. If another process must know the port, pass the socket file descriptor over the process boundary using file descriptor passing. Alternatively, have the listening process write the port to a file or publish it to a service registry after the socket is bound.

Conclusion

Port 0 is not a port you use. It is a request. Locally it means kernel, choose. Remotely it means server, choose. In both cases the real number only shows up in the reply. If you write servers or test harnesses, listen(0) and a read-back cures most port clashes. If you tunnel, remember that the 0 in -R0 is why you did not have to pick a public port at all.

Understanding port 0 makes socket programming feel less magical. The reserved number is not a destination; it is a placeholder for the allocator. Once you understand that, you can read the real port back and move on with confidence.

References

Run Claude Code From Any Browser: A Pinggy Devices Guide

Lightning Developer — Mon, 09 Nov 2026 13:30:36 +0000

Access to a real terminal from any browser is one of those superpowers that sounds too good to be true. You keep your workstation or server where it is, you leave a small agent running, and then from a laptop, tablet, or even a borrowed computer you open a browser tab and get a shell on that machine. Pinggy makes this workflow simple with its Devices feature. In this guide I will show you how to combine Pinggy Devices with Claude Code so you can run AI coding sessions remotely, inspect logs, restart services, and keep long tasks alive even after you close the browser.

The core idea is straightforward. You install the Pinggy CLI on a machine, connect to the Pinggy dashboard with one outbound connection, and then use that browser dashboard to open a terminal. Once the terminal exists, you can run claude or any other command line tool you would normally use locally. There is no SSH server, no open inbound port, and no public IP address to configure. For developers who work with AI agents, this removes a whole category of network headaches.

The Problem: AI Coding Agents Are Tied to Your Machine

Claude Code and similar coding agents are command line tools. They are great when you are sitting in front of your development machine. They can read your repository, edit files, run tests, commit code, and interact with APIs using your saved credentials. But once you step away, they become unreachable. Laptops sleep, office networks block inbound traffic, home routers use NAT, and cloud VMs may be locked down with security groups. You may want to start a long refactoring task and then check on it from another room or from a different city. The default tools, SSH and remote control features, have limitations.

SSH requires a server listening on port 22, a reachable IP address, and often a number of firewall changes. If the machine is behind a hotel router, a cellular connection, or a strict corporate firewall, inbound SSH is not an option. You can use a reverse tunnel, but tunnels need to be started, monitored, and sometimes restarted. Claude Code has a Remote Control mode, but it is for attaching to an already running claude process, and it requires someone or something to start that session first. Also, depending on your account tier, Remote Control may not be available at all.

This is where the terminal in browser model shines. The machine makes one outbound connection. The browser connects to a dashboard over HTTPS. The dashboard relays keystrokes and terminal output. No inbound network configuration is needed. In the rest of this post, I will walk through the complete setup using Pinggy Devices, then run Claude Code from a browser terminal, and cover the production details that matter when you trust a remote AI agent with real work.

What Pinggy Devices Actually Is

Pinggy Devices is a feature of Pinggy that turns any machine with the Pinggy CLI into a device you can manage from the Pinggy dashboard. The feature appeared in Pinggy CLI v0.6.2 on November 2, 2026. I tested the workflow with Pinggy CLI 0.6.3 and Claude Code 2.1.318 on an Apple Silicon MacBook. The limits and pricing details mentioned in this article are from the Pinggy Devices docs and the Pinggy pricing page, checked on November 3, 2026.

Unlike a traditional tunnel, Pinggy Devices does not expose a port on the public internet by default. Instead, the CLI registers the machine with your account and keeps a persistent channel to the dashboard. From the dashboard, you can open a shell on that machine. Each shell runs as the same user who started the Pinggy agent. That is a crucial detail: if you run pinggy device connect as your normal user, the browser terminal will have your home directory, your Git configuration, your SSH keys, your environment variables, and your Claude Code login. It is effectively you sitting at the machine, just rendered through a browser.

How the Architecture Works

Let us look at the moving parts before we jump into commands. Pinggy Devices is not a magic portal into your laptop. It is a relay between a browser based terminal client and a shell process on your machine. Here is the flow:

The Pinggy CLI on your machine establishes an outbound connection to the Pinggy infrastructure.
The CLI authenticates itself with a device token, which is stored locally after the first successful connect.
The Pinggy dashboard, which your browser loads over HTTPS, sends your keystrokes to the relay.
The relay forwards those keystrokes through the existing outbound connection to the CLI agent on the machine.
The agent starts or attaches to a shell, runs the commands, and streams the resulting terminal output back to the browser.

Because the connection is initiated by the machine, there is no need for a public IP, port forwarding, or a DMZ. The outbound connection can use standard HTTPS ports, which means it can pass through most firewalls and proxy environments. The browser side only needs access to the Pinggy dashboard, which is a normal website. This architecture is similar to remote support tools, but it is designed for developers who need full terminal access.

Prerequisites

Before you begin, make sure you have the following:

A machine you can physically access at least once, such as a laptop, desktop, or VM.
A user account on that machine with permission to run the Pinggy CLI. You do not need root.
An email address for the Pinggy account. If you do not already have one, a new free account will be created when you enter the email and verification code.
A browser that can reach the Pinggy dashboard. Chrome, Firefox, Safari, and Edge all work.
Enough disk space and memory to run both the CLI and Claude Code. Claude Code is a Node.js application, and its typical install requires a few hundred megabytes.
Optionally, npm and Node.js if you are on Alpine or another musl based Linux distribution, because the standard install script may not work there.

The install script does not require sudo. It installs the CLI into your home directory and runs the login flow automatically. On Windows, the PowerShell script uses irm and iex. On Alpine, the official docs recommend npm install -g pinggy instead.

Step 1: Install the Pinggy CLI and Sign In

The first command is simple. On Linux and macOS, open a terminal on the machine you want to reach and run:

curl -fsSL https://pinggy.io/install.sh | sh

The script will download the Pinggy CLI, put it in a location on your PATH, and start the login process. On Windows, use PowerShell:

irm https://pinggy.io/install.ps1 | iex

When the CLI asks for your email, enter the address you want to associate with the Pinggy account. It will send a six digit verification code. Type that code in the terminal. You may also be shown a link with an Approve sign in button. Only approve the login if the page on your screen displays the same code that the terminal printed. This prevents account takeovers from a mistyped email.

After the code is accepted, the CLI creates a device on your Pinggy account. The device name is usually the hostname of your machine. It appears on the Pinggy Devices page in the dashboard. If the machine was already added, the dashboard shows a Connect this device card on the Overview tab. That card contains two commands that already include your device token.

The first command works for machines that do not have the CLI installed:

curl -fsSL https://pinggy.io/install.sh | DEVICE_AGENT_TOKEN=<TOKEN> sh

The second command is for machines where the CLI is already installed:

pinggy device connect --token <TOKEN> --manage dashboard.pinggy.io

The --manage flag tells the agent which dashboard host it should connect to. The documentation for Pinggy Devices lists the same command without --manage, and it uses the default dashboard host. Using an explicit --manage is useful when you have multiple environments or when your company runs a custom relay. The token based flow is important for headless machines because you do not need to type an email or a verification code. You can install and connect in one step.

After the first successful connect, the CLI saves the token on the machine. From then on, you only need pinggy device connect to reconnect.

Step 2: Keep the Device Running in the Background

When you run pinggy device login or pinggy device connect for the first time, the agent stays in the foreground. It prints connection status, and it keeps running until you press Ctrl+C. For a quick test, that is fine. For real use, you want the agent to survive after you close the terminal. Stop the foreground agent, then reconnect in teh background with the -b flag:

pinggy device connect -b

If the machine does not have a saved token yet, include the token:

pinggy device connect --token <TOKEN> -b

The -b flag tells the CLI to run as part of the Pinggy daemon. The daemon is a lightweight background process that starts when you first run a background connect command. It is not the same as a cron job or a systemd service. It outlives the terminal that started it, but it does not survive a reboot. After the machine restarts, you must run pinggy device connect -b again to bring the device back online.

To stop the background agent, use:

pinggy device stop

If you want to stop the entire Pinggy daemon and all connected devices, use:

pinggy daemon stop

When the agent is stopped, the Pinggy dashboard shows the device as offline. If you try to open a terminal, the Terminal tab will be unusable until the device reconnects. You can also remove the device token from the local machine with pinggy device remove, but that only forgets the token locally. It does not delete the device from your account.

Step 3: Open the Terminal and Run Claude Code

Now the fun part. Go to the Pinggy dashboard, open the Devices page, and click the device you just connected. The Overview tab shows useful information about the machine: hostname, operating system, CPU, memory, and live system usage. This is handy for quickly checking whether the machine is under load before you start a big AI assisted refactor.

Above the system stats, you may see buttons for Terminal, Activity, and other tabs. Click Terminal and then click New shell. A new shell tab opens. Each shell gets its own tab, so you can have multiple terminals open at the same time, depending on your plan. From the browser, you can use the terminal almost exactly as you would use a local terminal. Typing, keyboard shortcuts, and terminal resizing work through the browser based client.

Let me show you a typical Claude Code workflow. You can change into your project directory and start the agent:

cd ~/code/storefront
claude

The first time you run claude in a browser shell, it may ask you to log in. If Claude Code is not installed yet, install it from the same browser shell:

curl -fsSL https://claude.ai/install.sh | bash

However, you should log in while you are still physically at the machine, because the first launch of Claude Code tries to open a browser window on the local machine. Claude Code has a fallback that prints a login URL and asks you to copy it, but I have not personally tested that fallback through the Pinggy dashboard terminal. If you want to be safe, complete the Claude Code login before you leave home.

Once Claude Code is running, the browser terminal behaves like a normal terminal. You can describe a task in natural language, approve file edits, run tests, and watch the output. The terminal redraws quickly enough for interactive work, and the dashboard keeps the session alive as long as you keep the shell active.

Here is what a simple Claude Code session looks like inside a Pinggy browser terminal. The shell on the right is running on the remote machine, while the browser is only responsible for drawing the terminal screen and capturing keystrokes.

Claude Code can also be used for non interactive tasks. You can ask it to generate a commit message, run the test suite, or fix a lint error. The browser terminal streams all of it back to you in real time.

After Claude Code finishes a task, it prints a summary of the files it changed and the commands it ran. You can review the output, type a follow up prompt, or switch to another shell tab.

Step 4: Run Long Tasks in the Background

A dashboard shell has two time limits. If the shell has no activity for 30 minutes, it ends. If the shell is open for 8 hours, it ends regardless of activity. This is intentional; it prevents forgotten browser tabs from leaving orphaned processes running forever. But it creates a problem for long Claude Code tasks, like running the test suite and fixing all failing tests in src/billing, or migrating a codebase from JavaScript to TypeScript. Those tasks can take longer than 30 minutes, and you might not be typing while they run. If the shell ends, the process running inside it may also end.

To handle long tasks, Claude Code has a background mode. You can start a session that is supervised by a seperate supervisor process, not by the terminal. The command looks like this:

claude --bg 'run the test suite and fix the failing tests in src/billing'

On Claude Code 2.1.317, running a short test prompt returned immediately and printed something like this:

Starting background service...

backgrounded · 5dc70293

  claude agents             list sessions
  claude attach 5dc70293    open in this terminal
  claude logs 5dc70293      show recent output
  claude stop 5dc70293      stop this session

The important thing is that a --bg session is not attached to the shell that started it. It runs in its own supervisor process, so it keeps working even if the dashboard shell closes. You can close the browser tab, go for a walk, and come back later. From any later shell, you can list all your sessions:

claude agents

You can reattach to a specific session with:

claude attach 5dc70293

You can view recent output without attaching:

claude logs 5dc70293

And you can stop a session:

claude stop 5dc70293

To detach from an attached session, press the left arrow key on an empty prompt, or press Ctrl+Z. A background session runs in its own Git worktree under .claude/worktrees/. This isolates the changes it makes from your main working tree until you merge them. The session survives sleep mode, but it stops if the machine shuts down. If you expect to run long tasks overnight, make sure the machine is plugged in and not set to hibernate.

Free vs Pro: What You Actually Get

The Pinggy browser terminal is available on every plan, including the Free plan. The differences are in the number of devices and concurrent terminals. The following numbers come from the Pinggy pricing page and the Pinggy Devices docs, as checked on November 3, 2026.

Plan	Price	Devices	Terminals per device	Terminals open across all devices
Free	$0	1	1	1
Pro	$2.50/month billed annually, $3/month billed monthly	25	3	10 per seat

The Free plan is enough for one home machine and one terminal. If you only need to run one Claude Code session from your laptop while you are away, that is fine. Once you start using multiple shells, the Pro plan becomes much more comfortable. Three shells per device means you can keep one terminal for Claude Code, one for a development server, and one for Git commands or log watching.

Pro also includes persistent tunnels, custom domains, and teams, and it comes with a 7 day free trial. For larger organizations, Enterprise offers custom pricing and unlimited devices and terminals. If you are trying to decide whether Free is enough, start with Free and only upgrade when you find yourself constantly closing and reopening shells.

How This Compares with Remote Control and SSH

There are two common alternatives for remote access to Claude Code. Both have trade-offs.

Claude Code Remote Control

Claude Code Remote Control is a feature that lets you attach to an already running Claude Code session. It is useful for pair programming or for checking in on a session that someone else started. However, it requires a Pro, Max, Ultra, Team, or Enterprise subscription. You cannot use it with API keys alone. More importantly, Remote Control only reaches a claude process that is already running. Someone still has to start claude remote-control on the machine before you can connect. If the machine is locked or the process dies, Remote Control cannot start a new one for you.

SSH and Reverse Tunnels

SSH is the classic answer. If the machine has a public IP and an SSH server, you can connect from anywhere. But many machines are behind NAT, CGNAT, or strict firewalls. To reach them, you need a tunnel like:

ssh -p 443 -R0:localhost:22 tcp@free.pinggy.io

That command creates a reverse tunnel through Pinggy's free TCP service, but the public address changes every 60 minutes on the free tier. You would need to keep checking the new address, which is impractical for interactive work. Tunnels are also a separate layer from the terminal; you still need an SSH client on the device you are connecting from.

What Pinggy Devices Changes

A Pinggy Devices shell has neither limitation. You can start Claude Code from scratch, restart a development server, run git pull, or even use a different coding agent like Codex. The browser terminal has your machine's credentials and filesystem, so it works like a local shell. There is no need to pre-start a special server. The only requirement is that the Pinggy agent is running on the machine.

If you want a deeper comparison of Claude Code and Codex on virtual machines, Pinggy has a separate guide that covers those setups in detail. The short version is that the device terminal gives you a generic shell, while Remote Control gives you a narrow window into one specific process.

Security Considerations

Giving yourself browser access to a machine also means giving anyone who can access your Pinggy account the same power. You should treat the Pinggy dashboard like a root password. The device token is stored in device.json under ~/.config/pinggy/, and it is readable only by your user. According to the Pinggy Devices docs, the agent never logs what you type. The Activity tab in the dashboard lists events with source IP addresses, so you can see when a device connected and from where.

The biggest risk is account compromise. Anyone signed in to your Pinggy account can open a shell on your devices, run commands as your user, and start Claude Code with your Anthropic login. That means they recieve access to your source code, environment variables, cloud credentials, and any API keys in your shell profile. Before you rely on this workflow, enable two factor authentication on your Pinggy account. Also, keep the dashboard's connect commands out of screenshots and chat messages, because they contain the device token. If a token leaks, an attacker can connect a rogue machine to your account or potentially take over your device.

To cut off a machine, delete the device in the dashboard or rotate its token. Rotating the token invalidates the old one, which forces the legitimate machine to reconnect with a new token. Note that pinggy device remove only forgets the token locally. It does not revoke the device from the account. Use the dashboard for revocation.

Troubleshooting

The two most common problems are straightforward.

Terminal Tab Is Greyed Out

If the Terminal tab is greyed out, the CLI on that machine is too old to support the browser terminal feature. Run the install command again to update the CLI. In most cases, the install script replaces the existing binary and you can reconnect immediately.

This machine already runs as device id in the background

This error appears when you try to run pinggy device login or pinggy device connect in the foreground while a background agent is already holding the connection to the dashboard. Stop it first:

pinggy device stop

After the background agent stops, you can run the foreground command again. If you want the device to stay connected, use pinggy device connect -b instead.

Device Does Not Come Back After Reboot

As I mentioned earlier, the background agent does not survive a reboot. If the machine restarts, run pinggy device connect -b again. To make this automatic, you can add a login item on macOS, a startup script on Windows, or a systemd user service on Linux. The Pinggy CLI does not install a system service by default, so you need to do this yourself if you want always on availability.

Shell Closes After Inactivity

Remember the 30 minute idle limit. If you step away from the browser terminal and the shell closes, any foreground process started inside it will also end. For long tasks, always use claude --bg or a process supervisor like tmux or screen. You can install tmux on the remote machine and run tmux inside the browser terminal. That gives you another layer of protection against shell timeouts.

Real-World Workflows

The flexibility of a browser terminal means you can do much more than run Claude Code. Here are a few workflows that work well.

1. Remote Development From a Thin Client

If you have a powerful desktop at home and a lightweight laptop on the road, you can leave the desktop connected with Pinggy and use its terminal from anywhere. Your IDE still runs locally, but the terminal controls the desktop. You can edit files through your IDE if you use a sync tool, or you can install a headless editor in a tmux session and use the browser terminal to do everything.

2. Server Maintenance

A cloud VM might only expose SSH through a bastion host. If you do not want to configure extra SSH keys, install Pinggy CLI on the VM and connect with a device token. From the browser, you can update packages, restart services, inspect logs, and run Claude Code to diagnose incidents. The outbound connection means you do not have to change security group rules.

3. Multiple Shells for a Complex Task

On the Pro plan, you can open three terminals on the same device at once. You might dedicate one shell to Claude Code, one to a local dev server, and one to Git or docker compose. Because each shell has its own tab, you can watch all three in the browser and switch between them quickly.

4. Headless Claude Code Tasks

You can start a Claude Code background session from the browser terminal and then detach. Close the browser tab. The session continues. Later, open a new shell, list the sessions, and attach to see the output. This gives you a very simple remote job queue for AI assisted coding tasks.

5. Pair Debugging

If you share a Pinggy account with a trusted teammate, both of you can sign in and open a shell on the same device. Since each shell is independent, two people can work on the same machine simultaneously. Be careful with concurrent Git operations in the same repository. You may end up with merge conflicts or index locks. Use separate worktrees or coordinate through Claude Code sessions.

Performance, Latency, and Practical Limits

A browser terminal is not as instant as a local terminal, but it is close. The Pinggy relay is optimized for terminal traffic, which is low bandwidth and high interactivity. Over a normal internet connection, keystroke latency is usually well under a second. The bigger bottleneck is often the responsiveness of the remote machine itself.

You can reduce latency by working near the machine's network region and by using a wired connection on the remote side. Wi-Fi with interference can cause jitter, especially if the remote machine is a laptop in sleep mode or on a weak signal. If you plan to run Claude Code for hours, make sure the machine does not go to sleep. In macOS, you can use caffeinate to prevent sleep while the terminal is active.

The dashboard terminal renders ANSI colors, box drawing characters, and Unicode output. Most modern browsers handle this well. If you notice text flicker or misaligned output, try a different browser or disable browser extensions that modify the DOM. The terminal client is also compatible with common terminal multiplexers like tmux and screen. If a shell ends because of inactivity, tmux can keep your session alive; the Pinggy shell can reconnect to the same tmux session in a new browser tab.

Edge Cases and Limitations

It is worth being explicit about what this setup does not do.

The Pinggy agent must be running. If the machine is off, asleep, or the daemon is stopped, no terminal can connect.
The free plan has one device and one concurrent terminal. Opening a second shell will fail until the first one is closed.
A foreground process started in a normal dashboard shell dies when the shell ends. Background sessions started with claude --bg survive shell termination.
The device token grants full access to a shell as the user who owns the token. Anyone with access to your Pinggy account has the same power.
The terminal runs as the user who started the Pinggy agent, not as root. If you need root privileges, you can use sudo inside the terminal, assuming your user is allowed to.
The browser terminal is not meant for very high bandwidth applications like streaming video or transferring large files. It is a terminal, not a general purpose tunnel. For file transfers, use a separate tunnel or an SCP session configured through Pinggy.
The 30 minute idle limit applies to browser shells. Background CLI sessions are managed separately by Claude Code. If you use tmux, the tmux session persists even if the browser shell ends.

Frequently Asked Questions

Do I need a public IP address?

No. The machine only makes an outbound connection to the Pinggy relay. It works behind NAT, CGNAT, and most firewalls.

Can I run Claude Code without installing anything on the remote machine?

No. You need the Pinggy CLI installed on the machine you want to reach. The installation is a single command and does not require sudo.

Does the browser terminal support copy and paste?

Yes. Most browser terminals support clipboard operations through keyboard shortcuts or context menus. The exact behavior depends on your browser. On macOS, Cmd+C and Cmd+V generally work in the terminal's native menu or through the browser's clipboard permission prompts.

Is it safe to leave the Pinggy agent running all the time?

It is safe as long as your account is secured with a strong password and two factor authentication, and as long as the device token stays private. The agent itself only sends terminal keystrokes and output over an outbound TLS connection. It does not expose a generic port.

Can I use this with tools other than Claude Code?

Absolutely. The browser terminal is a full shell. You can run git, docker, vim, htop, node, python, Codex, or any other command. Claude Code is just one example, and a very useful one for AI driven development.

What happens if my browser crashes?

The shell on the remote machine stays alive for a while because the relay may not immediately know that the browser disconnected. When you reopen the dashboard and click the Terminal tab, the screen is redrawn to reflect the current state of the shell. If the shell hit the idle timeout, you will see a fresh shell instead.

Does `claude --bg` work through the browser terminal?

Yes. You can run claude --bg 'task' in any shell, including a browser shell. The background process is independent of the shell that launched it. As long as the Pinggy agent is running and the machine is on, the background session continues.

What is the difference between `claude --bg` and `tmux`?

claude --bg is specific to Claude Code and runs the agent in a separate supervised process. tmux is a general terminal multiplexer that keeps any interactive program alive across terminal disconnects. You can use both together: open a browser shell, start tmux, run claude inside tmux, and then detach from tmux. Even if the browser shell times out, the tmux session and Claude Code remain alive. The downside is that attaching to a tmux session is less convenient than claude attach for seeing recent output, because you have to reattach to the session.

Best Practices Checklist

Use two factor authentication on your Pinggy account.
Keep the device token out of logs and screenshots.
Use pinggy device connect -b for long running machines.
Create a startup job to reconnect after reboot.
Use claude --bg for tasks longer than a few minutes.
Check claude agents before starting another background session.
Use tmux if you want a persistent interactive shell beyond Claude Code's background mode.
Keep the remote machine awake with caffeinate on macOS or a power plan on Windows.
Monitor the Overview tab to see if the machine is under heavy load.
Rotate the device token when you stop using a machine.

Recap

The whole setup can be summarized in three commands. On the machine you want to reach, install and sign in:

curl -fsSL https://pinggy.io/install.sh | sh

Keep the device connected in the background:

pinggy device connect -b

From the browser terminal, start a Claude Code background task:

claude --bg '<your task>'

Then open the Pinggy Devices page, click the device, open the Terminal tab, and choose New shell. You now have a real terminal on that machine, running in a browser, ready for Claude Code or anything else.

The combination of an outbound only agent and a browser based terminal is a practical answer to a very common developer problem: your best coding environment is stuck on a machine you are not in front of. Pinggy Devices solves that without requiring you to open ports, maintain a VPN, or leave an SSH server exposed. It is simple, close to the metal, and works with the AI coding tools you already use.

Reference

Run Claude Code Remotely from Any Browser with Pinggy

OpenRouter's Free Model APIs in 2026: Working With Request Limits Instead of Token Caps

Lightning Developer — Thu, 05 Nov 2026 07:53:03 +0000

Most developers hit the same wall once they start building with large language models. The prototype works, and then the API bill starts tracking every experiment. Frontier models still bill by the token. Claude Opus 5.5 lists at $4 per million input tokens and $20 per million output tokens, and that adds up fast once you are calling it in a loop.

Search for 'free AI API unlimited tokens' and you will find a pile of posts promising a way around that. The honest version is less exciting but more useful. OpenRouter gives you no-credit-card access to a rotating set of models at $0 per token, but 'unlimited' is not the right word. You get 20 requests per minute and either 50 or 1,000 requests per day, depending on whether you have bought $10 of credits. No token cap, but a very real request cap.

The free list also turns over fast. In July 2026, Owl Alpha, Tencent Hy3, Qwen3 Coder and gpt-oss-120b were all free on OpenRouter; none of them is free today, and the lineup is led by Thinking Machines Lab's 975-billion-parameter Inkling and NVIDIA's Nemotron family. Every limit, price and model ID below was checked against OpenRouter's live API and model pages on October 27, 2026.

Here is the current free lineup at a glance before we get into the mechanics:

Model	Size	Context (free)	Best For
Thinking Machines Inkling	975B / 41B active MoE	1M tokens	Coding and agent harnesses, text, image and audio input
NVIDIA Nemotron 3 Ultra	550B / 55B active MoE	1M tokens	General reasoning, agent orchestration
NVIDIA Nemotron 3.5 Super VL	120B / 12B active MoE	1M tokens	Documents, screenshots and video input
Google Gemma 4	31B dense / 26B-A4B MoE	262K tokens	Multimodal input, function calling, 140+ languages
Poolside Laguna S 2.1	118B / 8B active MoE	262K tokens	Coding agents, going away October 31, 2026
openrouter/free	Router over the free models	200K tokens	Code that should keep working as models rotate

That table covers the six worth knowing individually. Counting embedding, reranking, speech and 'decision' models, OpenRouter lists 28 model IDs ending in :free right now, 16 of them chat models, and we get to the rest further down.

The Free Tier: Rate Limits, Not Token Limits

This is the part most 'unlimited tokens' articles get wrong. OpenRouter's free models charge $0.00 per input token and $0.00 per output token, so there is genuinely no token-based billing. What every account does have is a request cap, documented on OpenRouter's limits page:

20 requests per minute, always, regardless of account status
50 requests per day if you have bought less than $10 of credits in total
1,000 requests per day once your credit purchases reach $10

The docs say the daily tier is selected by all-time credits purchased, so it counts what you have bought over the account's lifetime, not your current balance. Once you cross $10, the higher ceiling stays even if your balance later drops to zero. In practice the 1,000 tier starts at 9 credits, one below the threshold, which OpenRouter says absorbs rounding and top-up fees.

So a 100,000-token conversation costs you one request, same as a two-word prompt, and an agent loop that calls the model dozens of times per task hits the daily ceiling long before any token count matters. Two more things can stop you: Cloudflare's DDoS protection blocks requests that dramatically exceed reasonable usage, and a negative credit balance can block free models too, with 402 errors. That mostly happens if you use paid models alongside free ones and let the balance run dry.

Checking How Many Free Requests You Have Left

OpenRouter reports the daily counter on its key endpoint:

curl https://openrouter.ai/api/v1/key -H 'Authorization: Bearer $OPENROUTER_API_KEY'

The response includes a free_model_daily_requests object with used, limit and remaining counts for the current UTC day. An agent can check it before a long run instead of discovering the ceiling through 429 'Rate limit exceeded' errors halfway through. It does not report the per-minute limit, though. When you do hit a limit, the 429 response carries X-RateLimit-* headers describing the one you hit.

A quick parsing pattern with jq makes this easier to use in a script:

curl -s https://openrouter.ai/api/v1/key -H 'Authorization: Bearer $OPENROUTER_API_KEY' | jq '.free_model_daily_requests'

That gives you something like {"used": 12, "limit": 50, "remaining": 38}. You can recieve these values before launching a batch job and stop early if the remaining count is too low. The remaining field is the one that matters most because it tells you how many requests are still available for the rest of the UTC day.

Getting Set Up

Go to the OpenRouter keys page and sign up with email or GitHub. No credit card is needed for free models.
Generate an API key on that page. You can optionally cap each key with a credit limit.
Optional, recommended: buy credits. Pay-as-you-go carries a 5.5% platform fee on credit purchases, and $10 of purchases in total is what raises your free-model ceiling to 1,000 requests a day. It is a one-time threshold, not a subscription.
Call the API. Free models carry a :free suffix on their model ID, and OpenRouter's Free Models collection is the fastest way to see what is available today.

If you only plan to use free models, you can stop at step 2 and spend $0. The $10 is purely about the daily ceiling, and it is worth buying once a project becomes something you use every day, because 50 requests disappear fast when you are iterating on prompts. Before you buy, note that OpenRouter's FAQ says OpenRouter reserves the right to expire unused credits a year after purchase.

Calling a Free Model

Because OpenRouter mirrors the OpenAI API shape, you can use curl directly or the standard OpenAI Python SDK pointed at a different base URL. Here is the raw HTTP version:

curl https://openrouter.ai/api/v1/chat/completions -H 'Content-Type: application/json' -H 'Authorization: Bearer $OPENROUTER_API_KEY' -d '{"model": "nvidia/nemotron-3-ultra-550b-a55b:free", "messages": [{"role": "user", "content": "Explain the difference between MoE and dense transformer architectures in two sentences."}]}'

And the same call using the official OpenAI Python SDK, just repointed at OpenRouter:

from openai import OpenAI

client = OpenAI(
    base_url='https://openrouter.ai/api/v1',
    api_key='sk-or-v1-your-key-here',
)

response = client.chat.completions.create(
    model='nvidia/nemotron-3-ultra-550b-a55b:free',
    messages=[
        {'role': 'user', 'content': 'Explain the difference between MoE and dense transformer architectures in two sentences.'}
    ],
)

print(response.choices[0].message.content)

No OpenRouter-specific SDK, no custom client library. If your code already talks to the OpenAI API, changing base_url and the model string is the entire migration.

Understanding Free Model IDs and Endpoint Behavior

Every free model has the suffix :free at the end of its model ID. That suffix is the only thing that makes it free. The base URL is still https://openrouter.ai/api/v1, the authentication is still the same API key, and the request format is the same as the OpenAI-compatible interface. If you remove the suffix from a model ID, the same model may become a paid listing, so the suffix is not decorative. It is a routing tag that tells OpenRouter which pricing tier to apply.

The openrouter/free router does not carry the suffix because it is not a model in the traditional sense. It is an alias that resolves to a random free model that supports your request's required features. This is useful for quick experiments, but it makes behavior less predictable. You cannot assume which model will answer, and some free models are much slower than others.

The Free Models collection on OpenRouter is generated from the same API data that is used for the model list, so it is more reliable than a blog post that was written a month ago. Bookmark that page if you are planning to depend on free models.

Context Windows and Output Limits

Free models do not all have the same context window. The table above shows that several top models offer 1M tokens on their free endpoints, while others like Gemma 4 stop at 262K tokens. Context window is not the same as output limit. A model with a 1M context can still cap the number of tokens it generates in one response. For example, NVIDIA Nemotron 3 Ultra allows up to 65,536 output tokens on its free endpoint. That is generous, but it is not infinite. If you send a prompt that asks for many separate tasks, you may hit the output cap even though the context window has room.

When you use the OpenAI SDK, you can control the output size with max_tokens or with the newer max_completion_tokens parameter. For an OpenRouter request, max_tokens is the safer choice because many providers on the platform still use it. If you request more output tokens than the endpoint allows, the provider may reject the request or truncate it depending on the model. The response object includes a finish_reason field. A finish_reason of length means the model reached its token limit before completing the message.

response = client.chat.completions.create(
    model='nvidia/nemotron-3-ultra-550b-a55b:free',
    max_tokens=1024,
    messages=[
        {'role': 'user', 'content': 'Write a detailed design document for a rate-limited API gateway.'}
    ],
)
if response.choices[0].finish_reason == 'length':
    print('Response was truncated by the output token limit.')

This matters more on free models because you do not want to waste a request on a response that gets cut off at the wrong place. If you need longer outputs, retry with a higher max, use a model with a larger output budget, or ask the model to continue from the last sentence.

Rate Limit Headers and Backoff

When you exceed the per-minute limit or the daily limit, OpenRouter responds with HTTP 429 and a set of X-RateLimit-* headers. The headers tell you which limit was hit and when it resets. A robust client should read those headers and back off instead of retrying immediately.

Here is a minimal Python retry loop that respects the reset time:

import time
import requests

url = 'https://openrouter.ai/api/v1/chat/completions'
headers = {
    'Authorization': 'Bearer sk-or-v1-your-key-here',
    'Content-Type': 'application/json'
}
payload = {
    'model': 'nvidia/nemotron-3-ultra-550b-a55b:free',
    'messages': [{'role': 'user', 'content': 'Hello from a rate limited client.'}]
}

for attempt in range(5):
    resp = requests.post(url, json=payload, headers=headers)
    if resp.status_code == 200:
        break
    if resp.status_code == 429:
        reset_time = int(resp.headers.get('X-RateLimit-Reset', '0'))
        wait_time = max(1, reset_time - int(time.time()))
        time.sleep(wait_time)
    else:
        resp.raise_for_status()

X-RateLimit-Reset may be a Unix timestamp. If the header is not present, fall back to a fixed sleep. Do not hammer the endpoint; that can trigger Cloudflare's DDoS protection and get your IP blocked.

Handling Rotation and Rate Limits with Fallback Models

The single most important production tip for the free tier: do not hardcode one free model. Free variants get pulled or repriced without much warning. Between July and late October 2026, qwen/qwen3-coder:free, openai/gpt-oss-120b:free, tencent/hy3:free and nvidia/nemotron-3-super-120b-a12b:free have all disappeared, and any code pinned to them now fails. OpenRouter's models array lets you list several candidates in priority order in one request:

{
  "models": [
    "nvidia/nemotron-3-ultra-550b-a55b:free",
    "google/gemma-4-31b-it:free",
    "nvidia/nemotron-3.5-lightning:free"
  ],
  "messages": [
    {"role": "user", "content": "Summarize this changelog in three bullet points."}
  ]
}

By default any error can send the request to the next model, including context-length errors, moderation flags, rate limiting and provider downtime. You are billed for whichever model answered, and its ID comes back in the response's model field, so you can log which fallback fired. Keep every entry a :free model: if the list falls through to a paid one, you pay that model's rate.

The exact configuraton of your fallback list will depend on what capabilities you need. If you need tool calling or structured outputs, check the model page for each candidate before adding it. Not every free model supports every feature. A router model can help here, but it is not a replacement for a fallback strategy.

If you would rather not manage a list at all, openrouter/free is a router that picks a free model at random from the ones that support what your request needs, such as tool calling, structured outputs or image input. It trades predictability for convenience: you do not control which model answers, but your code keeps working as the free lineup changes.

How Free Models Leave OpenRouter

Three months ago the free list looked different. In July, Nemotron 3 Ultra, Gemma 4, Owl Alpha, Tencent Hy3, Qwen3 Coder and gpt-oss-120b were all free. Only the first two still are, and the other four show the different ways a free listing ends.

Owl Alpha turned out to be Meituan's LongCat-2.0. It was a stealth model, a prerelease checkpoint OpenRouter serves for free under a codename while the lab collects real-world usage. At the end of June, Meituan's LongCat team introduced LongCat-2.0 as the full model behind Owl Alpha: 1.6 trillion parameters, about 48B active per token, and a 1M-token context. The weights are on Hugging Face under the MIT license, and on OpenRouter meituan/longcat-2.0 costs $0.30/M input and $1.20/M output, currently shown as a discounted price.

The same pattern occured again this fall. A stealth model called Space Bunny left OpenRouter on October 5 and came back on October 19 as MiniMax M3.1 Flash, free for 72 hours and now paid, from $0.143/M input. As of October 27 there is no stealth model on the list, so do not plan around one.

Tencent Hy3's free window closed. Tencent had set July 21 as the end date for the free listing, and Hy3 is now paid only, from $0.0825/M input and $0.33/M output through Tencent's own endpoint.

Qwen3 Coder and gpt-oss-120b lost their :free variants. Both are still on OpenRouter as paid models: Qwen3 Coder from $0.22/M input, and gpt-oss-120b from $0.03/M input and $0.15/M output across about two dozen providers. At that price gpt-oss is close to free anyway. Smaller free models from July went the same way: the free Llama 3.3 70B, Llama 3.2 3B and Hermes 3 405B variants are gone, and NVIDIA's Nemotron 3 Super lost its free endpoint in late October. DeepSeek still has no free model, though V4.1 Flash is listed at $0.14/M input and $0.42/M output.

This churn is not a bug. Free endpoints exist to promote labs, gather telemetry, and push adoption. Once a model has enough traction, the free tier goes away. The best defense is to treat the free catalog as a pool of interchangeable endpoints rather than a set of permanent providers.

How to Keep Up With Rotation

Because free model lists change quickly, a weekly review is reasonable. Open an issue in your repo or use a scheduled job that queries the model list and filters by :free. Keep the list in your README so other contributors know not to hardcode a model that might disappear.

Another practical habit is to add a comment next to each free model ID in your config file with the date it was verified. When the list changes, you know exactly which entries need to be updated. This has saved many debugging sessions.

If you use a shared team account, tell everyone to check the OpenRouter Free Models collection before they start a new integration. It only takes a minute and it prevents the most common failure mode: a hardcoded model that was removed from the free tier overnight.

The Free Model Catalog Right Now

OpenRouter's free lineup is a moving target: models get added when labs promote a launch, and pulled when the promotion ends. On October 27, 2026, the API lists 28 model IDs ending in :free: 16 chat models, seven embedding and reranking models, two text-to-speech models and three 'decision' models that return scored answers instead of free text. By last week's usage, OpenRouter's Free Models page ranks Nemotron 3 Ultra, Nemotron 3.5 Super VL and Nemotron 3.5 Lightning as the most used. Five of the chat models are worth calling out individually.

Thinking Machines Inkling (975B-A41B)

Inkling is the biggest model on the free list. Thinking Machines Lab released it on July 15, 2026, trained from scratch with the full weights available: a Mixture-of-Experts with 975B total parameters and 41B active, text, image and audio input, and up to 1M tokens of context. The weights are on Hugging Face under Apache 2.0. On OpenRouter the free endpoint serves the full 1M context, while the paid listing ($1.00/M input, $4.05/M output) tops out at 524K. The lab is frank about where it stands: Inkling is not the strongest overall model available today, open or closed, and it pitches itself as a base for customization.

Read the notice at the top of the model page before you wire it in. The free endpoint is only available for use with agentic harnesses, and Thinking Machines logs its prompts and outputs to improve its models, after separating them from your account. Use it for coding-agent experiments, not confidential work. Its smaller sibling, thinkingmachines/inkling-small:free (276B total, 12B active), is free as well.

NVIDIA Nemotron 3 Ultra (550B-A55B)

NVIDIA Nemotron 3 Ultra, released June 4, 2026, is one of the two July picks that is still free. It is a 550B-parameter MoE with 55B active per token, built on a hybrid Transformer-Mamba architecture that NVIDIA designed for high-throughput agent pipelines. NVIDIA serves the free endpoint itself, with a 1M-token context and up to 65,536 output tokens. The paid endpoints, from $0.40/M input and $1.76/M output, stop at 262K context, so on this model the free tier is the bigger one. NVIDIA's notice on the page says use of the free endpoint is logged for security purposes and to improve NVIDIA products and services.

NVIDIA Nemotron 3.5 Super VL (120B-A12B)

Nemotron 3.5 Super VL is the newest model in this guide, released October 15, 2026. It is a 120B-parameter MoE with 12B active that takes text, images, documents, GUI screenshots and video and returns text, with a 1M-token context and reasoning switched on by default. You can turn it off or give it a token budget. That makes it the free pick for document extraction, screenshot-driven agents and video understanding. The same NVIDIA logging notice sits on its page. Paid endpoints start at $0.06/M input. For speed over size, nvidia/nemotron-3.5-lightning:free (30B total, 3B active, text only, 1M context) is the high-throughput option in the same family.

Google Gemma 4 (31B and 26B-A4B)

Google DeepMind's Gemma 4 family, released April 2, 2026, is the other July pick that is still free, and both variants survived. google/gemma-4-31b-it:free is the 30.7B dense model: no MoE routing, so it is the slower of the two, but it is the one to reach for when you want the best single answer. google/gemma-4-26b-a4b-it:free is the MoE sibling, with 25.2B total and 3.8B active parameters, landing close to the 31B model's quality while responding faster. Google AI Studio serves both for free with a 262K context, up to 32,768 output tokens, image and video input, configurable thinking, native function calling and 140+ languages, under the Apache 2.0 license. Unlike the NVIDIA and Thinking Machines pages, Gemma's free page shows no logging notice.

Poolside Laguna S 2.1 - Going Away October 31

Laguna S 2.1 is Poolside's coding-agent model: 118B total parameters, 8B active, open-weight under the OpenMDW-1.1 license, with a 262K context on the free endpoint. Poolside reports 70.2% on Terminal-Bench 2.1 and 40.4% on DeepSWE. Those are vendor numbers, but strong ones for a model with 8B active parameters, and of everything on the free list it is the one most directly built for coding agents. That is exactly the problem: the model page says going away October 31, 2026, and the smaller poolside/laguna-xs-2.1:free (33B total, 3B active) expires the same day. Poolside also says it may use free-tier inputs and outputs to train its models. It is not only the free tier that is ending: the paid listing ($0.09/M input, $0.18/M output, 1M context) shows the same going away date, as does the paid Laguna XS 2.1.

We are calling it out because free-tier listicles go stale within weeks. After October 31, 2026, check its current listing before you use it.

The Rest of the Current Free Roster

Beyond those five, the free chat models are Inkling Small; NVIDIA's Nemotron 3.5 Lightning, Nemotron 3 Nano Omni (30B-A3B, with text, image, audio and video input) and the 4B Nemotron 3.5 Content Safety guardrail model; Cohere's North Mini Code (30B, 3B active), its first agentic coding model; Recursive's Flint (40B, 2.5B active), built for coding agents and added on October 21; China Telecom's Xing4.0 29B-A4B; Dots Studio's Dots3-Note Preview (280B, 16B active), free until December 31, 2026; and LiquidAI's LFM2.5-2.6B for small, fast jobs. Outside chat, there are free embedding and reranking models from NVIDIA and LiquidAI, and free text-to-speech from Fish Audio and HeyGen. HeyGen's free text-to-speech listing ends November 30, 2026.

For open-weight models you can run on your own hardware instead of depending on a rotating free tier, see the rest of this blog for self-hosting options.

Free Embedding, Reranking and Speech Endpoints

Not every free endpoint is a chat model. OpenRouter also exposes free embeddings and reranking models. The chat completion endpoint is the obvious way to use free AI, but the embedding endpoints are useful for private knowledge bases, semantic search, and retrieval-augmented generation. Most of these models also use the same :free suffix, and the API shape follows the OpenAI embeddings interface.

For reranking, you send a query and a list of candidate documents, and the model returns relevance scores. This is useful when you want to filter a large set of results before sending the best ones to a chat model. The free tier on these models is small, but it is enough for experiments and low-traffic retrieval pipelines.

Speech endpoints are a different story. Free text-to-speech models from Fish Audio and HeyGen let you generate audio from text without paying. Those endpoints consume the same daily free request budget, so a long-form audio generation task can burn through the quota quickly. The quality varies, so test the audio output before using it in a user-facing product.

'Decision' models on OpenRouter return scored answers instead of free text. They are less common, but they fit into classification and routing workflows where a structured score is more useful than a paragraph.

What the Free Endpoints Do With Your Prompts

Rate limits are the documented cost of the free tier. The less obvious one is data. Three of the five model pages above say the provider logs free-tier traffic or may train on it: NVIDIA and Thinking Machines log it to improve their models, and Poolside may train on it. That is the deal behind most free inference: you get the tokens, and the lab gets real-world usage.

OpenRouter lets you opt out, at a price. Your account's privacy settings have separate switches for paid and free models on whether to allow providers that may train on your data, and per OpenRouter's provider logging docs, if you opt out, OpenRouter will not route to providers that train. Every free model in this guide runs on a single provider, so opting out does not move you to a safer host; it takes those models off the table for your account. If a free model works for everyone else but fails for you, check that setting first.

Privacy compliance is an important part of the decision. If your company has a policy that prohibits sending customer data to providers that may retain it, you need to review each free model's data notice before using it. The free tier is convenient, but it is not a place for secrets, personal data, or proprietary code.

The Business Model Behind Free Inference

Even though the price is $0, there is a cost. The labs behind these models need real-world usage, feedback, and performance data. Free inference is a form of evaluation at scale. When a lab like NVIDIA or Thinking Machines offers a free endpoint, it is not giving away a commodity. It is using the free tier to stress-test a new architecture, gather quality signals, and build a community of developers who will move to paid infrastructure when the project becomes serious.

OpenRouter also benefits because free models attract developers to its API, and once they are comfortable, the paid tier is a short step away. The free tier can be seen as an extended trial of both the model and the routing platform.

This business logic explains why models rotate. A free listing is not a guarantee. It is a promotional window, and the window closes when the lab decides that the promotion has served its purpose.

Free Tier vs. Paying: What You Actually Give Up

The free tier is not a stripped-down demo. The biggest free models are frontier-scale open-weight releases, and on Inkling and Nemotron 3 Ultra the free endpoint offers a bigger context window than the paid listing. What you give up by staying free:

Proprietary flagships. Free models on OpenRouter are open-weight releases or temporary promotions. You will not find free access to Claude, GPT or Gemini's flagship tiers.
Throughput. 50 or 1,000 requests a day is fine for personal projects and prototyping. It is not enough for a production app with real traffic, and OpenRouter itself warns that free models can be rate limited or slower at peak times.
Privacy. Many free endpoints log or may train on what you send.

Once you outgrow it, pay-as-you-go charges each provider's list price with no markup on tokens, plus the 5.5% fee when you buy credits. If you already have keys with OpenAI, Anthropic or Google, bring your own key routes through them with no OpenRouter fee on the first $25,000 of list-price inference each month and 5% after that. For gateways beyond OpenRouter, tooling like Portkey and LiteLLM can help with routing, caching and retries, and our other OpenRouter production posts cover what breaks when you move paid traffic onto it.

Error Codes You Might See

OpenRouter uses standard HTTP status codes, but the meaning can be confusing if you are new to the free tier.

Status	Meaning	What to do
401	Invalid API key	Regenerate the key in your OpenRouter dashboard and update your config
402	Negative credit balance	Add credits; free models can also be blocked by this condition
404	Model not found	Check the model ID and the `:free` suffix
429	Rate limit hit	Read the `X-RateLimit-*` headers and back off
5xx	Provider error	Retry with exponential backoff or use a fallback model

A 5xx error is different from a rate limit. It usually means the provider had a transient issue, and a fallback model can keep your agent moving. A 429 means you are being throttled, and no amount of fallback switching will help until the reset time arrives.

A Realistic Way to Use This

The pattern that holds up over time looks like this: build against the OpenAI-compatible endpoint so you are never locked into one provider's SDK, put two or three free models in a models fallback array instead of trusting any single one, check free_model_daily_requests before long runs, and keep confidential data on paid endpoints whose data policy you have read. Treat stealth models and time-limited listings like Laguna S 2.1 as bonus capacity, not something a workflow depends on.

A practical example of a healthy integration:

import requests

api_key = 'sk-or-v1-your-key-here'
url = 'https://openrouter.ai/api/v1/chat/completions'

payload = {
    'models': [
        'nvidia/nemotron-3-ultra-550b-a55b:free',
        'google/gemma-4-31b-it:free',
        'nvidia/nemotron-3.5-lightning:free'
    ],
    'messages': [
        {'role': 'user', 'content': 'Explain the tradeoffs of free LLM APIs.'}
    ]
}

resp = requests.post(
    url,
    json=payload,
    headers={'Authorization': f'Bearer {api_key}'}
)
print(resp.json())

This request uses Python's requests library and passes the fallback array directly. The response will tell you which model handled the call, and you can log it for later analysis.

Using Free Models in Agent Loops

An agent loop can consume the daily free quota very quickly. Each tool call, each retry, and each intermediate step can generate a new chat completion. A task that takes 20 steps can eat 20 requests in minutes. To make the quota last, consider using a larger context and packing multiple steps into one prompt. When you can, reuse previous completions instead of asking the model to re-read the whole transcript.

Another approach is to route only the final decision to a large free model and use a smaller model for simpler subtasks. For example, use nvidia/nemotron-3.5-lightning:free for extraction and nvidia/nemotron-3-ultra-550b-a55b:free for the final synthesis. The fallback array still applies, but you can choose different fallback lists for different task classes.

Coding agents like OpenCode ship OpenRouter as a built-in provider, so you can point them at the free tier without writing a custom integration. The same request caps apply, though, so an agent that makes many small calls will still exhaust the daily limit quickly. If you use a coding agent, set a low request budget and fall back to a paid model for long sessions.

Monitoring Free Usage

The key endpoint gives you the daily usage numbers, but not a historical view. For a long-running project, log the model field from every response and count requests by model ID. You can also check the OpenRouter activity page to see recent requests and errors across your account. A simple cron job that runs once an hour can hit the key endpoint and write the remaining count to a log file.

A logging line does not need to be complicated. Capture the timestamp, the selected model, the status code, and the finish_reason. That is enough to detect when a particular model starts failing or when your fallback order is not working as intended.

Practical Example: Daily Newsletter Summarizer

Imagine you want a bot that reads a set of tech newsletters every morning and produces a one-paragraph summary. With the free tier, you can do this with a small Python script. The script fetches the articles, truncates each one to the context limit, sends the content to a free model, and stores the summary. A daily run uses maybe 10 to 20 requests, which fits comfortably in the 50 request daily tier.

First, choose a fallback list with two free models. Second, call the chat completion endpoint. Third, check finish_reason and store the output. Finally, schedule it with cron. This is a good example because it uses the free tier for a bounded task rather than building a production API that needs thousands of calls per day.

The same pattern applies to other scheduled jobs: log summarization, test report generation, issue triage, and personal research digests. Keep the scope small, monitor the daily remaining count, and you can get real value from an API that costs nothing per token.

Frequently Asked Questions

Is OpenRouter's free tier actually unlimited?

No. The tokens are free, but the requests are capped. The daily cap is 50 or 1,000 requests depending on your all-time credit purchases, and the per-minute cap is always 20. If you stay under those limits, you can send very large prompts and receive very long completions without token billing.

Why did my free model stop working?

Free listings rotate. Labs use free inference to promote launches, collect telemetry, or test a model under real traffic. When the promotion ends, the model either disappears from the free list or becomes paid. Always have a fallback list and check the OpenRouter model pages before a deploy.

Can I use free models in production?

You can, but only for low-traffic internal tools, personal projects, and experiments. The request caps and the data logging notices make them unsuitable for customer-facing products that need privacy and consistent throughput. For production use, the paid tier or bring-your-own-key route is a better fit.

Does using a free model with a huge context count as one request?

Yes. A request is one API call, regardless of token count. That is why free models with 1M context are attractive for document processing, but you still have to respect the daily request limit.

Should I pay the $10 to unlock 1,000 requests?

If you are using free models every day or iterating on prompts for hours, yes. The $10 is a one-time threshold that raises your free daily ceiling, and it also gives you pay-as-you-go access to paid models if you need them. If you only need a handful of requests for a weekend experiment, skip it.

Conclusion

'Free AI API with unlimited tokens' is a catchy search phrase, but the accurate description is more useful once you understand it: OpenRouter gives you free, per-token-uncapped access to a strong and changing set of open-weight models, gated by a daily request limit rather than a token limit. Right now the lineup includes Inkling, Nemotron 3 Ultra, Nemotron 3.5 Super VL and Gemma 4. Fifty requests a day costs nothing and needs no card; $10 of credits, bought once, raises that to a thousand. The discipline it asks for has not changed since July: build for rotation from day one, read each free endpoint's data notice, and recheck model pages before you rely on them.

Reference

How to get Free AI Model APIs with 'Unlimited' Tokens

Proactive AI Agents in 2026: Dots, Muse, Grok Bot, Instinct, OpenClaw, and Hermes Compared

Lightning Developer — Wed, 04 Nov 2026 06:54:06 +0000

Proactive AI agents are the new frontier in assistant design. Traditional chatbots wait for your message and then respond, which makes them easy to reason about. The new generation flips that model. Agents run in the background, wake themselves on schedules or events, and send you notifications before you ask. For developers, this shift is both exciting and a little uncomfortable, because proactivity means an agent can perform actions in the world without a fresh command from you.

Between August 11 and October 21, 2026, the landscape changed rapidly. xAI shipped Grok Bot, Meta shipped Meta Muse, OpenAI shipped OpenAI Dots, and Anthropic previewed Claude Duet. Instinct, an agent you interact with through your phone number, was valued at ten billion dollars by October. Open source projects were already ahead on this path. OpenClaw had 393,525 GitHub stars on October 31, and Hermes Agent had 259,065. Both run on your own hardware, which makes them interesting for privacy sensitive workflows.

In this article, I compare six proactive agents: OpenAI Dots, Meta Muse, Grok Bot, Instinct, OpenClaw, and Hermes Agent. The comparison uses a concrete running example. You want a weekday 8 AM brief that only speaks up when a decision is needed, and you want to know what happens when a new GitHub issue arrives during the day. I verified the claims below on October 31, 2026. The OpenClaw and Hermes commands were tested in clean Docker containers, so the output you see is reproducible.

What makes an AI agent proactive

An agent is proactive when it starts a turn on its own, without a new user message. There are three common trigger types: a schedule, an event, or a self-wake. A schedule is usually a cron expression or a plain English phrase like weekdays at 8am. An event is a webhook, an email, a GitHub issue, or a Slack mention. A self-wake is the most interesting. It means the agent decides when to check back, or it runs a periodic pass over your data asking whether anything needs attention.

Self-wake only works if the agent can stay silent when nothing matters. OpenClaw's default heartbeat prompt ends with If nothing needs attention, reply NO_REPLY. Hermes does the same thing with a [SILENT] token: if the final response contains that token, the gateway skips delivery. Without a quiet path, a proactive agent would spam you every few hours with low value summaries. That is why the quiet path is one of the first features to check.

Proactivity also changes the risk model. An unattended agent reads untrusted content, such as email bodies, calendar invites, and issue comments, while holding your credentials. A malicious email could attempt a prompt injection that instructs the agent to read your inbox, send money, or delete files. The six agents in this article handle that danger very differently, so security is a bigger differentiator than model quality.

Proactive AI agents at a glance

Here is a quick comparison. The table captures where each agent runs, what starts it, and what you pay.

Agent	Runs on	Starts work via	Price and access
OpenAI Dots	OpenAI cloud computer, optional link to yours	Self-wake, scheduled tasks, read-only research	Pro from $100/month, Business Premium, Enterprise
Meta Muse	One Muse Secure VM per user	Background jobs, unprompted suggestions	Free tier, Power $20, Maximum $100; US only
Grok Bot	One shared computer per account, in Cursor's cloud	Routines on schedules or Slack, GitHub, email and webhook events	Beta, included with X and Cursor plans
Instinct	Instinct's own phone and computer	Texts you first with reminders	Early access, no public price
OpenClaw	Your machine (Node.js Gateway)	30-minute heartbeat, cron and event automations	Free, MIT; you pay for the model
Hermes Agent	Your machine (Python gateway)	Cron jobs, signed webhooks	Free, MIT; you pay for the model

One column deserves extra attention: credentials. Hosted agents hold some form of token, either in their cloud or in your browser. Open source agents load your API keys and service tokens on your machine. You should map that out before you connect your Gmail or GitHub. In the sections below, I cover each agent's trigger model, hosting, credentials, and security boundary.

OpenAI Dots: a coordinator that decides when to check back

OpenAI Dots feels like a coordinator rather than a chatbot. A dot lives in OpenAI's cloud with its own computer and browser. It runs on GPT-6 Astra and can pause and resume its own work, so follow-ups do not need a fixed schedule. If you ask for a morning brief in plain words, it schedules that task. The background research is read-only, and any follow-up action must have the applicable permissions. You can attach custom rules like Ask before taking action for outgoing email.

OpenAI's documentation does not mention webhook triggers. That means a new GitHub issue will not wake the dot instantly. The dot will notice it the next time it checks your connected apps, which can be minutes or hours later. For a developer this is a meaningful gap if you need event driven automation. Dots are better at coordination. They can hand work to ChatGPT Work and Codex, then chase each subtask until a result is ready. This is a useful pattern for research tasks that need multiple tools.

Pricing matters. Personal Pro starts at $100 per month and is not available in the EEA, UK, or Switzerland. You get one dot per account, so a power user might feel constrained. Enterprise and Business Premium plans have more room but are aimed at organizations.

Meta Muse: a second agent holds the keys

Meta Muse has the strongest security story on the hosted side. Every user receives a dedicated Muse Secure VM. The agent runs inside a systemd-nspawn container, and a separate host side component called Sentinel acts as a gate. Meta's documentation says: Muse proposes actions, but only Sentinel can grant permission to perform action. The agent never touches the real credentials. It holds surrogate tokens, and Sentinel swaps in the actual tokens at the network boundary.

Payments are handled with single-use Stripe Link cards, and each one needs your approval. This is a genuinely useful safety pattern for an always-on agent, because a hijacked agent cannot spend money without a fresh approval. Meta also makes a reasonable effort to keep the agent's filesystem constrained with systemd-nspawn.

Muse supports background cron jobs and unprompted suggestions, but there is no visual schedule screen and no event trigger in the user interface. You ask for your morning brief in chat and the agent runs it as a background job. It is available on the web, iOS, Android, and WhatsApp, but only in the United States. Even the free tier requires a payment card.

One caveat: Meta says staff access to user data is restricted by policy, not technically prevented. The company says a planned Muse Confidential VM will fix that, but it has not shipped yet. For a developer this is a proof point that hosted agents are fundamentally different from local ones.

Grok Bot: a team of bots on one shared computer

Grok Bot is the most trigger-rich hosted agent in this comparison. xAI launched it in beta on August 11, 2026, and describes it as a team of always-on agents. A routine can run on a schedule, a Slack mention, GitHub, Linear, Sentry, PagerDuty activity, email to the bot's address, or a webhook. That makes Grok Bot the only hosted agent here that can react to your GitHub issue instantly.

The catch is the computer. All of your Bots use the same cloud computer, sharing files, browser sessions, and app logins. That means a triage bot that reads a poisoned GitHub issue shares a browser session with a bot that handles your email. A prompt injection in an issue body could try to read a message from your Gmail session. xAI adds an independent Auto Review model for risky actions, and connector tokens are stored on Cursor's backend, but you are still relying on one shared trust boundary.

Grok Bot runs in Cursor's cloud, so it is bundled with X Premium plans and paid Cursor plans. The exact subscription tiers are The X Subscription Premium, Super, and Ultra, plus Cursor paid plans. There is no separate price at the moment. You should think of it as a feature of a broader plan rather than a standalone product.

Instinct: an agent you text, that texts you first

Instinct is different from all the others because there is no app. You interact with it by text or phone call. The company, Spear Street Technology, was founded by Noah Shinn. Instinct uses a phone and a computer in the same way you do. A hands-on review from October 25, 2026 describes how it checks in, keeps track of ongoing tasks, and reminds you to cancel a subscription. It has since added phone calls, its own email addresses, and group chats.

Instinct publishes very little about its trigger model. There is no public documentation for schedules, events, or approval workflows, except for purchases. Purchases use one-time Stripe Link cards for amounts you approve. If you want to connect Gmail, read the terms carefully. The revised terms say: You also authorize us to access, copy, collect, and index data from your Connected Services and You hereby appoint the Services as your agent to enter into agreements, commitments or transactions on your behalf. Training on your data is on by default, with an opt-out.

For a developer, Instinct is convenient but opaque. It can be genuinely proactive and the text interface is fun, but you are trusting a commercial service with a wide scope. If you are comfortable with that, it may save you time. If not, self-hosted agents are the better fit. There is also a configuraton detail that may matter: because Instinct is in early access, you cannot inspect its internal schedule or event pipelines.

OpenClaw: a heartbeat on your own Gateway

OpenClaw is the biggest open source project on this list. Version 2026.10.9, released on October 29, runs a Node.js Gateway on your machine. Automations run inside the gateway, so nothing fires while it is down. The gateway is the core pattern. It keeps a scheduler alive, executes jobs, and delivers messages through channels like Telegram.

The self-wake mechanism is the heartbeat. By default every 30 minutes the heartbeat runs an agent turn and messages your own DM. The checklist for the heartbeat now lives in a monitor scratch file, not the old HEARTBEAT.md. You can edit it with openclaw cron scratch <jobId> --set "...", and openclaw doctor --fix will migrate an old setup.

The morning brief is a separate isolated job. openclaw cron is an alias for openclaw automations. The command looks like this:

openclaw cron create "0 8 * * 1-5" \
  "Check my inbox and calendar. Tell me only what needs a decision today. If nothing does, reply NO_REPLY." \
  --name "Morning brief" --tz "Asia/Kolkata" --session isolated \
  --announce --channel telegram --to "123456789"

You can inspect your jobs with openclaw cron list --all:

Name             Schedule                           Target    Delivery

Heartbeat (dev)  every 30m                          main      not requested

Morning brief    cron 0 8 * * 1-5 @ Asia/Kolka...   isolated  announce -> telegram:123456789 (explicit)

If cron is not second nature, use a cron expression parser. One default I recommend changing is the tool allow list. The newly created job allows every tool with "toolsAllow": ["*"], so pass --tools with a narrower list. The --session isolated flag is also important; it keeps the brief from reading the heartbeat's scratch memory.

OpenClaw has a large ecosystem, but that breadth comes with maintenance burden. The OpenClawCVEs tracker counted 543 CVEs and 211 advisories on October 31, 2026. If you expose OpenClaw to the internet, you need a patching routine. Self-hosting means you own the risk.

Hermes Agent: cron jobs and signed webhooks

Hermes Agent is the other major self-hosted player, and for developers it has one of the clearest scheduler designs. Version 0.22.5, released October 23, runs its scheduler inside the gateway and ticks every 60 seconds. You can define schedules in plain English. Failed runs always deliver, so you never miss an alert because of a transient error. There is also a monitor mode with --monitor-url or --monitor-script that skips the LLM entirely when a cheap check's output has not changed. This is a nice cost optimization for jobs that poll an API or a website.

Setting up the morning brief in Hermes is straightforward:

hermes config set timezone Asia/Kolkata
hermes cron create "weekdays at 8am" \
  "Check my inbox and calendar. Tell me only what needs a decision today. If nothing does, reply [SILENT]." \
  --name "morning-brief" --deliver telegram

The gateway prints a confirmation:

Created job: 115c4cda804e

  Next run: 2026-11-02T08:00:00+05:30

Nothing runs until hermes gateway run is up. Set the time zone before creating jobs. In our test, changing the time zone after job creation did not move the stored next run. For the model side, you can run Hermes on free OpenRouter models if you want to keep costs near zero. This makes Hermes a good choice for experiments.

Triggering Hermes from GitHub through a Pinggy tunnel

This is where the developer experience gets concrete. Grok Bot gives you a webhook URL. OpenClaw can poll GitHub with its own automation. Hermes can only recieve webhooks on port 8644 of a machine with no public address, so you need a tunnel. The docs suggest setting WEBHOOK_ENABLED=true in ~/.hermes/.env, but in v0.22.5 the command hermes webhook subscribe refused with Webhook platform is not enabled until the flag was in config.yaml. Let me walk through the working setup.

First, enable the webhook platform and subscribe to the GitHub issues event:

hermes config set platforms.webhook.enabled true

hermes webhook subscribe github-issues --events "issues" \
  --prompt "New issue #{issue.number} in {repository.full_name}: {issue.title}. Triage it and tell me if it needs me today." \
  --deliver telegram

hermes gateway run

Subscribing prints a generated HMAC secret and http://localhost:8644/webhooks/github-issues. In a second terminal, create a secure tunnel with Pinggy:

ssh -p 443 -R0:localhost:8644 free.pinggy.io

Pinggy prints an HTTPS URL ending in .run.pinggy-free.link. Under your GitHub repository, go to Settings > Webhooks > Add webhook. Enter the Pinggy URL with /webhooks/github-issues, choose application/json, paste the secret, and select only the Issues event.

We tested teh path with a signed GitHub-style issues event. Our test gateway had no Telegram bot, so the --deliver telegram route answered 503 {"error": "Admission unavailable; retry this delivery"}. Connect the delivery channel first. With the route switched to --deliver log, a valid X-Hub-Signature-256 got HTTP 202 {"status": "accepted", ...} and the gateway logged the rendered prompt. A wrong signature got 401 {"error": "Invalid signature"}.

A free Pinggy tunnel expires after 60 minutes and gives you a new URL. For a persistent webhook, use the Pro token with a persistent subdomain: <token>@pro.pinggy.io. Our guide to receiving webhooks on localhost has more details. These steps were tested on October 31, 2026, with Hermes Agent v0.22.5.

How to choose a proactive agent

Choosing one agent depends on where your work lives and how much risk you are willing to take.

If your daily work lives inside ChatGPT and Codex, choose OpenAI Dots. It is the best coordinator for research tasks and follow-up work. The read-only research default is a good safety boundary. If you are in the US and want cheap errands, Meta Muse is the safest hosted option on paper. Sentinel's credential boundary is a genuinely thoughtful design.

If you want event-driven routines and are comfortable with a shared computer, Grok Bot is the strongest option. It is the only hosted agent in this list that can react to GitHub instantly. But you should not put secrets in the shared browser session if you can avoid it. If you only want to text with an agent, Instinct is compelling. It feels like an assistant with a phone. Just read the terms first.

For developers who want to own the infrastructure, OpenClaw has the biggest ecosystem and the largest community. It also has the most CVEs, so you need a patching routine. Hermes Agent has the clearest scheduler and webhook model, and its monitor mode can save money on polling jobs. I would start with Hermes if webhooks are your primary use case, and with OpenClaw if you want broad plugin coverage and a heartbeat style self-wake.

One more thing to watch: Anthropic's Claude Duet is a US waitlist preview that sends a morning brief and checks your apps every few hours. Google's Gemini Spark is also in the news. Both are worth evaluating when they reach stable access, but neither has a public trigger model yet.

Security checks before you plug in an agent

Whether you choose hosted or self-hosted, run through the same checklist before connecting an account.

What credentials does the agent hold? Hosted agents usually hold tokens server side. Self-hosted agents load locally.
Can the agent make irreversible changes? Look for approvals on send, pay, delete.
Does the agent have a quiet path? No NO_REPLY or [SILENT] means you will be spammed.
What events can wake it? Webhooks are fast but expose a public endpoint.
Is there a session isolation boundary? Grok Bot's shared computer is a warning sign.
Where is your data stored? Muse is US only, Dots excludes EEA, UK, and Switzerland for Personal Pro.
What happens when a prompt injection arrives? Test with a fake email or issue before pointing the agent at production accounts.

Troubleshooting common issues

The following issues came up during my testing. If you are setting up your own agent, you will probably hit at least one of them.

Webhook platform not enabled. Put platforms.webhook.enabled true in config.yaml, not just WEBHOOK_ENABLED in .env. The command parser reads the YAML config first, and the .env variable was not sufficient in v0.22.5.

Telegram delivery fails. The webhook accepted the event, but delivery returned a 503. Connect the delivery channel first. If Hermes cannot reach Telegram, it cannot deliver the rendered prompt.

Time zone changes do not move next run. Set the timezone before creating a scheduled job. Changing it afterwards left the old next run time in place in our test.

Free tunnel expires. The free Pinggy URL changes every 60 minutes. Use a persistent subdomain with a paid token for any webhook that needs to stay alive.

Heartbeat messages are too noisy. Increase the heartbeat interval or edit the monitor scratch so the agent only replies with NO_REPLY when nothing needs attention.

Tools allow list is too broad. In OpenClaw, the default toolsAllow is a wildcard. Pass --tools with a list of allowed tools. A brief only needs calendar, email, and delivery tools.

FAQ

Can I run OpenClaw and Hermes on the same machine? Yes. They use different gateways and different ports, so you can run both. You will need to decide which one owns the cron schedules for the same job, otherwise you might get duplicate briefs.

What is the difference between a heartbeat and a cron job? A heartbeat is a system-owned periodic pass that asks the agent whether anything needs attention. A cron job is a user-defined scheduled task with a fixed expression. Both are proactive, but a heartbeat is more flexible because the agent can choose to remain silent.

Do proactive agents work with offline data? No. They need an LLM to reason about your data. OpenClaw and Hermes call a model provider like OpenRouter or a local model server. If the model API is down, the job fails or waits for the next run.

How do I prevent prompt injection in a webhook? First, verify the webhook signature. In Hermes, the X-Hub-Signature-256 header must match the generated secret. Second, add a prompt instruction that tells the agent to ignore instructions inside the incoming content and only use the content as data. Third, use an allow-list of tools so the agent cannot call arbitrary tool operations.

What is the total cost of running OpenClaw? The software is free, but you pay for model API usage, a delivery channel, and your machine uptime. For a simple daily brief, the model cost can be less than a dollar per month if you use a small model. For more complex tasks with many tool calls, it can be a few dollars.

Conclusion

Whichever agent you pick, start small. Create one scheduled job that has a quiet path (NO_REPLY, [SILENT], or message me only if a decision is needed) and one event trigger. Turn on approvals for anything that sends, pays, or deletes. After one week, count how many of its messages you were glad to receive. That number is the real measure of proactivity.

The field is moving fast. Hosted agents are getting more secure, open source agents are getting easier to deploy, and new entrants like Claude Duet and Gemini Spark will force even better defaults. For developers, the best move is to build a reproducible setup with the agent that matches your own trigger, credential, and privacy requirements. Keep your delivery channel connected, keep your tools allow-listed, and always test with signed payloads before you let the agent talk to your real accounts.

Reference

Proactive AI Agents Compared: Dots vs Muse vs Grok Bot vs Instinct vs Hermes vs OpenClaw (2026)

Webhook Testing on Localhost: Tunnels, Signatures, and Reliable Replays

Lightning Developer — Wed, 04 Nov 2026 02:34:00 +0000

When a service wants to tell your application about an event, it does not wait for you to ask. It sends an HTTP POST to a URL that you registered. A payment clears, a pull request opens, an order ships, and the provider calls your endpoint. This pattern is called a webhook, and it is everywhere.

The problem is that the URL has to be reachable from the public internet. During development, your application runs on localhost:3000, behind a home router or an office NAT. GitHub, Stripe, and Slack cannot reach that address. To test webhooks locally, you need two things: a temporary public URL that forwards to your local port, and a handler that only trusts requests that were genuinely signed by the provider.

This guide follows one example from start to finish. You will receive a GitHub repository webhook in an Express handler on port 3000 through a Pinggy tunnel. Stripe, Slack, and Shopify work the same way, with only the signature details changing. The code and tests in this article were run on Node.js 25.5 with Express 5.3.0 in October 2026.

Key points

One command gives localhost a public URL. ssh -p 443 -R0:localhost:3000 free.pinggy.io prints an HTTPS address that forwards to port 3000. Free tunnels last 60 minutes and get a new random URL each time. A Pro token keeps one subdomain.
Verify the signature on the raw bytes. GitHub signs the exact request body with HMAC-SHA256 and sends it in X-Hub-Signature-256. Read the body with express.raw(), never express.json(), and compare with crypto.timingSafeEqual.
Reply fast and expect repeats. GitHub waits 10 seconds and never retries automatically. Shopify waits 5 seconds and retries 8 times over 4 hours. Return a 2XX first, queue the work, and skip delivery IDs you have already handled.
Replay instead of re-triggering. Pinggy Web Debugger, started with -L4300:localhost:4300, shows every delivery and can resend it as-is or with edited headers.
Skip the tunnel when the provider ships a CLI. stripe listen and gh webhook forward deliver events to localhost without a public URL.

How a webhook reaches localhost:3000

Nothing on your router changes. Your laptop makes the first connection outward. An SSH client dials Pinggy on port 443 and asks it to forward a public URL back down that connection. When GitHub POSTs to the URL, the request follows a path: GitHub to Pinggy, then through the SSH connection your laptop opened, then to localhost:3000. The handler's response travels back along the same path.

Because the laptop starts the connection, this approach also works behind CGNAT. With CGNAT, your router does not have a public IP address, so port forwarding cannot work from the outside. A reverse tunnel does not care. It only needs an outbound connection from your machine to the tunnel server.

Free Pinggy URLs show a one-time screening page, but only to browsers. Webhook senders, curl, and HTTP libraries go straight through to your handler. That means a tunnel is safe to use for webhook testing as long as you enforce a signature check.

Why signature verification is non-negotiable

A public tunnel URL is guessable. It may be a random subdomain, but attackers scan subdomains and IP ranges all the time. If your endpoint accepts any request without verifying a signature, anyone can send a fake event. They could trigger a build, mark an order as paid, or spam your logs. Signature verification is the only reliable way to know that a request came from the provider.

Providers do not all use the same cryptographic primitive, but the pattern is similar. They compute a digest of the request body and a secret, put the digest in a header, and send the request. Your handler recomputes the digest and compares it with the header. If they match, you can trust the body. If they do not, reject the request with 401 Unauthorized.

This is not a theoretical concern. When you open a tunnel, your local endpoint is on the public internet. Attackers can hit it within minutes. A signature check costs a few lines of code and saves you from a long debugging session.

Understanding the signature header

The X-Hub-Signature-256 header is not just a hex string. It is prefixed with sha256=. Some older integrations use X-Hub-Signature, which is the SHA-1 version. GitHub still accepts both for compatibility, but its documentation recommends the SHA-256 header for new integrations. If you only check the legacy header, a delivery signed with SHA-256 would fail. If you only check the SHA-256 header, old tooling will be rejected. For a fresh webhook, you should choose X-Hub-Signature-256 and ignore the legacy header.

When you construct the expected value, use the same prefix. The code does 'sha256=' + ..., which matches what GitHub sends. Some developers forget the prefix and then wonder why every request returns 401. The header also uses lowercase hex characters. You do not need to normalize case if you compute the digest with digest('hex'), because Node.js returns lowercase. If you use uppercase, you would need to lowercase before comparison.

Trust boundaries and tunnels

Even with a signature check, the tunnel is part of your trust boundary. Anyone who can reach the tunnel URL can send requests to your handler. They will fail the signature check, but the request still reaches your Node.js process. This means you should not rely on the signature check alone to protect against denial-of-service. A malformed request without an X-Hub-Signature-256 header is rejected after a quick length check, but parsing the body and logging it costs CPU and memory.

Pinggy free tunnels include a one-time browser warning page. This is not a security mechanism for webhooks. It only exists to stop a random person from opening the URL in a browser and seeing your local app. Automated clients, including webhook providers and attackers, skip it. Keep your handler behind a signature check even if you are only testing.

Source IP restrictions are tempting, but unreliable for GitHub because its IP ranges change. For Stripe, the published IP ranges are more stable, and you could combine an allowlist with the signature. Defense in depth is nice, but the signature is the primary control.

Step 1: Write a handler that checks the signature

GitHub computes an HMAC-SHA256 of the request body using a secret you choose. It sends the hex digest in the X-Hub-Signature-256 header, prefixed with sha256=. Your handler recomputes that value and compares the two.

Set up a folder and generate a secret:

mkdir webhook-demo && cd webhook-demo
npm init -y && npm install express
openssl rand -hex 32

The command uses OpenSSL to generate a random 64-character hex string. Copy the output. GitHub will need the same value later. Save the handler as server.mjs:

import express from 'express';
import crypto from 'node:crypto';

const app = express();
const SECRET = process.env.GITHUB_WEBHOOK_SECRET;
const seen = new Set();

app.post('/webhook', express.raw({ type: 'application/json' }), (req, res) => {
  if (!Buffer.isBuffer(req.body)) {
    return res.status(415).send('expected a raw application/json body');
  }

  const expected =
    'sha256=' + crypto.createHmac('sha256', SECRET).update(req.body).digest('hex');
  const received = req.get('X-Hub-Signature-256') ?? '';

  const a = Buffer.from(expected);
  const b = Buffer.from(received);
  if (a.length !== b.length || !crypto.timingSafeEqual(a, b)) {
    return res.status(401).send('bad signature');
  }

  const delivery = req.get('X-GitHub-Delivery');
  if (seen.has(delivery)) return res.sendStatus(200);
  seen.add(delivery);

  const event = req.get('X-GitHub-Event');
  const payload = JSON.parse(req.body.toString('utf8'));
  console.log(event, payload.action ?? '', delivery);

  res.sendStatus(202);
});

app.listen(3000, () => console.log('Listening on http://localhost:3000'));

Start the server with the secret in the environment. The --watch flag restarts it when you edit the file:

GITHUB_WEBHOOK_SECRET='paste-the-secret-here' node --watch server.mjs

Why `express.raw()` matters

The signature covers the exact bytes GitHub sent. express.json() parses the body into a JavaScript object and then serializes it again when you need the raw string, which can change whitespace, escape characters, or Unicode normalization. The digest from the provider will stop matching. express.raw({ type: 'application/json' }) gives you the body as a Buffer before any parsing. You verify the signature on those raw bytes and only then parse the JSON.

The length check before crypto.timingSafeEqual is also important. Node.js throws ERR_CRYPTO_TIMING_SAFE_EQUAL_LENGTH when the two buffers differ in size, which happens when the header is missing. Comparing lengths first avoids the exception and avoids leaking the expected length through timing.

Duplicate deliveries

A redelivery keeps the same X-GitHub-Delivery header. GitHub's documentation states that if you request a redelivery, the delivery ID stays the same. The handler uses an in-memory Set to skip repeats. This is perfect for a demo. It is wrong for production, because it forgets everything on restart and does not work across multiple instances.

In a real system, insert the delivery ID into a table with a unique index in the same transaction as the work. If a duplicate arrives, the insert fails with a unique constraint violation and you know the event was already handled. This is the same idempotency strategy used by payment providers and other webhook-heavy services.

The reply window

GitHub waits 10 seconds for a 2XX response. If the handler takes longer, GitHub cuts the connection and records the delivery as failed. That is why the handler responds with 202 Accepted as early as possible. Slow operations, such as sending emails or updating a search index, should go to a queue. The code above only logs, but in a real application you would enqueue a background job before returning the response.

Test the handler locally before GitHub

You can sign a request yourself with openssl and send it to the handler. This tests the exact same code path that GitHub will use, without involving GitHub.

BODY='{"zen":"Design for failure.","hook_id":123}'
SIG="sha256=$(printf '%s' "$BODY" | openssl dgst -sha256 -hmac "$GITHUB_WEBHOOK_SECRET" | awk '{print $NF}')"

curl -i http://localhost:3000/webhook \
  -H 'Content-Type: application/json' \
  -H 'X-GitHub-Event: ping' \
  -H 'X-GitHub-Delivery: test-1' \
  -H "X-Hub-Signature-256: $SIG" \
  --data "$BODY"

Run this in a terminal where GITHUB_WEBHOOK_SECRET is set to the same value. The first call returns 202 Accepted. Calling the same command again returns 200 OK because the delivery ID repeats. If you change one character in BODY after computing SIG, the handler returns 401 Unauthorized. Those three outcomes prove that the handler accepts valid requests, rejects invalid signatures, and deduplicates redeliveries.

Step 2: Open the tunnel

Open a second terminal and point a tunnel at port 3000:

ssh -p 443 -R0:localhost:3000 free.pinggy.io

If SSH asks for a password, press Enter. Pinggy prints the tunnel's public URLs, including an HTTPS address shaped like this:

https://uljtt-30-47-152-61.run.pinggy-free.link

Copy that URL. You can build a custom command on the Pinggy website as well.

Free tunnels last 60 minutes and get a new random subdomain every time they start. After a restart, you must paste the new URL into GitHub again. With a Pinggy Pro token, tunnels have no 60-minute limit and you can assign a persistent subdomain from the dashboard. This is helpful when you need a stable webhook URL for several days of development.

The URL is public while the tunnel is running. The signature check is what keeps out requests that GitHub did not sign. Pinggy can also limit a tunnel to specific source IPs with the w: option, but GitHub advises against using IP allowlists for webhooks because its IP ranges change from time to time. Trust the signature, not the source address.

Choosing a stable tunnel URL

For a long integration project, a rotating free URL becomes annoying. Every time the tunnel restarts, you have to edit the GitHub webhook settings and wait for the next test event. A persistent subdomain removes that churn. Pinggy's Pro tier gives you a fixed URL that remains the same across tunnel restarts, which is much easier to put in your local .env file or your webhook configuration.

There is also a practical benefit for the Web Debugger. If you keep the same tunnel URL, the debugger history accumulates across multiple handler restarts, giving you a record of how the provider's requests evolved. With a new URL each time, you lose that history and have to start over.

Step 3: Point the GitHub webhook at the tunnel

Inside the repository, open Settings, then Webhooks, then Add webhook. Fill in the form:

Payload URL: the HTTPS tunnel URL plus /webhook, for example https://uljtt-30-47-152-61.run.pinggy-free.link/webhook.
Content type: application/json.
Secret: the same value you put in GITHUB_WEBHOOK_SECRET.
Events: choose Let me select individual events and tick the events your code handles.

Save the webhook. GitHub sends a ping event immediately. The terminal running node --watch prints ping followed by the delivery ID. The Recent deliveries tab on the GitHub webhook page shows the full request, the response status, and a Redeliver button.

Trigger one of the events you selected, such as pushing a commit if you chose push. You will recieve the real event in the same way as the ping. At this point, the entire loop is working: GitHub sends to Pinggy, Pinggy forwards over SSH to localhost, and your handler verifies and responds.

Step 4: Inspect and replay deliveries with the Web Debugger

GitHub's delivery log only covers GitHub. Pinggy's Web Debugger shows every request that hits the tunnel, regardless of the sender. To enable it, add one extra flag to the tunnel command. Since a restarted free tunnel gets a new URL, update the payload URL in GitHub after restarting:

ssh -p 443 -R0:localhost:3000 -L4300:localhost:4300 free.pinggy.io

Open http://localhost:4300 in a browser. Every request appears live with its headers, body, and your handler's response.

The Web Debugger has two powerful actions. Replay resends a captured delivery exactly as it arrived. This is the quickest way to verify duplicate handling: a replayed GitHub delivery should get 200, not a second 202, as long as the server has not restarted and the in-memory Set is still populated. Modify and Replay lets you change the method, path, HTTP version, or any header before resending. You can, for example, corrupt the X-Hub-Signature-256 header and confirm that the handler answers 401. That gives you a way to test both success and failure paths without waiting for GitHub to send anything new.

Other providers: same handler, different header

The handler structure stays the same across providers. The basic configuraton stays the same. The signature header, the signed string, and the reply window change.

Provider	Signature header	What gets signed	Reply within	Retries
GitHub	`X-Hub-Signature-256`, `sha256=` + hex	Raw body	10 seconds	None automatic; redeliver from UI or API within 3 days
Stripe	`Stripe-Signature`, `t=...,v1=...`	`timestamp.body`	No documented number, quickly	Up to 3 days in live mode, 3 times over a few hours in a sandbox
Slack (Events API)	`X-Slack-Signature`, `v0=` + hex	`v0:timestamp:body`	3 seconds	3 retries, numbered in `X-Slack-Retry-Num`
Shopify	`X-Shopify-Hmac-SHA256`, base64	Raw body	5 seconds	8 times over 4 hours

Stripe and Slack mix a timestamp into the signed string. A handler that checks the timestamp can reject a captured request replayed later. Stripe's official libraries allow a 5 minute tolerance by default. Slack's documentation says to ignore any request more than five minutes off your local time.

Use the provider's official SDK when one exists. Stripe's Node.js library has constructEvent, which parses the header, checks the timestamp, and compares signatures in constant time. Writing your own HMAC code for Stripe is more error prone because you also have to validate the timestamp scheme and version. The same advice applies for Slack's signing secret and Shopify's HMAC header.

Raw bodies in every framework

The raw body rule applies no matter which framework you use. It just looks different.

In Fastify, register a JSON content-type parser with { parseAs: 'buffer' } so the route receives a Buffer.
In a Next.js App Router route handler, await request.text() returns the unparsed body, which is what Next.js's own webhook example uses.
In Hono, await c.req.text() gives you the body string before any JSON parsing.

Whatever framework you choose, verify the signature before calling JSON.parse. If you parse first, you might accidentally mutate the data and break the signature, or you might expose yourself to attacks that exploit the parser before authentication.

Retry semantics and backoff

Webhook providers have different retry policies. Some retry with exponential backoff, some retry at fixed intervals, and some do not retry at all. The table above summarizes the most common ones. When a provider does retry, you may see the same event arrive multiple times. Your delivery ID deduplication should use a stable identifier that the provider documents. The raw body is not a good idempotency key because two separate events can have identical bodies.

Webhooks can also arrive out of order. If your handler processes order.shipped before order.paid, your application state may be wrong. Use event timestamps or version fields inside the payload to maintain ordering where it matters. Queue consumers should expect at-least-once delivery, so idempotency is not an option, it is a requirement.

When you don't need a tunnel

Some providers ship a CLI that pushes events directly into localhost over an outbound connection. No public URL is needed.

Stripe's CLI is the most polished example. Install it with one of these commands:

npm i -g @stripe/cli@latest
# or
brew install stripe

Then log in and start forwarding:

stripe login
stripe listen --forward-to localhost:3000/webhook

The CLI prints a whsec_ signing secret that stays the same between restarts. You can set it as STRIPE_WEBHOOK_SECRET in your environment and use stripe trigger checkout.session.completed to fire a test event whenever you want one.

GitHub has a similar extension for the GitHub CLI. Install it with:

gh extension install cli/gh-webhook

Then use gh webhook forward to stream repository or organization events to a local URL. Note that only one person can forward a given repository at a time.

GitHub's documentation also still mentions smee.io, a relay that streams payloads to a client over Server-Sent Events. Its README warns that channels are not authenticated, so anyone with the channel URL can read the payloads. That makes it acceptable for a quick test, but not for sensitive data.

Slack apps can avoid a public URL entirely by using Socket Mode. Events arrive over a WebSocket instead of a Request URL. However, Socket Mode apps are not allowed in the public Slack Marketplace, so this only works for internal apps.

A tunnel stays the fallback for the long tail of providers that have no CLI. There is a separate comparison of provider CLIs versus tunnels for webhook testing, but the pattern is usually the same: if your provider has a CLI, use it; if not, open a tunnel.

Hosted inspectors and production gateways

If you only want to see what a provider sends before writing any code, a hosted inspector is faster than a tunnel or CLI. Webhook.site gives you a URL instantly. Free URLs accept up to 100 requests, expire after 7 days, and anyone who knows the URL's ID can read what was sent. Hookdeck has an inspect mode that requires no account and keeps captured requests for 3 days. RequestBin now redirects to Pipedream, so older guides that mention RequestBin are out of date.

For production, where a missed event can cost money, a receiving gateway is a better choice. Services like Svix, Hookdeck, or Convoy sit in front of your application and handle buffering, retries, and replay. Convoy is self-hostable under the Elastic License 2.0, so it is source-available rather than open source. A gateway can protect you from provider retry storms and gives you an audit log of every delivery.

Production hardening

The demo handler is intentionally small. In production, you should also do the following:

Use a database-backed deduplication table instead of a Set.
Store the signing secret in a secret manager, not in an environment variable hardcoded in a shell command.
Add request timeouts and circuit breakers for outbound calls.
Log the delivery ID, event type, and signature status in a structured format.
Set up metrics for webhook latency, error rate, and duplicate rate.
Run the handler behind a reverse proxy that limits request size and rate limits by source IP.

These practices matter because webhook providers can send bursts of events. A simple controller that handles 1 request per second may fail when a provider sends 100 events after a bulk operation.

Handling large payloads

Some webhook bodies are large. GitHub repository events can include many commits. Shopify product updates can be several megabytes. express.raw() buffers the entire body in memory. For most webhooks this is fine. If you expect very large payloads, you need a different strategy. You can stream the request body to disk while computing the HMAC, but you cannot verify the signature until the whole body is read. The provider also has a maximum body size. GitHub limits webhook payloads to 25 MB, and Stripe's limit is lower. For local testing, the default memory limit is fine.

Graceful shutdowns

When the tunnel closes, the handler may still receive in-flight requests. Implement a graceful shutdown that stops accepting new connections, waits for existing requests to finish, and closes the database pool. This is especially important if you are testing delivery semantics with a CLI that retries.

A minimal CI workflow for webhook handlers

Once the local curl checks pass, add them to CI. You can write a small test that starts the server, sends a signed request, and asserts on the response. Here is a minimal example using Node's built-in test runner and global fetch:

import { createHmac } from 'node:crypto';

const secret = process.env.TEST_SECRET;
const body = JSON.stringify({ action: 'opened', issue: { number: 1 } });
const signature = 'sha256=' + createHmac('sha256', secret).update(body).digest('hex');

const response = await fetch('http://localhost:3000/webhook', {
  method: 'POST',
  headers: {
    'content-type': 'application/json',
    'x-github-event': 'issues',
    'x-github-delivery': 'test-delivery-1',
    'x-hub-signature-256': signature,
  },
  body,
});

assert.equal(response.status, 202);

Add a second test that corrupts the signature and expects 401, and a third that sends the same delivery ID twice and expects the second response to be 200. These three tests will protect you from the most common webhook regressions: missing raw body, broken signature comparison, and duplicate handling.

Troubleshooting

Every delivery gets 415

Your handler did not receive raw JSON bytes. Either the GitHub webhook content type is set to application/x-www-form-urlencoded, or a global app.use(express.json()) runs before the webhook route and consumes the body first. Mount express.raw() on the webhook route only, exactly as in the code above.

Every delivery gets 401

The secret in GitHub and the one in GITHUB_WEBHOOK_SECRET differ. Common causes are a trailing newline when you pasted the value, a leading or trailing space, or a stray quote. Compare the two values with wc -c and od -c, then use the Redeliver button in GitHub to send a fresh delivery.

GitHub reports a timeout or failed delivery

Either the handler took longer than 10 seconds, or the tunnel was down when GitHub sent the request. GitHub does not retry failed deliveries by itself. Fix the cause and click Redeliver in Recent deliveries. Deliveries from the past 3 days are listed there.

Deliveries stopped after an hour

The free tunnel hit its 60-minute limit. Restart it and update the payload URL in GitHub, or use a Pro token with a persistent subdomain.

Nothing shows up at all

Check that the payload URL ends with /webhook and uses the HTTPS address. If the Web Debugger shows no request, GitHub never reached the tunnel. If it shows the request, the problem is on teh local side, in the route or handler.

Curl works but GitHub does not

The most common difference is content type. GitHub sends application/json when configured, but the signature header is case sensitive. Also check whether the secret string contains a newline. openssl rand -hex 32 does not add a newline, but some terminal copy operations do.

Practical debugging tips

When a webhook handler misbehaves, the fastest way to find the problem is to compare what the provider sent with what the handler received. Log the raw body length, the event type, and the signature header value. Log the delivery ID too; support requests are much easier to investigate when you can search by that value.

You can also add a temporary console.log before and after JSON.parse to see whether the body is a Buffer or a string. Many 415 errors come from the route not receiving the raw body because a global JSON parser ran first. A quick log of typeof req.body and Buffer.isBuffer(req.body) will tell you which one it is.

Use the Web Debugger's Modify and Replay feature to test edge cases. Change the Content-Type header to text/plain, remove the signature header, or swap the delivery ID to a fresh value. Each test gives you a deterministic response without touching GitHub.

Conclusion

Receiving webhooks on localhost comes down to a public URL that forwards to your local port and a handler that refuses anything it cannot verify. Once you get the loop working with GitHub's ping event, turn the curl checks from Step 1 into automated tests. A correctly signed request returns 202, a repeat returns 200, and a wrong signature returns 401. Keep those tests in CI.

A global JSON parser added months later will turn every real delivery into a 415 error. A test that sends a raw body and expects 202 catches that regression before production does.

The same mental model applies to Stripe, Slack, Shopify, and everyone else. Learn the raw body rule, learn the signature header, and learn the retry window. If you can handle GitHub webhooks locally, you can handle the others.

Reference

How to Receive and Test Webhooks on Localhost

Proactive AI Agents in 2026: A Practical Comparison of Dots, Muse, Grok Bot, Instinct, OpenClaw, and Hermes

Lightning Developer — Tue, 03 Nov 2026 05:18:19 +0000

An AI assistant that only answers when you type is easy to reason about, because nothing happens until you ask. The new generation of personal agents intentionally breaks that rule. That changes what you should check before handing one your inbox.

Between August 11 and October 21, 2026, xAI shipped Grok Bot, Meta shipped Muse, OpenAI shipped OpenAI Dots, and Anthropic previewed Claude Duet. All of them are built to keep working after you close the app and to message you first. Instinct, an agent you reach by text, was valued at $10 billion by October. The open source side got there earlier: OpenClaw (393,525 GitHub stars on October 31) runs a heartbeat every 30 minutes by default, and Hermes Agent (259,065 stars) runs cron jobs and signed webhooks on your own machine.

Below, six agents are compared on triggers, hosting, credentials, and price. The running example is a weekday 8 AM brief that speaks up only when a decision is needed, plus a new GitHub issue. Facts were checked, and the OpenClaw and Hermes commands run in clean Docker containers, on October 31.

Why proactive agents appeared now

The shift became possible because model latency dropped enough for an agent to run many turns quietly. A generation ago, an AI assistant had to wait for a user prompt because the cost of running a background loop was too high. Now, a frontier model can process an inbox, summarize a calendar, and decide whether to send a message in under a minute. The missing piece was not intelligence. It was permission to start a turn on its own.

Proactive agents also benefit from better tool integration. They can read Gmail, Slack, GitHub, and calendar APIs through connectors. They can run browser sessions. They can execute code. This makes them useful for real work, but it also expands the attack surface. The industry is still learning how to build safe versions of these systems.

Another driver is the API-native nature of these agents. Many of them are built on top of the same model providers and use the same webhook primitives that developers already understand. That is why a developer can set up a self-hosted agent with a GitHub webhook in a few minutes. The barrier to entry is much lower than it was a year ago.

What makes an AI agent proactive

An agent is proactive when it starts a turn without a new message from you. The trigger can be a schedule, which usually means a cron expression. It can be an event, such as a webhook, a Slack mention, or a push from GitHub. It can also be a self-wake, where the agent decides when to look again or runs a periodic pass that asks whether anything needs attention.

The self-wake is the new part, and it only works if the agent is allowed to say nothing. OpenClaw's default heartbeat prompt ends with 'If nothing needs attention, reply NO_REPLY'. Hermes skips delivery when a cron job's final response contains [SILENT]. This quiet path is important. If the agent always replies, it becomes spam, and you quickly learn to ignore it. A good proactive agent should send fewer messages, not more.

The other change is risk. An unattended agent reads untrusted text, like email messages and GitHub issue bodies, with your logins loaded. That changes the threat model. A prompt injection in an email can reach the agent's tools. The agent may not be sophisticated enough to understand that a requested action is malicious. It might send email, create issues, or update records based on text it was never explicitly asked to process. That is why every serious proactive agent now has some kind of approval layer, sandbox, or credential separation.

There is also a distinction between agent orchestration and agent execution. A proactive agent can be a coordinator that decides what needs to be done and delegates to other agents. Or it can be a single agent that performs the task itself. OpenAI Dots leans toward coordination. Grok Bot is more of a team of agents that share one environment. Hermes and OpenClaw are closer to traditional automation frameworks with an LLM in the loop. Understanding these differences matters because they affect where credentials live and how much damage a compromised agent can do.

Another important concept is delivery. A proactive agent needs a channel to reach you. Telegram, Slack, email, SMS, and WhatsApp are all common. Some agents use their own notification system. The delivery channel is not just a UX detail. It is also an attack surface. If an attacker can spoof the channel, they can inject messages into the agent's context. Some systems solve this by using signed webhooks and authenticated channels. Others rely on the provider's infrastructure.

A quick look at the field

Before comparing the six, it helps to see them side by side. The table below summarizes the main options. It is not exhaustive, but it captures the differences that matter for most developers.

Agent	Runs on	Starts work via	Price and access
OpenAI Dots	OpenAI cloud computer, optional link to yours	Self-wake, scheduled tasks, read-only research	Pro from $100/month, Business Premium, Enterprise
Meta Muse	One Muse Secure VM per user	Background jobs, unprompted suggestions	Free tier, Power $20, Maximum $100; US only
Grok Bot	One shared computer per account, in Cursor cloud	Routines on schedules or Slack, GitHub, email and webhook events	Beta, included with X and Cursor plans
Instinct	Instinct's own phone and computer	Texts you first with reminders	Early access, no public price
OpenClaw	Your machine (Node.js Gateway)	30-minute heartbeat, cron and event automations	Free, MIT; you pay for the model
Hermes Agent	Your machine (Python gateway)	Cron jobs, signed webhooks	Free, MIT; you pay for the model

There are two broad families here. Hosted agents run on the vendor's computer. That means they can work while your laptop is closed. Open source agents run on your own machine, so they only work when the gateway is running. Both families have security tradeoffs. Hosted agents keep your data on someone else's infrastructure. Self-hosted agents require you to secure your own box and handle secrets carefully.

Hosted versus self-hosted tradeoffs

Hosted agents are attractive because they ask for very little technical setup. You click a button, connect an account, and the agent starts running. The provider handles uptime, scaling, patching, and model updates. The downside is that you are trusting the provider with your data. Even with strong encryption in transit, the provider can access your content if it chooses to. Some providers offer enterprise contracts with data processing agreements. Others do not.

Self-hosted agents require more work. You need a machine that stays on. You need to install the gateway, manage dependencies, and keep it updated. You need to decide how to expose webhook endpoints. You also need to handle your own secrets. In exchange, you have full visibility into what the agent does. You can inspect logs. You can modify the source code. You can add your own security controls.

There is also a middle path. You can run a self-hosted agent on a cloud VM and let it communicate with the world through a tunnel like Pinggy. That gives you the privacy of your own server and the convenience of a public URL. It does not solve the patching problem, but it solves the network problem.

OpenAI Dots: a coordinator that decides when to check back

OpenAI Dots lives in OpenAI's cloud with its own computer and browser. It runs on GPT-6 Astra and decides when to pause and resume. Follow-ups need no fixed schedule. Its background research is read-only, and follow-up actions need the applicable permissions. You ask for the brief in plain words with a time zone and an end date, and it appears under Scheduled. Actions pass through your custom rules, such as 'Ask before taking action' for outgoing email.

OpenAI's docs describe no webhook triggers, so the GitHub issue waits until the dot next checks your apps. Its strength is coordination: it hands work to ChatGPT Work and Codex and chases each job. It is a supervisor agent rather than a simple task runner. The dot model is interesting because it can decide to go do research, come back, wait for a while, then continue. This is different from a cron job that fires at a fixed time.

Personal Pro excludes the EEA, UK and Switzerland, and you get one dot per account. The price is high, so this is aimed at professionals who already live inside OpenAI's ecosystem. In practice, Dots feels like a managed chief of staff. It can prepare briefings, monitor dashboards, and keep an eye on projects. It is not designed for event-driven automation in the same way as Grok Bot.

One of the things to understand about Dots is that the environment is ephemeral but persistent enough for long-running tasks. It has a browser, a file system, and access to GPT-6 Astra's reasoning. The read-only research mode is a strong safety feature. It means the dot can browse the web and read your connected apps, but it cannot modify anything unless you grant a specific permission for that action. This is a different security tradeoff from giving a bot full access to a shared computer.

A common question is whether Dots can react to external events. The answer in late 2026 is no, at least not through webhooks. It can poll apps on a schedule, but if an urgent issue arrives at 9:17 AM, you may not hear about it until the dot's next scheduled pass. That is fine for a morning brief, but it is not fine for incident response.

Another detail is the custom rules engine. You can define rules that require approval before the dot performs certain classes of action. This is a useful control, but it depends on the user writing good rules. If you allow outgoing email without approval, the dot can send email based on its own judgment. You should start with conservative rules.

Meta Muse: a second agent holds the keys

Meta Muse gives each user a dedicated cloud VM. Meta's security write-up is the most detailed of the six. The agent runs in a systemd-nspawn container, and a separate host-side agent called Sentinel decides what it may do. The key quote from the write-up is 'Muse proposes actions, but only Sentinel can grant permission to perform action.'

Muse holds only surrogate tokens. Sentinel swaps in real credentials at the network boundary. Payments use single-use Stripe Link cards, each needing your approval. This is a meaningful design improvement over agents that store your real access tokens inside the agent context. Even if the Muse container is compromised, it does not directly hold your Google or Microsoft credentials. It has to ask Sentinel, which can enforce policy, rate limits, and user consent.

Meta says Muse runs cron jobs in the background and makes unprompted suggestions, but describes no schedule screen or event triggers. You ask for the brief in chat. It runs on the web, iOS, Android and WhatsApp. It is US only, and needs a card even on the free tier. Meta also says staff access to user data is restricted by policy, not technically prevented, until a planned 'Muse Confidential VM' ships.

The lack of a visible schedule screen is not a deal breaker for everyone. You can still say 'every weekday at 8 AM, check my inbox and calendar' in natural language, and Muse will set up a background job. The problem is discoverability and control. With no event triggers, you cannot make Muse react to a GitHub issue. You can only ask it to check periodically. For many users, that is enough.

Muse's pricing tier starts with a free tier, then Power at $20, and Maximum at $100. The VM per user is a strong privacy feature because it prevents cross-tenant inference. But it also means Meta cannot cheaply scale to millions of users. The requirement to add a card on the free tier is likely to reduce abuse.

A useful mental model for Muse is that the agent is not the principal. The user is the principal, and Sentinel acts as a policy enforcement point. This is similar to how a service account works in cloud security. The agent can propose, but it cannot act without authorization. This separation is worth emulating in your own agent projects.

Grok Bot: a team of bots on one shared computer

xAI launched Grok Bot in beta on August 11 as 'a team of always-on agents', with the most explicit triggers of the hosted group. A routine runs on a schedule, at least five minutes apart, or on a Slack mention, GitHub, Linear, Sentry or PagerDuty activity, email to the bot's address, or a webhook. It is the only hosted agent here that reacts to our GitHub issue instantly.

The catch is the computer. xAI says 'All of your Bots use the same cloud computer, sharing its files, browser sessions, and app logins.' It runs in Cursor cloud. A triage bot reading a poisoned issue shares your inbox bot's Gmail session. This is a serious security consideration. If one bot is compromised, all bots on the same account share the same environment.

xAI adds an independent Auto Review model for risky actions. Connector tokens are kept on Cursor's backend, and passwords are filled by reference. These controls reduce the risk of the shared computer, but they do not eliminate it. The shared computer means that any file written by one bot is visible to another bot. If a workflow requires isolation, Grok Bot is not the right choice.

Grok Bot comes with The X Subscription's Premium, Super and Ultra plans and paid Cursor plans. It is in beta. The breadth of triggers is impressive. GitHub, Slack, Linear, Sentry, PagerDuty, and generic webhooks cover most developer workflows. For teams that already use these tools, Grok Bot can act as a central automation hub. It can triage issues, respond to incidents, and send summaries to a Slack channel.

The 'at least five minutes apart' limit is worth noting. You cannot run a cron job every minute. This is probably to prevent abuse and to keep costs manageable. If you need sub-minute scheduling, a self-hosted agent like Hermes or OpenClaw is better.

The shared computer model also has implications for secrets. Because all bots share browser sessions, a login to a third-party service is available to every bot. The Auto Review model can intercept risky actions, but the model itself is an additional system that must be audited. If you use Grok Bot, you should carefully define which bots can access which tools. The provider's documentation does not currently allow per-bot isolation.

Instinct: an agent you text, that texts you first

Instinct has no app. You text or call it, and it can use a phone and computer in the same way that you do. The company, Spear Street Technology, Inc., was founded by Noah Shinn. A hands-on review from October 25 says it 'checks in, keeps track of ongoing tasks, and takes the initiative to remind you to cancel a subscription.' It has since added phone calls, its own email addresses, and group chats.

Instinct publishes no trigger model. There are no docs on schedules, events, or approvals beyond purchases. Purchases use one-time Stripe Link cards for amounts you approve. Before connecting Gmail, you should read its terms. The terms were revised August 26, 2026. They include language like 'You also authorize us to access, copy, collect, and index data from your Connected Services' and 'You hereby appoint the Services as your agent to enter into agreements, commitments or transactions on your behalf.' Training on your data is on by default, with an opt-out.

For a developer, Instinct is the least transparent option. It is also the most consumer friendly. There is no app to install, no dashboard to configure, no API. You just text it. That makes it ideal for non-technical users, but it also makes it hard to audit. If you care about knowing exactly what the agent can do, Instinct is a risk.

The $10 billion valuation in October shows how much investor interest there is in proactive agents. Even without a public pricing page or a detailed security model, Instinct has captured attention. The service is in early access. Early users report that the agent is good at following up on tasks it has seen in text messages. It can set reminders, monitor ongoing conversations, and send proactive suggestions.

From an architecture perspective, Instinct likely runs on its own phone and computer infrastructure. The agent has a phone number and can send SMS messages. When you send a message, the agent parses it and may start a task. Later, it can initiate a text to you. This is a different model from a cloud workspace because it is built around the phone as the primary interface.

One concern is the terms of service. The phrase 'appoint the Services as your agent' is broad. It means Instinct may be able to enter into agreements on your behalf. The use of Stripe Link cards limits financial risk to amounts you approve, but other actions are less constrained. You should not connect critical business accounts until the security model matures.

OpenClaw: a heartbeat on your own Gateway

OpenClaw v2026.10.9, released October 29, runs a Node.js Gateway on your machine. Automations run inside it, so nothing fires while it is down. The self-wake is the heartbeat. It is a system-owned job that runs an agent turn every 30 minutes by default and messages your own DM. The checklist now lives in a monitor scratch instead of HEARTBEAT.md. You can set it with a command like this:

openclaw cron scratch <jobId> --set 'your checklist here'

The openclaw doctor --fix command migrates from the older HEARTBEAT.md format. This is a good example of how quickly the open source agent space is moving.

The morning brief is a separate isolated job. openclaw cron is an alias for openclaw automations. Here is the full command:

openclaw cron create '0 8 * * 1-5' 'Check my inbox and calendar. Tell me only what needs a decision today. If nothing does, reply NO_REPLY.' --name 'Morning brief' --tz 'Asia/Kolkata' --session isolated --announce --channel telegram --to '123456789'

After that, openclaw cron list --all shows both jobs. The output looks something like this, trimmed and with a test agent named dev:

Name             Schedule                           Target    Delivery
Heartbeat (dev)  every 30m                          main      not requested
Morning brief    cron 0 8 * * 1-5 @ Asia/Kolka...   isolated  announce -> telegram:123456789 (explicit)

A cron expression parser will explain 0 8 * * 1-5 if you do not use cron often. The schedule means 8:00 AM from Monday to Friday. The time zone is important because the shell's time zone is not necessarily the one you want. OpenClaw lets you set --tz directly on the job.

One default to change immediately. The job allowed every tool because toolsAllow was set to ["*"]. You should pass --tools with an allow-list. This reduces the attack surface if the agent's prompt is manipulated. The OpenClawCVEs tracker counted 543 CVEs and 211 advisories on October 31. That number sounds alarming, but it reflects a very active project. Still, self-hosting means you are responsible for patching.

OpenClaw has a large ecosystem of plugins, automations, and community extensions. It can connect to many messaging platforms, CRMs, file systems, and developer tools. The default heartbeat is the fastest way to get a proactive agent running locally. You need a model API key, and you pay for the tokens.

Hermes Agent: cron jobs and signed webhooks

Hermes Agent v0.22.5, released October 23, runs its scheduler inside the gateway. It ticks every 60 seconds. Schedules can be plain English. Failed runs always deliver, and a monitor mode with --monitor-url or --monitor-script skips the LLM entirely when a cheap check's output has not changed. That is a useful optimization for health checks.

Here is the same morning brief in Hermes:

hermes config set timezone Asia/Kolkata
hermes cron create 'weekdays at 8am' 'Check my inbox and calendar. Tell me only what needs a decision today. If nothing does, reply [SILENT].' --name 'morning-brief' --deliver telegram

The output shows the job ID and the next run time:

Created job: 115c4cda804e
  Next run: 2026-11-02T08:00:00+05:30

Nothing runs until hermes gateway run is up. Set the time zone first. In our test, changing the time zone afterwards did not move the stored next run. For the model side, you can run Hermes on free OpenRouter models. That makes it possible to experiment without paying for an API key.

Hermes has the clearest scheduler and webhook model for developers. The gateway is a Python process, which is easy to extend. The monitor mode is particularly effective. If you have a script that checks whether a service is healthy, you can run it on a schedule and only invoke the LLM when the script reports a change. This keeps token costs low and makes the system more predictable.

Triggering Hermes from GitHub through a Pinggy tunnel

Grok Bot gives you a webhook URL, but Hermes can only recieve webhooks on port 8644 of a machine with no public address. To receive GitHub events, you need to expose that port. This is a common problem for self-hosted agents. A tunnel solves it.

The docs suggest setting WEBHOOK_ENABLED=true in ~/.hermes/.env, but in v0.22.5 hermes webhook subscribe refused with the error 'Webhook platform is not enabled' until the flag was placed in config.yaml. This is exactly the kind of configuraton detail that can eat an afternoon. The fix is:

hermes config set platforms.webhook.enabled true
hermes webhook subscribe github-issues --events 'issues' --prompt 'New issue #{issue.number} in {repository.full_name}: {issue.title}. Triage it and tell me if it needs me today.' --deliver telegram
hermes gateway run

Subscribing prints a generated HMAC secret and http://localhost:8644/webhooks/github-issues. In a second terminal, run:

ssh -p 443 -R0:localhost:8644 free.pinggy.io

Pinggy prints an HTTPS URL ending in .run.pinggy-free.link. Under the repository's Settings, go to Webhooks, then Add webhook. Enter that URL plus /webhooks/github-issues. Choose application/json, paste the secret, and select only the Issues event.

We tested teh path with a signed GitHub-style issues event. Our test gateway had no Telegram bot, so the --deliver telegram route answered with HTTP 503 and the error {"error": "Admission unavailable; retry this delivery"}. The lesson is to connect the delivery channel first.

With the route switched to --deliver log, a valid X-Hub-Signature-256 got HTTP 202 with {"status": "accepted", ...} and the gateway logged the rendered prompt. A wrong signature got HTTP 401 with {"error": "Invalid signature"}. This shows that the HMAC verification works.

A free tunnel expires after 60 minutes with a new URL, so a saved hook needs a Pro token with a persistent subdomain. The command looks like:

ssh -p 443 -R0:localhost:8644 <token>@pro.pinggy.io

More details are in the Pinggy guide to receiving webhooks on localhost. Steps one through five were tested on October 31, 2026 with Hermes Agent v0.22.5.

This example matters because it shows how a self-hosted agent can participate in event-driven workflows. You are not limited to cron. With a tunnel, you can expose any local port and receive signed payloads from GitHub. The same pattern works for Stripe, Slack, or any service that sends webhooks.

Security considerations for self-hosted agents

Self-hosting gives you control, but it also gives you responsibility. Your gateway is a target. The default heartbeat in OpenClaw runs every 30 minutes. That means the agent is constantly reading your data, and an attacker who can inject content into a data source may be able to influence the agent. Here are a few practices to follow.

First, use allow-lists for tools. Do not let the agent use every tool by default. In OpenClaw, pass --tools with a specific set. In Hermes, configure the gateway to restrict available tools. This limits the damage a prompt injection can do.

Second, separate job sessions. Use isolated sessions for tasks that read untrusted input. If an email causes the agent to take an action, the action should not affect the rest of your system. OpenClaw has an --session isolated flag. Hermes has job-level configuration for similar isolation.

Third, use signed webhooks and verify signatures. GitHub sends an HMAC signature. Hermes verifies it. If you build your own trigger, always verify the payload signature before processing. Also use HTTPS for the tunnel endpoint. Pinggy provides HTTPS by default.

Fourth, patch often. OpenClaw has a high number of CVEs. This is not a reason to avoid it, but it is a reason to update the gateway frequently. You can automate the update process with a cron job or a CI pipeline.

Fifth, audit your agent's messages. Start with one job and read every message. Count how many times the agent acted without being asked. If it takes actions you did not expect, tighten permissions. If it sends too many irrelevant messages, refine the prompt with a quiet path.

How to choose a proactive agent

If your work lives in ChatGPT and Codex, pick a dot. It coordinates well and has read-only research. For cheap US errands, Muse's free tier and Sentinel design are the safest hosted bet on paper. Grok Bot suits teams that want event-driven routines and accept one shared computer. Instinct suits people who only want to text, if its terms are acceptable. OpenClaw has the biggest ecosystem but needs frequent patching. Hermes has the clearest scheduler and webhook model for developers.

Also worth watching are Anthropic's Claude Duet, a US waitlist preview that sends a morning brief and checks your apps every few hours, and Google's Gemini Spark. These two are too new for a direct comparison, but they confirm that proactive agents are becoming a standard feature.

Think about your delivery channel. An agent that texts you first is useful, but text is asynchronous. A Slack or Telegram message can be more searchable. Email is fine for long-form briefs. Choose the channel that you actually check. If you do not check Telegram, an agent that only publishes to Telegram will be ignored.

Think about the data the agent can read. Hosted agents read your data on their servers. Self-hosted agents read your data on your machine. Which is more comfortable depends on your threat model. If you handle sensitive client data, self-hosting gives you more control over compliance. If you want zero maintenance, a hosted agent is simpler.

Think about cost. Hosted agents have monthly subscription prices. Self-hosted agents have model API costs. At high volumes, API costs can exceed a $100/month subscription. At low volumes, self-hosting is much cheaper. You should estimate the number of agent turns per day. A heartbeat every 30 minutes is 48 turns per day. Each turn may include several LLM calls. A simple email check might cost a few cents. A complex research task can cost more.

Think about trigger flexibility. If you need to react to webhooks, Hermes and Grok Bot are the best choices. If you need fine-grained scheduling with seconds or minutes, Hermes and OpenClaw are better. If you want a coordinator that can decide when to check, Dots is unique. If you want no configuration at all, Instinct is the easiest.

Frequently asked questions

Can I use these agents without giving them access to my email? Yes, to various degrees. OpenClaw and Hermes only access what you configure. Dots requires connecting apps for research. Muse uses Sentinel to gate credentials. Grok Bot shares browser sessions, so be careful. Instinct can access connected services, and its terms are broad.

Which agent is best for GitHub automation? Grok Bot has native GitHub triggers and is the easiest hosted option. Hermes with a Pinggy tunnel is the best self-hosted option because you can run it on your own machine and verify signatures. OpenClaw also has GitHub integrations, but its default heartbeat is not event-driven.

Do I need a separate computer to run a self-hosted agent? Not necessarily. A laptop or a small cloud VM is enough for a single user. The gateway is lightweight. The heavy work is done by the LLM API. You do need the machine to be online when you want the agent to run.

Are these agents safe to connect to my bank? Probably not yet. The only payment-related safety feature among these is the single-use Stripe Link card used by Muse and Instinct. That reduces financial risk. However, no agent is safe if its prompt can be injected with malicious instructions. Keep sensitive financial accounts out of any agent until the security model matures.

Can I run OpenClaw and Hermes at the same time? Yes, but they cannot share the same delivery channel without careful configuration. Both can send to Telegram, and each has its own gateway. Running both lets you compare them on the same workflows. You should use separate job names and separate sessions.

How do I make the agent silent when nothing needs attention? Use the explicit quiet path. For OpenClaw, prompt it to reply NO_REPLY. For Hermes, include [SILENT] in the final response. Some hosted agents also have an option to only message when an action is needed, but you should verify that behavior in practice.

Conclusion

Whichever you pick, start with one scheduled job that has a quiet path. The quiet path can be NO_REPLY, [SILENT], or 'message me only if a decision is needed.' Then add one event trigger, with approvals on for anything that sends, pays, or deletes. After a week, count how many of its messages you were glad to get. That number is the real measure of a proactive agent.

Proactive AI agents are a new category. The differences in security models are more important than the differences in features. A shared computer is risky. A policy enforcement agent is promising. A broad terms of service is a warning. A persistent local gateway is powerful. Choose the model that fits your data, your risk tolerance, and your workflow.

If you are a developer, the self-hosted options are the easiest to audit. Hermes gives you signed webhooks and a transparent scheduler. OpenClaw gives you a large ecosystem and a heartbeat. Both are free and open source. They require more work, but they give you ownership. In a space that changes this fast, ownership is a real advantage.

Reference

Proactive AI Agents Compared: Dots vs Muse vs Grok Bot vs Instinct vs Hermes vs OpenClaw (2026)

Anthropic's Junk Rating Forecast Is a Signal for Everyone Building on AI Infrastructure

Lightning Developer — Sun, 01 Nov 2026 11:40:04 +0000

On October 26, 2026, Anthropic filed its Form S-1, and for four days the public debate was dominated by valuation, revenue growth, and an $80.7 billion headline loss. Then the Financial Times reported something with more direct consequences for how the company will pay for its future: Blackstone, the anchor investor in a $63 billion financing deal for Anthropic's chips, has told investors in that deal that it expects the AI lab to receive a high junk rating after its IPO. This article walks through what that forecast means, why it matters, and what developers and infrastructure buyers should watch in the coming quarters.

The forecast that reversed

Blackstone had previously told investors it expected Anthropic to secure an investment-grade rating before 2027. According to the FT, that view has changed. The firm now expects a rating in the double-B range, which is the top tier of speculative grade. Moody's, S&P, and Fitch have not made an official determination. The forecast is a prediction, not a decision. But predictions from the institution underwriting the debt tend to travel, and this one tells you something about how the people closest to the deal are pricing Anthropic's risk.

Why did Blackstone change its view? Bankers working with both Anthropic and OpenAI have spent months trying to persuade the major agencies to hand the two AI developers investment-grade ratings once they are public. Blackstone itself had been telling investment partners that Anthropic would get there before the end of the year. The revision came after preliminary guidance from the agencies, pointing toward BB or higher within speculative grade.

That shift did not happen in isolation. Anthropic has been signing compute deals at a pace that makes the credit math more difficult. Its prospectus describes a plan to spend more than $800 billion on computing infrastructure through 2045. A company that commits to hundreds of billions in future payments is not going to be priced like a mature software business, regardless of how fast revenue is rising. The agencies are saying that out loud, at least in preliminary conversations.

The sequence matters more than the headline. Bankers have spent months trying to convince the agencies that Anthropic's revenue trajectory, its enterprise retention, and its cash pile should outweigh the still-negative accounting picture. Blackstone's revised guidance shows that those arguments are not yet landing at the rating-committee level. The agencies are not questioning whether the AI buildout is real. They are questioning whether a business with this much committed future spending has yet earned the right to be treated as a low-risk borrower.

What a double-B rating actually means

Credit ratings split the corporate world in two. Ratings from AAA down to BBB minus are investment grade. Ratings from BB plus down to D are speculative grade, often called high yield or junk. The boundary is not cosmetic. It decides which institutions are allowed to buy the bonds, how much collateral is required, and how much interest the issuer has to pay.

Band	Category	Typical issuer profile
AAA to A	Investment grade	Large, profitable, low leverage, long track record
BBB plus to BBB minus	Investment grade	Stable cash flow, moderate leverage, some cyclicality
BB plus to BB minus	Speculative grade, top tier	Growing, leveraged, limited through-cycle history
B plus to B minus	Speculative grade	High leverage, thin margins, elevated default risk
CCC and below	Speculative grade	Distressed or near default

An issuer with a double-B rating can borrow, but it borrows differently. The pool of buyers narrows to high-yield funds, hedge funds, private credit vehicles, and a sliver of crossover investors. Many insurance companies and pension funds operate under mandates that restrict or forbid meaningful exposure to speculative-grade debt. That is exactly the constraint the FT flagged: a missing investment-grade rating narrows Anthropic's lender base and raises its cost of capital.

Second-order effects matter as much. Ratings are public signals. A BB rating on Anthropic debt becomes a benchmark that counterparties cite in lease negotiations, in supplier contracts, and in the internal risk models of every company that has extended the lab credit backstops or capacity commitments. If you are running an engineering team that relies on Anthropic APIs, you might not look at the rating directly. The cloud providers and compute brokers that negotiate with Anthropic will. Their financing costs feed into what they charge for capacity, and those costs ultimately shape the price and availability of the models you use.

There is also a status effect. In the bond market, the difference between BBB minus and BB plus is the difference between a borrower that is eligible for conservative portfolios and one that is not. A company can be operationally strong and still fail that test. The rating agencies are slow to award investment grade to a company with no through-cycle record, even when its quarterly growth numbers look spectacular.

Inside the $63 billion deal that made the rating a public question

The rating question became urgent because of how the chip financing was built. On October 26, 2026, Bank of America, Blackstone, Citi, and Morgan Stanley announced a $63 billion financing structure to buy Broadcom AI accelerators and networking equipment for lease to Anthropic, executed through a newly formed special purpose vehicle. Deliveries are expected to start in 2027 under a previously announced compute capacity agreement involving Broadcom. The FT later described the transaction as Project North Star, covering Anthropic's lease of 1.5 gigawatts of Google-designed chip capacity.

The stack is layered, and each layer carries a different rating.

Layer	Size	Backing	Rating signal
Senior (first lien) debt	About $43.5 billion, roughly 69% of the total	Broadcom residual value support, absorbing declines in asset value	Supported by Broadcom's investment-grade profile
Junior (second lien) debt	About $18 billion	Anthropic lease payments	BB plus with positive outlook from KBRA; BB from Morningstar DBRS
Blackstone commitment	$9 billion of the junior tranche	Same	Targeted yield above 10%

Broadcom's role is the part most readers skip. Its residual value guarantee means the senior lenders are not simply betting on Anthropic. They are betting on a chipmaker with an investment-grade rating standing behind the collateral. That structure is why a company with an operating loss could raise $63 billion at all. The senior tranche looks closer to a Broadcom credit than an Anthropic credit. The junior tranche does not, and that is where Blackstone put its money, at a yield that reflects the difference.

KBRA's BB plus with a positive outlook on the junior debt is a small but real improvement over the stable outlook it assigned to a similar arrangement, Project Big Sky, four months earlier. Read that alongside Blackstone's revised corporate-level forecast and the picture is consistent: the agencies see improvement, but not enough to cross into investment grade.

Why a rating is a financing input, not a report card

It is tempting to treat the rating as commentary on Anthropic's business. It is better understood as an input to a fairly mechanical calculation about how the company funds the next several years. The rating is not a judgment about product quality, and it should not be read as a statement that Anthropic will recieve no more funding.

The arithmetic runs like this. Anthropic reported $16.29 billion of revenue in the first half of 2026, up from $1.16 billion a year earlier, alongside an operating loss of $693 million and $8.95 billion of compute and infrastructure expense. The $80.7 billion net loss is mostly an accounting event: about $72.4 billion of it came from non-cash fair value changes on convertible notes, derivative liabilities, and similar instruments. As the company's private valuation climbed, the accounting value of those liabilities rose, and accounting rules pushed that increase through the income statement.

So the operating business is improving while the balance sheet is committing to enormous future payments. Anthropic holds more than $112 billion in cash and cash equivalents, according to the FT, and investors expect it to raise roughly another $100 billion in the IPO. Its S-1 discloses named compute contracts with Amazon, Microsoft, Broadcom, and other providers that add up to roughly $637 billion, and the $800 billion infrastructure plan extends to 2045.

Capital of that size cannot come from equity alone. Equity raises dilute, and public shareholders are less forgiving than private ones about dilution at scale. Debt is the alternative, and the price of that debt is set by the rating. An investment-grade issuer might borrow at a spread that a double-B issuer pays a multiple of. On a balance sheet carrying tens of billions in lease obligations, a couple of hundred basis points of spread is not a rounding error; it is the difference between funding the next tranche comfortably and funding it reluctantly.

It also changes the way counterparties view long-term contracts. A compute agreement with an investment-grade tenant gets more favorable payment terms, longer credit periods, and more room to renegotiate capacity. A speculative-grade tenant faces stricter milestones, more escalation clauses, and more frequent true-ups. None of those terms show up in an API changelog, but they determine how aggressively Anthropic can sign new capacity deals and therefore how much inference and training throughput it can offer.

This is not a report card on the product. It is a pricing signal for the cost of capital. A developer reading the S-1 might assume that a $112 billion cash balance removes all risk. In practice, the cash balance is not enough to cover the forward commitments if the financing markets tighten. The rating matters because it governs how cheaply the remaining gap can be filled.

The accounting details behind the $80.7 billion loss

The $80.7 billion net loss looks terrifying at first glance. Most of it is not an operating loss. It is a non-cash mark-to-market adjustment driven by the rising valuation of the company's private convertible notes and derivatives. When a unicorn raises at a higher valuation, the conversion features on earlier notes become more valuable, and accounting standards require the issuer to record that increase as a fair value loss.

This is one of those cases where generally accepted accounting principles create the opposite of what intuition suggests. As Anthropic became more valuable, its income statement showed a larger loss. The operating business, meanwhile, improved: second-quarter operating income was $974 million, and the first half generated positive operating cash flow of roughly $3.9 billion.

For engineers who work with financial data, the lesson is to separate recurring operating expenses from non-cash valuation charges. The $8.95 billion of compute and infrastructure expense is real spending. The $72.4 billion fair value adjustment is not a cash outflow. That distinction is central to the credit story because rating agencies focus on the company's ability to generate cash and service debt, not on accounting noise caused by the company's own valuation.

The bull case the agencies are weighing

It would be wrong to read the junk forecast as a verdict that Anthropic's business is weak. The case for investment grade rests on numbers that are genuinely unusual.

Revenue grew roughly 1,300% year over year in the first half. Anthropic reported $974 million of operating income in the second quarter of 2026, its first profitable operating quarter in the six periods disclosed in the S-1. It generated positive operating cash flow of roughly $3.9 billion in the first half. Customers spending $100,000 or more on a trailing twelve-month basis grew from over 950 to over 11,900 in a year, and net revenue retention was approximately 900% as of September 30, 2026. A business with that retention profile has a plausible path to covering fixed commitments.

The 900% net revenue retention figure deserves special attention. It means existing customers are spending roughly nine times as much on Anthropic as they did a year earlier. Very few software businesses ever see that metric. For a credit analyst, it reduces the risk that the revenue base will erode quickly if new customer acquisition slows. It also supports the idea that Anthropic could become a large, profitable company within the next few years.

That is the argument bankers have been making to the agencies, and it is not frivolous. But it runs into a structural objection that rating committees tend to take seriously: there is no through-cycle history. Investment grade has historically meant a demonstrated ability to service debt during a downturn. Anthropic was founded in 2021. It has never operated through a demand collapse, a pricing war that compressed margins, or a technology shift that made its assets less valuable.

Moody's made a related point about the broader financing pattern, describing Broadcom as one of the strongest large technology companies while warning that risk would rise if multiple transactions were structured in a short period to meet the sizable funding needs of frontier AI labs. The concern is not any single deal. It is the aggregate. When every major AI lab is trying to lock down datacenter capacity at the same time, the total volume of machine-readable obligations becomes a systemic data point that rating agencies cannot ignore.

How rating agencies think about AI compute contracts

Understanding the rating means understanding how agencies look at compute contracts. These agreements are not like ordinary SaaS contracts. They involve enormous prepayment structures, residual value guarantees, special purpose vehicles, and delivery milestones that can shift by quarters.

Agencies tend to focus on four variables.

The first is debt service coverage, which compares expected cash flow to required principal and interest payments. Anthropic's revenue growth makes this ratio look better today than it did a year ago, but the coverage ratio worsens when analysts add the full amount of committed lease payments into the fixed charge calculation.

The second is asset coverage. If the chips underlying the lease lose value, how much collateral is left after a default? Broadcom's residual value support is designed to answer that question for the senior lenders. The junior lenders are more exposed to Anthropic's own credit, which is why the junior debt receives a projected BB rating while the senior debt is effectively priced off Broadcom.

The third is counterparty quality. A compute contract with Google Cloud is not the same as a compute contract with a startup that offers discounted GPUs. The rating agencies can give credit for strong counterparties, but they also worry about concentration risk. Anthropic's dependence on a small number of hardware and cloud providers is a credit negative even when the providers themselves are investment grade.

The fourth is contract enforceability. Are the payment obligations unconditional? Can Anthropic terminate for convenience? Is capacity guaranteed at a specific date? S-1 filings summarize these agreements, but the actual definitions occupy hundreds of pages. Rating agencies typically assume the worst case if the contracts allow for flexibility.

Structural objections that keep it out of investment grade

The lack of a through-cycle record is only one objection. There are at least four more that rating committees weigh.

First, the assets being financed are technology assets with a useful life that is shorter than the debt maturity being proposed. AI accelerators depreciate quickly, and their resale value depends on generations of hardware that have not been released yet. Broadcom's residual value support helps the senior tranche, but it does not eliminate technological obsolescence. If a new interconnect standard or a software optimization reduces demand for current chips, the collateral value may decline faster than the amortization schedule.

Second, the contracts that back the lease payments are concentrated among a small number of counterparties. Anthropic's compute agreements are with hyperscale cloud providers and specialized GPU clouds. That concentration is operationally important because it gives Anthropic access to capacity, but it is a credit negative because a problem at one counterparty can create a cascading revenue and supply problem.

Third, the structure uses special purpose vehicles to keep leverage off the operating company's consolidated balance sheet to some degree. SPVs are common in project finance, and they are not inherently risky. But they can make the true aggregate leverage harder to observe. Credit investors have been flagging data center and chip financing structured through SPVs for months, so that leverage does not appear cleanly on any single balance sheet. The rating agencies have to estimate how much of a company's future obligations are embedded in these vehicles and how much recourse the parent actually has.

Fourth, there is the efficiency question. Many frontier AI companies have publicly discussed inference-time techniques that reduce the number of chips needed for a given workload. If efficiency gains reduce demand for raw compute faster than the contracts assume, the utilization assumptions behind the lease payments could miss. This is not a problem unique to Anthropic, but it is another reason why an agency might hesitate to assign investment grade to a credit that is effectively a bet on a specific hardware roadmap.

Who is left holding the structure

There is a distributional question buried in the rating. When a deal is investment grade, risk lands on insurers, pension funds, and bond funds operating under conservative mandates. When it is speculative grade, risk lands on high-yield specialists and private credit funds, which demand higher yields and, in a stress scenario, are quicker to sell.

Blackstone's $9 billion commitment in the junior tranche, seeking a yield above 10%, is a clear illustration of how the market prices this. The yield is the compensation for taking Anthropic lease risk without Broadcom's guarantee underneath. If Anthropic's corporate rating comes in at double-B, that junior paper looks appropriately priced. If the corporate rating surprised to the upside, that yield would have been a bargain.

Broadcom carries the other side of the trade. Its residual value support transfers part of the collateral risk off the lenders and onto a chipmaker with a strong rating. The FT's reporting on Project North Star notes that Broadcom's A-range rating was an important factor in getting the financing done at all. That is a reminder that AI infrastructure debt is rarely a pure bet on one company. It is a web of guarantees in which the strongest balance sheet in the room sets the terms for everyone else.

Similar reversals have occured across other AI financings in the past year, and the pattern is nearly always the same: an optimistic private forecast, a preliminary agency discussion, and then a correction toward the middle of the credit spectrum. The correction does not mean the deal fails. It means the people providing the capital price it more honestly.

What to watch between now and pricing

The rating agencies have not spoken. What exists today is preliminary guidance relayed by an anchor investor, and preliminary guidance can move in either direction once audited financials, a price range, and a share count are on the table. A completed IPO that raises close to the reported $100 billion would materially change the liquidity picture the agencies are modeling, and a large equity cushion is exactly the kind of thing that pushes a borderline credit upward.

Three data points will settle the question faster than any commentary.

The actual rating and outlook from each agency that covers the new debt, including whether any of them assigns a higher rating to the secured tranches than to Anthropic's unsecured obligations.
The payment schedule behind the compute commitments. A $637 billion contract total says little without knowing how much is due in each year, how much is cancellable, and whether obligations are conditioned on delivery milestones.
The spread at which Anthropic's first unsecured or lightly secured borrowing prices after listing. That number is the market's own rating, and it will be visible immediately.

The third point is teh one most quantitative developers can start tracking today. Spreads are quoted in basis points, and they move before rating agencies publish anything. If you see a new issue from Anthropic price several hundred basis points above Treasuries, the market has already made its own judgment.

There is a fourth signal that is less obvious: the behavior of the secured versus unsecured spread. If the market prices the secured tranche at a very tight spread and the unsecured corporate debt at a wide spread, it is telling you that the market trusts the collateral and the counterparty guarantees more than it trusts Anthropic's standalone credit. That kind of split can persist for years and is common for project finance platforms.

A practical checklist for engineering leaders

For engineering leaders who consume Anthropic models or build tooling around them, the credit story has practical implications. This checklist is a useful way to prepare.

Negotiate reserve capacity in writing. If your workloads depend on a specific model family, ask for reserved throughput and committed service levels. A financially constrained vendor may cut unsupported traffic first.
Build a model abstraction layer. The ability to route between Anthropic, OpenAI, or open-weights models is no longer a nice-to-have. It is a hedge against vendor pricing changes and capacity constraints.
Monitor unit economics, not just API price. Track cost per successful request, including retries, latency penalties, and cache hit rates. A price cut can be offset by worse reliability or lower inference efficiency.
Watch the vendor's balance sheet disclosures. After the IPO, Anthropic will report quarterly. Look for changes in committed capex, lease obligations, and cash burn. Those numbers are leading indicators for API pricing.
Understand the SPV exposure if you use dedicated GPU instances. If you rent bare metal or dedicated capacity from a provider that financed its fleet with project debt, ask whether the financing includes residual value guarantees from a third party.
Prepare for stronger rate limits. As Anthropic's cost of capital rises, it will prioritize paid, predictable workloads over speculative traffic. Build retry and fallback logic that respects those limits without causing user-facing failures.

This checklist is not about predicting a default. It is about reducing the blast radius if the financing environment changes faster than the product roadmap.

A simple model for the spread drag

For developers who want to quantify the impact of a rating change on capital costs, here is a simple model of the annual spread drag between investment-grade and speculative-grade borrowing on a hypothetical $10 billion note. It is intentionally simplified, but it shows why rating categories matter for anyone who models AI capex.

face_value = 10_000_000_000
years = 10

def annual_cost(spread_bps):
    return face_value * (spread_bps / 10000)

ig_spread = 150
hy_spread = 450

ig_cost = annual_cost(ig_spread)
hy_cost = annual_cost(hy_spread)
drag = hy_cost - ig_cost

print(f'Investment grade spread: ${ig_cost:,.0f} per year')
print(f'High yield spread: ${hy_cost:,.0f} per year')
print(f'Annual spread drag: ${drag:,.0f}')

The output is straightforward:

Investment grade spread: $150,000,000 per year
High yield spread: $450,000,000 per year
Annual spread drag: $300,000,000

A single rating notch can create hundreds of millions of dollars in annual interest expense for a company of Anthropic's size. Those costs eventually flow into either the income statement or the prices charged to customers. When you see a company raise prices or reduce free tier limits, this kind of capital cost is often part of the reason.

Common questions from engineering teams

Will a junk rating make Anthropic less safe to use?

No. The rating is about the company's capital structure, not the security of its API. Anthropic has a large cash balance and a fast growing revenue base. A speculative-grade rating increases the cost of future borrowing, but it does not mean the service will disappear.

Does this affect the Anthropic API pricing?

Indirectly. A higher cost of capital puts pressure on the company to improve utilization and pricing discipline. You may see more aggressive tiering, higher prices for low-value traffic, or bigger discounts for committed-use contracts. The effect will show up gradually, not as a single overnight price change.

What should I do if my company depends heavily on one model provider?

Build redundancy. Use an internal gateway that supports multiple providers. Keep evaluation datasets and prompts in a format that is not tied to one vendor. The goal is not to avoid Anthropic, but to make switching possible without rewriting the entire application.

Can the rating improve quickly?

Yes. If the IPO raises an unusually large equity cushion and the company continues to grow at triple-digit rates, the agencies could revise the outlook to positive and upgrade within 12 to 24 months. The Blackstone forecast is a snapshot, not a life sentence.

How do I track this going forward?

Follow the rating agency reports, the company's quarterly earnings, and the new issue calendar. The spread on the first corporate bond issue is the single most transparent market signal available.

The signal inside the forecast

A junk rating is not a judgment that Anthropic is failing. The company grew revenue by more than a factor of fourteen year over year, turned an operating profit in the second quarter, and sits on a cash pile larger than the entire revenue base of most public software companies. Plenty of excellent businesses have spent years in high yield while they built durable cash flow.

What the Blackstone reversal signals is narrower and more useful. The credit market is separating the question of whether Anthropic will be a huge business from the question of whether its obligations should be held by conservative institutions. The answer to the first is increasingly yes. The answer to the second, at least for now, is: not yet, and not at investment-grade prices.

For anyone watching the AI buildout, that distinction is the real story coming out of the IPO. Anthropic's valuation will be set by people buying a growth story. Its borrowing costs will be set by people asking who pays if the growth arrives late. The gap between those two groups, and how it narrows over the next few quarters, will shape how much computing capacity the company can actually commit to. The FT's report is the first clear reading of how wide that gap currently is. For engineers and infrastructure buyers, the practical takeaway is equally clear: monitor the ratings, track the capital costs, and design your AI stack to survive a world where one large vendor has to borrow at junk prices.

Reference

Anthropic Expected to Get a High Junk Rating After Its IPO. Here Is What That Actually Changes

Turn OpenAI Dots Into Your Always-On Chief of Staff: A Developer's Guide

Lightning Developer — Fri, 30 Oct 2026 12:25:29 +0000

Most AI assistants behave like vending machines. You type a request, get an answer, and nothing else happens until you come back with another prompt. Follow-ups, reminders, and the question 'did that ever get done?' stay your job.

OpenAI released dots at DevDay on September 29, 2026. A dot is an always-on agent inside ChatGPT. It runs on GPT-6 Astra, gets its own cloud computer and browser, and keeps working between conversations. It can inspect your connected apps, delegate long-running work, and message you when something needs a decision. At first glance that overlaps with other agentic products, but its real value is as a chief of staff: something that reads Gmail, Google Calendar, and project threads, notices what slipped, and chases the tasks you hand it until they are actually finished.

This guide builds that setup with one running example: a solo developer with a personal dashboard app, a hobby game, a newsletter due on Tuesday, and a week on the road. Plan names, limits, and menu labels come from OpenAI's docs and were checked on October 29, 2026.

Summary

A dot is a coordinator, not an errand runner. It lives inside ChatGPT next to your memory, plugins, ChatGPT Work tasks, and Codex threads, and it hands real work off to those specialized tools. It works in two directions. Proactively, it reads your connected apps in read-only mode and tells you what slipped. Reactively, you dump a list on one call and it starts and tracks each task. Custom rules decide what it may do alone, and a short 'message me only when something matters' instruction removes most of the noise.

Access is narrow for now. Personal accounts need Pro, starting at $100 per month. Business Premium and Enterprise are rolling out, and personal Pro excludes the EEA, UK, and Switzerland. Work and Codex tasks started by a dot count toward those product limits, while conversations with the dot itself do not count toward ChatGPT usage limits.

How a dot differs from ChatGPT Work and Codex

A dot is a persistent agent with three things a normal chat does not have.

First, it has its own cloud computer and browser. That means it can keep working while your laptop is shut. It can open pages, run tools, and perform research independently of your local machine.

Second, it has memory beyond the current chat. It can use relevant ChatGPT memory, search across your past conversations, and maintain its own notes about your preferences, decisions, and ongoing work. Those notes follow it across the ChatGPT app, Slack, Microsoft Teams, and voice calls.

Third, it can pause and wake itself up. A follow-up check does not need a fixed schedule. The dot can sleep and then resume when it needs to verify something, chase a task, or ask you a question.

It reaches your apps through ChatGPT plugins. OpenAI listed more than 4,000 plugins at launch, covering Gmail, Google Drive, GitHub, and many other services. If you connect your computer through the ChatGPT desktop app, the dot can also use local files, code, and apps on that machine, and it can continue existing local Codex tasks.

The key architectural point is what a dot does with big jobs: it does not do them in its own chat. The docs split the work clearly:

Tool	What it is for
Chat	Answers, explanations, ideas, drafts
ChatGPT Work	Delegated tasks like research, analysis, or file creation, now or on a schedule
OpenAI Codex	Building, debugging, testing, and reviewing software
Your dot	Ongoing responsibilities, next steps as things change, follow-ups between conversations

Because a dot delegates, it can split big jobs across background agents that run in parallel. Since an October 9 update, it can also start Codex work and follow up on existing Codex threads. That is the entire case for the dot as a coordinator.

On paper, Meta's Muse and xAI's Grok Bot compete with the same idea. Meta's Muse is cheaper for shopping, travel bookings, and forms. xAI's Grok Bot runs teams of always-on bots inside work tools. Neither sits on top of the threads, memory, plugins, and Codex tasks you already have in ChatGPT. If you treat a dot like a one-off errand tool, you ignore the context it is standing next to. Used as a coordinator, it feels different.

How the alternatives compare

Users who follow AI launches will notice that dots are not the only always-on assistant. The comparison depends on where your work already lives.

Meta's Muse is good at consumer-facing errands. It can handle shopping, travel bookings, and forms, and it has a free tier in the US. It is designed to be cheap and approachable, but it is not built around software project context like existing Codex threads or a personal Obsidian vault.

xAI's Grok Bot is aimed at running teams of bots inside your work tools. It can complete tasks across Slack, email, and documents, and it feels like a multi-agent workspace. The tradeoff is that it does not share ChatGPT's memory, plugin ecosystem, or Codex task history.

OpenAI's dot is different because it coordinates the products you already use. It is less independent, but it has more relevant context. In practical terms, a dot can say 'I found a blocking issue in your existing Codex thread, and the research you asked for is done. Here is what I need you to decide.' That mix of delegation and follow-up is hard to replicate in a generic bot team.

Product	Best at	Limitation
Meta's Muse	Shopping, travel bookings, forms	Less useful for software project follow-up
xAI's Grok Bot	Running teams of bots in work tools	Does not share ChatGPT memory and Codex threads
OpenAI dot	Coordinating ChatGPT Work and Codex	Expensive, one per account, regional limits

What you need before you start

Dots are not available on free plans. The current plan list is short:

Personal accounts need Pro 100, Pro 200, or Pro 500, starting at $100 per month.
You must be over 18.
Personal Pro excludes the European Economic Area, the United Kingdom, and Switzerland.
Business Premium is rolling out worldwide.
Enterprise is rolling out, but a workspace admin must enable dots first.
Free, Go, and Plus are not on the list.

The rollout is gradual, so even an eligible account may not see dots immediately. On October 28, a community forum post announced that dots are available in the EU on Business and Enterprise plans, with consumer plans coming very soon. That was confirmed by OpenAI.

Your first dot is included in the plan. OpenAI says you will be able to add more dots later, but pricing for additional dots has not been announced. Conversations with your dot do not count toward ChatGPT usage limits. Tasks that the dot starts in ChatGPT Work or Codex do count toward those products' limits. Plans also include an allowance for deeper dot work, with extended limits for the first month after launch. OpenAI has not published hard numbers for that allowance, so keep an eye on usage once the first month passes.

Set up your dot

Setup takes only a few minutes, but you need to connect the apps you want the dot to watch. In the running example, that means Gmail, Google Calendar, Google Drive, GitHub, and Slack, plus the laptop where the dashboard app, the game, and the Obsidian vault live.

Follow these steps.

Create the dot. Open dots in the ChatGPT mobile app, desktop app, or a desktop browser. Mobile web is not supported. Follow the introduction flow and give your dot a name and a look. Its handle starts as @yourname-dot, and naming the dot updates it. For example, a dot named Alfred becomes @yourname-alfred.
Connect plugins. Add plugins for the apps you want it to use, such as email, calendar, and files. Each plugin works with its connected account and uses permissions that already exist on that account, so review those permissions while you are in the flow. You can skip this step and add plugins later.
Connect your computer. In the ChatGPT app on the computer you want to connect, open the dot's profile, find 'Your computer' under Computers, select 'Allow access', and confirm. The dot can then use local files, code, and Codex tasks on that machine. This only works while the machine is online and the ChatGPT app is open. Only one personal computer can be connected at a time. 'Revoke access' removes it.
Add a channel. On the dot's profile, 'Add' shows contact methods available to you, such as Slack and Microsoft Teams. Texting over iMessage or RCS is rolling out in beta to Pro users in the US. Channels are only a way to talk to the dot. Apps and your computer are connected separately.

After that, write rules before you let the dot near your inbox. That rule-writing step is easy to skip, but it is the most important part of the setup.

Write custom rules before you hand over your inbox

Before a dot can take an action that affects your accounts or shares information, an automatic review checks that action against your instructions, permissions, custom rules, and safety requirements. The action then proceeds, waits for approval, or includes a step you must do yourself. OpenAI uses changing a password as the example of something a dot will always hand off to you.

Custom rules are how you tune that middle ground. On desktop and web, they live under Settings > Personalization > Custom rules in the Permissions section. On iOS and Android, open the sidebar and select Customize > Custom rules. Each rule is a plain-language description of an action plus one of four handling options.

A starting set for a chief of staff might look like this:

Action	Handling
Send an email or Slack message to anyone other than me	Ask before taking action
Accept, decline, or move calendar events	Take action when you say so
Write drafts, update notes, start or continue Codex tasks	Take action without asking
Pay, refund, or change a login	Hand off to you

Two details are easy to miss. Asking for draft replies does not authorize sending them, so 'draft replies to these three emails' leaves the drafts in a draft state. Plugin permissions are a separate layer. From the rules page, open 'Plugins' to see Plugin permissions, and remember that a custom rule never grants access to an app or computer. You have to connect those in the setup stage first.

Finding the right autonomy level

The four handling options are not equally useful for every action. For a chief of staff role, you want low-risk tasks fully automatic and high-risk tasks explicitly approved. Start with the most restrictive option for anything that touches another person or costs money. For notes, drafts, and Codex work, 'Take action without asking' is reasonable if the dot has a clear finish line.

One useful pattern is to separate 'read' from 'write'. The dot can read your inbox freely, but any draft that goes out should require approval unless you explicitly name the recipient and say send. Another pattern is 'propose, then act': ask the dot to prepare an action and wait for your go signal. The 'Take action when you say so' mode is built for that. The dot does the prep work and then waits. When you are on the road, this reduces back and forth while keeping a human in the loop.

The proactive half: what it finds without being asked

Right after setup, a dot introduces itself and uses the context and connected apps to look for places it can help. No prompt is required. For the traveling developer in our example, a first pass might return three things:

A hotel folio that does not match the booked rate, worth sorting out before checkout.
A sponsor email that has sat unanswered for two weeks.
A recording session planned for tomorrow that depends on details nobody has confirmed yet.

This research is read-only by design. The tools the dot uses for research cannot send messages, change app content, or control your browser or computer. Background agents report what they find to the main dot, which turns it into a suggestion or a question. Any follow-up action goes through the same review and rules we described above.

The other half of 'proactive' is follow-up. Because a dot pauses and wakes on its own, it keeps checking on things after a conversation ends. That cuts both ways. Suppose you ask the dot to chase a newsletter sponsor for an unpaid invoice. You go back and forth on wording, it sends the message, and half an hour later the dot independently looks at the payment side and tells you the money arrived last week. Useful, and a little embarrasing. The fix is to put the check in the original instruction instead of relying on follow-up: 'Before chasing any invoice, confirm it is still unpaid.'

Research runs read-only. Only the final step acts, and only through the automatic review plus your custom rules.

The reactive half: hand it a whole to-do list on one call

The fastest way to load work onto a dot is to call it. Open the dot's conversation and select the phone button, or press 'Call' on its profile in the desktop app. The screen actually rings like a phone call, which feels like a gimmick the first time. Past that, it is the quickest way to empty your head. You can type while you talk, and ending the call does not stop the work you assigned. Dot-initiated calls are planned for after launch.

Here is a realistic list that our developer dumps in one call:

Research the topic for Tuesday's newsletter and put a full outline into the existing note in the Obsidian vault, complete enough to turn into a draft without missing a key point.
In the existing Codex thread for the dashboard app, which already pulls Apple Reminders, calendar events, and Obsidian tasks onto one board, make a double-click on a task open a basic Markdown editor inside the app, save edits back to the Obsidian note, and keep an 'Open in Obsidian' button for anything heavier.
In the game's Codex thread, fix the player getting stuck between walking and climbing on steep slopes, and make god mode give unlimited arrows and faster movement for playtesting.

The dot reads the plan back, then fans it out. The research goes to a background agent or a ChatGPT Work task, and the outline lands in the vault through the connected computer. The two coding jobs continue existing local Codex tasks on that computer, which means the computer must stay online with ChatGPT open. New coding work can instead run in a Codex cloud environment that you have already set up, with the laptop off. The dot can open each job as its own visible thread, and Activity on the dot's profile in the desktop app shows each task's progress, files, results, and requests for input.

This is where the dot beats opening three threads yourself. It owns the follow-through. OpenAI's docs say plainly that a completed run does not by itself confirm that the requested result was achieved or delivered, so give it a finish line along with the task. 'Done means the editor saves back to the note and someone has played the god-mode build' is a bar the dot can check, chase, and report on. When it needs a decision or approval, it messages you, and with the ChatGPT app on your phone that arrives as a push notification you can answer from anywhere.

Making delegation reliable

When you hand a dot three tasks in one call, small ambiguities become expensive. The dot can split work, but it cannot read your mind. Use these patterns to reduce wrong results.

Define done in observable terms. Instead of 'improve the dashboard,' say 'double-clicking a task opens a Markdown editor, edits save back to the Obsidian note, and an Open in Obsidian button appears.' The dot can verify that behavior with its cloud browser and report the result.

Ask for one summary message. A good instruction is 'When everything is finished, send me a single message with the file paths and the test results.' This prevents a stream of small updates.

Ask for sources on research. If the newsletter outline has claims or numbers, tell the dot to list sources. OpenAI itself asks you to review important results, so sources should be part of the artifact, not a separate request.

Set a deadline for each job. 'If the Codex thread is not finished by Friday, tell me what is blocking.' This turns an open-ended background job into a bounded one and gives the dot a reason to wake you.

Separate new work from existing Codex threads. When you mention 'the existing Codex thread for the dashboard app,' the dot knows to continue that thread. If you just say 'fix the dashboard,' it may start a new thread and miss context. Name the thread and the file path when it matters.

Use checkpoints. For longer jobs, ask the dot to pause after each milestone and report before starting the next step. That keeps the human loop short and avoids a large batch of wrong work.

A day in the life with a dot

To make this concrete, imagine the first morning on the road. The dot has already checked the hotel folio and flagged a rate mismatch. It also noticed that the sponsor email is still unanswered. While you are having coffee, the dot sends one message: 'The hotel folio is wrong, and the sponsor email is two weeks old. Do you want me to draft replies to both?' That is the proactive half working.

You call the dot and dump the newsletter and coding tasks on it. It starts the research in the background, writes the outline to the Obsidian vault, opens a Codex thread for the dashboard editor, and starts another for the climbing bug. At lunch, the dot reports that the editor task hit a build error and asks whether to try a different approach. You approve. By evening, the outline is in the vault, the dashboard editor is running locally, and the climbing bug is fixed in the god-mode build. The follow-up loop happened without you copying and pasting context between tabs.

The dot's own activity feed doubles as an audit log. You can see which background agent handled the research, which Codex thread changed, and which files were written. That transparency matters when you are trusting an agent with real work.

Make it quieter, and more useful

Out of the box, a dot can be chatty. Connect Gmail and it may start telling you about new emails all day, which is noise when your phone already notifies you about every email you recieve. Tell it, in plain words, what you do not want and what you do: 'Do not tell me about new emails. Message me only if a deadline is at risk or you need a decision.' The dot keeps preferences like that in its notes, and you can ask it to confirm what it saved.

A few more instructions pay off quickly:

Route by kind. Keep routine progress in ChatGPT and send decisions to Slack. The dot picks the channel based on what you have told it.
Make check-ins explicit. Recurring work needs a clear schedule. Use a format like 'Every weekday at 8 AM IST for the next four weeks, check my inbox and calendar and send me in Slack only what needs a decision today. Confirm the schedule.' You can later review or cancel it under Scheduled.
Tell the dot directly when priorities change. Its notes are separate from ChatGPT's saved memory. Changing a saved-memory setting does not necessarily change the notes the dot has already made.

Stopping work happens in three places. Pause stops the dot's current main task, but it does not stop every delegated task or cancel future scheduled runs. To stop a delegated task, open it in Activity. To end a recurring one, disable or delete it in Scheduled. None of these undo actions that have already completed.

Where dots still fall short

Price and region come first. One hundred dollars a month for one agent is a lot if you only want help with email. Meta's Muse has a free tier in the US for errands. Personal Pro accounts in the EEA, UK, and Switzerland cannot get a dot yet, and in the EU only Business and Enterprise workspaces can so far.

The cloud half and the laptop half behave differently. The cloud computer stays available when the laptop is off, but anything on your machine, such as local Codex tasks or the Obsidian vault, needs that machine online with the ChatGPT app open. The cloud browser keeps its own sessions and does not inherit your logins. Some websites block cloud browsers or ask for extra verification.

Mistakes are real. OpenAI says dots can make mistakes and asks you to review important results and their sources. The follow-up-after-the-fact problem from the invoice example comes from the dot's fundamental design: it checks things on its own schedule. Usage also needs watching, because Work and Codex tasks started by a dot count toward those products' limits, and the extended limits only cover the first month after launch.

Finally, you get one dot for now. At launch, OpenAI previewed specialist dots for organizations, each with its own identity, credentials, and system access, starting as focused enterprise pilots. If more dots reach personal plans, the obvious move is one dot per role: inbox, finance, content. That mirrors the bot teams people already run on Grok Bot. Until then, one dot has to cover everything.

Giving your dot an always-on notes folder with Pinggy

The Obsidian vault in our example has teh same weakness as any local task: the dot can only write the newsletter outline while the laptop is online and ChatGPT is open. If you keep a synced copy of the vault on a machine that never sleeps, such as a mini PC, a NAS, or a Raspberry Pi, you can give the dot its own route to that folder as a custom MCP plugin. A Pinggy tunnel supplies the public HTTPS URL that ChatGPT needs to reach a box behind a home router.

Authentication shapes the entire setup. ChatGPT's custom MCP dialog offers OAuth, No authentication, or OAuth or no authentication. OpenAI's auth docs say ChatGPT cannot present custom API keys. If your gateway demands a bearer key, it will lock ChatGPT out along with everyone else. Short of running an OAuth 2.1 server, the practical setup is No authentication with two limits: the server only sees one folder of the vault, and it answers on a long random path instead of /mcp.

On that box, sync the vault to /srv/vault. Syncthing works well for this. Keep the notes you want the dot to work on, like the newsletter outline, in a Dot folder inside it. Then serve the official filesystem MCP server over Streamable HTTP with supergateway, which wraps a stdio server in an HTTP endpoint:

MCP_PATH="/mcp-$(openssl rand -hex 16)"
echo "$MCP_PATH"
npx -y supergateway --stdio "npx -y @modelcontextprotocol/server-filesystem /srv/vault/Dot" --outputTransport streamableHttp --port 8787 --streamableHttpPath "$MCP_PATH"

That serves the server-filesystem package's 14 tools, including read_text_file, write_file, edit_file, search_files, and the rest, on port 8787 at that random path, and nothing outside /srv/vault/Dot. We ran this on October 29 with supergateway 4.2.1 and server-filesystem 2.1.0. A tools/list request on the random path returned all 14 tools, a request to plain /mcp got a 404, and reading a file elsewhere in the vault returned 'Access denied - path outside allowed directories'.

Then open the tunnel from the same box:

ssh -p 443 -o ServerAliveInterval=60 -R0:localhost:8787 <token>@pro.pinggy.io

Use a Pro token from the Pinggy dashboard, with a persistent subdomain assigned to it. A free tunnel lasts 60 minutes and comes back with a new URL, which breaks the plugin URL you saved in ChatGPT. Free URLs also show a warning page to browser-like clients.

In ChatGPT on the web, turn on Developer mode if it is not already on. Open Plugins, select the plus button, then Add custom MCP server. Give it a name. Enter https://.a.pinggy.link followed by your random path as the Server URL. Pick No authentication, read the risk warning, select 'I understand and want to continue', choose Create as a plugin, then install it. OpenAI's custom MCP server guide lists the same steps, and Pinggy's guide to building a ChatGPT plugin with MCP shows where the Developer mode switch lives.

Three caveats apply. First, the random path is a secret inside a URL, not real authentication. Anyone with the full URL can read and write that one folder, so keep sensitive notes out of it and put an OAuth 2.1 layer in front of the gateway before trusting it with more. Second, OpenAI also has a private MCP tunnel option that keeps the server off the public internet entirely, but it requires an OpenAI Platform organization with Tunnels permissions and its tunnel-client running beside the server. Third, OpenAI's dots docs say a dot can use supported plugins installed and enabled for your account. One vendor reports its custom MCP connector working from the dot's first message, but this exact setup has not been tested with a dot by the original guide authors. Add a custom rule for edits to the folder either way.

The mini PC opens the tunnel outward, so no port is opened on the router and the laptop can stay closed.

Security and troubleshooting

When you start using a dot, a few questions tend to come up immediately.

Why does my dot not appear? The rollout is gradual. Even on an eligible plan, the dot entry point may not show up for a few days. Check that your ChatGPT app is updated and that you are on a supported platform. Mobile web is not supported, so use the mobile app, desktop app, or desktop browser.

Why did the dot ignore my local files? The connected computer must be online and open in the ChatGPT app. If the laptop is off, anything that depends on local files will fail. Cloud Codex tasks can continue without a local machine, but local paths cannot.

Can the dot send messages without asking? Only if your custom rules allow it. The default position is to check before actions that affect other people or external accounts. You can set 'Take action without asking' for notes and Codex tasks, but you should keep 'Ask before taking action' for sending messages to third parties.

How much does this cost in practice? The dot conversation itself does not count toward ChatGPT limits. Work and Codex tasks it starts count toward those product limits. The deeper work allowance has extended limits for the first month, but the numbers are not public. Watch your usage after that.

What if the dot keeps repeating notifications from my phone? That is the most common complaint. The fix is one clear rule: message me only if a deadline is at risk or you need a decision. Then review the dot's messages after a week and update the rule.

Can I use this with an open source alternative? Yes, the MCP pattern is vendor neutral. The same supergateway setup can expose any filesystem, and tools like Syncthing make the sync layer portable. The always-on agent itself is tied to ChatGPT for now, but the notes folder architecture is not.

What to do next

Start with work you regularly need to check or update, not a one-off request. That is OpenAI's own advice, and it matches how a dot is built. 'Keep the newsletter on schedule' or 'watch the sponsor inbox and tell me what needs a reply' gives the dot something to wake up for. Describe the responsibility, share the sources it needs, and say which decisions need you.

Then review the dot's work, tell it what needs to change, and only widen the scope once the first job runs well. Give it a week and look at what it actually caught. If most of its messages repeat notifications your phone already sends, tell it so and judge it on follow-ups instead: the invoice it double-checked, the Codex thread it reopened, the outline that was waiting in the vault on Monday morning. That is the job a chief of staff does, and it is the one thing a single chat thread never did.

Conclusion

A dot works best one layer above the tools you already use. It looks through Gmail, Google Calendar, and Slack with read-only research tools, hands research to ChatGPT Work and code to OpenAI Codex, and keeps following each job until it is done or it needs you. The order of the setup matters more than any individual setting: connect plugins and your computer, write custom rules before it goes near your inbox, give every task a finish line, and tell it in one plain sentence when to stay quiet.

Whether that is worth $100 per month depends on how much of your week goes into follow-up. If you mostly want errands run and you are in the US, Meta's Muse free tier is the cheaper bet. If you juggle Codex threads, a newsletter, and an inbox that never empties, a dot takes over the tracking you would otherwise keep in your head. Plan around two gaps while you decide: you get one dot per account for now, and anything that runs on your laptop needs the laptop online with ChatGPT open.

Reference

How to Use OpenAI Dots as a Chief of Staff in ChatGPT

FLUX 3 Max vs. Seedance 2.5: A Practical Field Guide to AI Image-to-Video Models

Lightning Developer — Wed, 28 Oct 2026 08:39:46 +0000

Introduction: The Image-to-Video Model Shortlist

Choosing an AI image-to-video generator used to mean settling for one obvious weakness. The model produced stunning clips, but each render took so long that nobody could iterate. Or the model was fast, but the output looked like a morph between unrelated frames. The latest release cycle changed that calculus. On the Artificial Analysis image-to-video leaderboard, two models now sit in the leading tier with 1,139 Elo: FLUX 3 Max and Seedance 2.5. One of them renders a 10-second clip in 12.45 seconds on fal's benchmark, while the other takes 277.8 seconds. That is not a minor difference. It changes where you can put the model in a product.

Before going further, keep the data scope in mind. This guide uses October 2026 launch-era scores, pricing, and fal latency measurements. It is a desk-researched comparison, not a hands-on benchmark. The 1,139 Elo figures refer to the launch snapshot. The live Artificial Analysis board, checked on October 24, lists FLUX 3 Max and Seedance 2.5 at 1,138 each, with MiniMax H3 at 1,140. Calculated workload times assume sequential generation and exclude queueing, retries, and review time. Always check current model pricing before budgeting.

"Best" still depends on the job. A creative agency, a storyboard artist, and a startup watching its bill want different things. So instead of one ranked list, here are six jobs and the model I would hand each one, with the reason and the catch.

Fair warning: FLUX 3 Max takes four of the six slots. It is one model with three modes, text-to-video, image-to-video, and keyframes-to-video, plus a launch price, and those happen to cover four different jobs. The other two picks are places where I would genuinely send you elsewhere.

The Six Picks at a Glance

#	Use case	Pick	Why	Watch out
1	Best overall	FLUX 3 Max	#1-tier quality, about 22x faster than its tie-partner	720p output
2	Agencies iterating on concepts	FLUX 3 Max	Around 22 drafts in the time of one	Run your own eval for the hero cut
3	Storyboarded shots	FLUX 3 Max keyframes-to-video	You set the start and end frames	Both frames have to exist first
4	Raw speed above all	H3 Max on fal	3.49 seconds in fal's benchmark	1,125 Elo, a step below the 1,139 tie
5	Committed to ByteDance's stack	Seedance 2.5 on fal	Same 1,139 Elo, same fal key	About 4.5 minutes and about $4.73 per 10-second clip at 720p
6	Budget at scale	FLUX 3 Max at launch pricing	About $0.43 per 10-second clip	75% off ends November 7

How the Picks Were Scored

To compare fairly, I leaned on two public sources. First, Artificial Analysis runs a blind, pairwise human preference arena for image-to-video models. Humans see two clips and choose which one looks better, and those votes produce an Elo score. Second, fal publishes benchmark latencies for generating a 10-second video at 720p or 768p, 16:9. The two sources answer different questions. Elo tells you about perceived quality. Latency tells you whether the model fits into a real-time workflow.

The scores and speeds behind the picks are summarized in the table below.

Model	AA image-to-video Elo	fal benchmark: one 10-second clip	Appears in picks
FLUX 3 Max	1,139	12.45 seconds	1, 2, 3, 6
Seedance 2.5	1,139	277.8 seconds	5
H3 Max	1,125 plus or minus 17	3.49 seconds	4
FLUX 3 original	1,089	126.44 seconds	not in picks

The 1,139 scores come from Artificial Analysis' launch results for FLUX 3 Max, based on 4,868 votes. FLUX 3's 1,089 is its launch figure, with 1,086 plus or minus 16 on the public board. Latency values come from fal's benchmark for a 10-second video at 720p or 768p, 16:9. Scores are as of October 2026, and the leaderboard updates as new votes arrive.

The live Artificial Analysis image-to-video board with audio on October 24, 2026. The API pricing column is Artificial Analysis' own per-minute figure. The prices in this post are fal's 720p rates.

Why Elo Alone Is Not Enough

Developers often ask why a leaderboard number does not settle the argument. Elo captures human preference, but it does not capture the shape of your workload. A model with a high score but a five-minute latency forces you to design a queue, a progress bar, and a retry policy. A model with a slightly lower score but a 3.5-second latency can feel like a native video effect. For product work, speed is not a nice-to-have. It is part of the user experience.

The other missing dimension is cost. Two models can share an Elo score and still price very differently. Seedance 2.5 shares 1,139 Elo with FLUX 3 Max, but at 720p on fal it costs about $4.73 per 10-second clip compared with FLUX 3 Max's $1.70 list price. During the launch discount, the gap grows even wider. A team generating hundreds of clips must care about that gap.

There is also the question of what the leaderboard does not measure. It does not tell you whether the model handles a specific brand style, a particular face, or a shot list that your client already approved. That is why the recommendations in this post come with a warning to run your own evaluation for any clip that will ship.

Deep Dive: FLUX 3 Max

FLUX 3 Max is fal's frontier video model, built by fal Research. It is a post-trained variant of FLUX 3 Video, tuned for stronger prompt adherence, better visual quality, and lower latency. It launched on fal on October 19, 2026.

The jump over its parent is large. The original FLUX 3 scored 1,089 Elo and took 126.44 seconds to render one 10-second clip in fal's benchmark. FLUX 3 Max scores 1,139 and takes 12.45 seconds. That is a 50-point quality gain and roughly a 10x speedup. The post-training stack is responsible for part of that, and fal's inference infrastructure handles the rest.

The model covers the basics that developers expect from a modern video model. You get 720p video with native audio. Generated clips can run from 5 to 20 seconds. Aspect ratios span 21:9 to 9:16, which covers cinematic stills, desktop video, and vertical short-form content. Built-in prompt expansion turns short prompts into richer ones, so you do not need to write a paragraph every time. fal Research continues to post-train the model, which means the behavior can improve without you changing your integration.

Why does post-training matter? A base video model learns how to generate plausible frames, but it may not follow instructions well. Post-training is a second phase that optimizes for specific outcomes: following a text prompt, keeping a subject consistent across frames, or making the camera motion feel intentional. The same base weights can become a fast preview model or a high-quality hero model depending on how the post-training is tuned. FLUX 3 Max is positioned somewhere in the middle: high enough quality to ship, fast enough to iterate.

What You Can Do with FLUX 3 Max

FLUX 3 Max is not a single endpoint. It is a model family that exposes three modes through fal:

Text-to-video. You provide a prompt and get a clip with no starting image. This is useful for brainstorming and for scenes that do not need a locked composition.
Image-to-video. You provide a starting frame and a prompt. The model animates from that frame. This is the natural fit for product shots, character stills, or any asset that already exists.
Keyframes-to-video. You provide a start frame and an end frame, plus a prompt. The model generates the motion between them. This is the storyboard tool.

Because all three modes are available under one integration, a team can start with text prompts for exploration, move to image-to-video for a controlled first frame, and switch to keyframes-to-video when the director wants a locked ending. The API stays the same, which reduces the number of moving parts in a production pipeline.

1. Best Overall: FLUX 3 Max

If I had to pick one model for a general-purpose image-to-video workflow, it would be FLUX 3 Max. It is the only model on this list with both a share of the top score and a 12.45-second turnaround. Seedance 2.5 has the same score but not the speed. H3 Max has the speed but sits 14 points lower on the public board.

The why is simple. A 12-second wait is acceptable in an interactive tool. A developer can call the endpoint from a web request, show a spinner for a few seconds, and return a video without building a complex job scheduler. A 277-second wait turns every generation into a background task that requires a progress bar, a callback, or a polling loop.

The watch out is also simple. Output is 720p. If a delivery specification asks for 1080p or 4K, you need a finishing step, either an upscaler or a separate render pipeline. The model is ideal for social clips, internal drafts, and concept boards. It might not be the final renderer for a broadcast commercial.

When 720p Is Enough

For many developer workloads, 720p is enough. Online ads, social posts, presentation backgrounds, and video previews rarely need more. The smaller resolution also makes video files easier to store, cache, and stream. If your product serves short video clips inside a webpage, 720p keeps bandwidth costs low. If you need a hero piece for a client presentation, you may want to upscale later. The key is to plan that step early rather than discovering it after your first batch of clips.

2. Best for Agencies Iterating on Concepts: FLUX 3 Max

Concept work is a volume game. Clients choose from options, and more directions per review means more chances to land on an idea that excites them. FLUX 3 Max is the strongest option for this because it produces roughly 22 drafts in the time it takes Seedance 2.5 to produce one.

The arithmetic assumes sequential, single-request generation. It is not a throughput test, but it is useful for estimating wall-clock time in a linear workflow.

Sequential, single-request math	FLUX 3 Max	Seedance 2.5
One 10-second clip	12.45 seconds	277.8 seconds
Clips in one hour, back to back	about 289	about 13
50 ten-second variants	about 10.4 minutes	about 3.9 hours
Clips in the time of one Seedance 2.5 render	about 22	1

Parallel requests shorten wall-clock time for both models, but each individual draft still takes as long as it takes. If you fire off 10 simultaneous requests to FLUX 3 Max, you can get a set of options in under 15 seconds. With Seedance 2.5, the same 10 requests might finish in roughly five minutes under ideal parallel conditions. Neither number is bad, but the feel is completely different.

The cost picture also favors FLUX 3 Max: $1.70 per 10-second clip at list price versus about $4.73 for Seedance 2.5 at 720p. On the quality side, the two are tied at 1,139 Elo. That means there is no clear quality reason to choose the slower model for early exploration. If your team eventually prefers Seedance's look for the hero cut, run the final round there. Both models are available on fal, so you can A/B test with the same API key.

Building an Iteration Loop

Agencies can build a simple internal tool around the model. A designer uploads a reference image, types a few prompt variants, and clicks generate. The backend sends the requests to fal, collects the returned video URLs, and presents them in a grid. Because FLUX 3 Max is fast, the designer can refine the prompt in the same meeting where the client is waiting. That turns a review session into a live working session.

The important part is to separate exploration from final delivery. Use the fast model to explore directions, then switch to the best-looking model for the chosen direction. You do not need to standardize on one model for every stage.

3. Best for Storyboarded Shots: FLUX 3 Max Keyframes-to-Video

When a board says "start here, end there," you do not want the model guessing the ending. FLUX 3 Max keyframes-to-video, available from FLUX 3 Max on fal, takes controlled start and end frames for storyboarded work.

What you need to lock	Endpoint	Inputs
The opening frame only	Image-to-video	image_url plus prompt
A pinned ending on a quick one-off	Image-to-video	image_url plus optional end_image_url plus prompt
Board-planned shots, start and end	Keyframes-to-video	Controlled start and end frames

The start and end frame inputs, image_url and end_image_url, are available in fal's FLUX 3 Max image-to-video playground. This is useful for directors who have a clear vision for the first and last frame of a shot but want the model to fill in the motion.

The start and end frame inputs in fal's FLUX 3 Max image-to-video playground. Screenshot: fal.ai, October 2026.

Why choose this option? You control composition at both ends of every shot. Storyboard shots also run through the same API as everything else, so there is no separate tool to wire up. A shot list can map directly to a set of API calls, each with a start frame, an end frame, and a prompt.

The catch is that both frames have to exist before you generate. That front-loads design work. You cannot ask the model to invent the ending after you see the beginning. You also need to keep shots under 20 seconds. Longer sequences become several shots cut together. For best results, keep the two frames close enough that the move between them reads as one believable action. If the end frame is too far from the start frame, the model has to invent too much intermediate context and the motion can feel unnatural.

Why Keyframes Matter in Production

Storyboard artists work in discrete panels. Each panel represents a moment in time. An image-to-video model that only takes a start frame forces the artist to describe the ending in text, which the model may or may not honor. Keyframes-to-video removes that ambiguity. The artist draws the last panel, uploads it, and the model knows exactly where the shot has to land. This is especially valuable for product visualization, where the final logo position or the final camera angle must be exact.

4. Best When Raw Speed Beats Everything: H3 Max on fal

H3 Max is fal Research's earlier post-trained frontier video model. It is the work that FLUX 3 Max builds on. In fal's benchmark, it produced video in 3.49 seconds, which makes it the even-faster option in fal's lineup. It scores 1,125 on Artificial Analysis' current board, where it is listed as MiniMax H3 Max.

Think of H3 Max as the same research team's other tool, not a rival. It is the model I would reach for when the result has to feel instant. Three and a half seconds is close to the boundary where a user stops perceiving the generation as a separate stage and starts treating it as a live effect. That opens the door to interactive sliders, preview-on-change, and rapid shot exploration.

Why use it? A 3.49-second turn suits live previews and any flow where even a short wait feels too long. If you are building a product where the user adjusts a prompt and expects to see a new clip within seconds, H3 Max is the safer bet. The quality is only 14 points below the top tie, which is a meaningful but small gap. For rough previews, the difference is easy to miss. For the clip that ships, I would use FLUX 3 Max.

Watch out for the caveats. The score of 1,125 is 14 points below the 1,139 tie. It may also have different input or output constraints. Check the fal model page for current inputs and pricing before you build an integration around it. Raw speed is valuable, but it is not a substitute for checking the actual output quality on your own content.

The Use Case for Ultra-Fast Previews

Imagine a video editor that lets you scrub through different motion styles. A user clicks smooth dolly, the backend sends a request, and in 3.5 seconds the clip updates. That is a very different product from one that shows generation in progress, check back in five minutes. If your product depends on interactivity, you may want to use H3 Max for previews and then use FLUX 3 Max or Seedance 2.5 for the final export. The extra integration work is small because all three are on fal.

5. Best If You Are Committed to ByteDance's Stack: Seedance 2.5

Seedance 2.5 shares the 1,139 score. If your team has prompt libraries, templates, or client approvals built around it, or an internal evaluation that prefers its look, there is no quality case for ripping it out. The model is strong enough to sit at the top of the leaderboard, and a tie means the average human preference is statistically indistinguishable from FLUX 3 Max.

The table below shows the cost and speed difference on fal at 720p as of October 2026.

On fal, 720p, as of October 2026	Seedance 2.5	FLUX 3 Max
Price per second	about $0.473 with audio	$0.17 list, $0.0425 at launch
Price per 10-second clip	about $4.73	$1.70 list, about $0.43 at launch
Time to a 10-second clip on fal benchmark	277.8 seconds	12.45 seconds

The main reason to keep Seedance 2.5 is ecosystem lock-in. If your prompt engineering team has written hundreds of prompts and refined them against Seedance's visual style, switching costs more than a model comparison. You also know how the model behaves in your existing pipeline. There is no quality reason to rip it out.

The catch is operational. At about 4.5 minutes per clip, every draft becomes a background job. If you need a dozen options for a client review, you need to parallelize aggressively and manage queueing. At 720p on fal, it costs about 2.8 times FLUX 3 Max's list price per second and about 11 times the launch price. Seedance 2.5 is billed by tokens, at $0.0214 per 1,000 tokens at 480p or 720p, so the exact cost shifts with aspect ratio. Check the current rates before committing to a large batch.

When to Stay with Seedance 2.5

You should stay with Seedance 2.5 if you have already built an evaluation set that prefers its output. You should also stay if your client or internal stakeholder specifically asks for a style that Seedance produces. In that scenario, you can A/B test it against FLUX 3 Max with the same fal key. Because fal hosts both models, the experiment takes minutes, not days. If FLUX 3 Max wins your eval, you can switch without changing billing relationships.

6. Best Budget at Scale: FLUX 3 Max During Launch Pricing

List price for FLUX 3 Max on fal is $0.17 per second at 720p, or $1.70 per 10-second clip. From October 19 to November 7, it is 75% off. After November 7, check fal's pricing page for current rates.

Window	Discount	Per second	Per 10-second clip
October 19 to November 7	75% off	$0.0425	about $0.43
List	none	$0.17	$1.70

To put that in campaign terms: a library of 500 ten-second clips costs about $212.50 at 75% off, or 500 times $0.425. At list, it costs $850. On Seedance 2.5 at 720p, the same library costs about $2,365, or 500 times about $4.73. For volume beyond that, enterprise teams can contact fal sales for further discounts.

Why choose this? During the launch discount, FLUX 3 Max is about 11 times cheaper per second than Seedance 2.5 at 720p on fal, with the same top-tier score. You also pay only for successful outputs. Queue time and failed generations are not billed. That makes it unusually friendly for batch production where some percentage of outputs will end up being discarded anyway.

The watch out is the expiration date. The discount is temporary. Budget anything after November 7 using fal's current pricing page. List price is $0.17 per second. Billing is per second, so a 20-second clip costs twice as much as a 10-second clip. If your workload uses long clips, plan accordingly.

Volume Planning With Failed Generations

Every generative model produces some percentage of unusable clips. Financial planning should include a retry budget. Suppose your success rate is 80%. To get 500 usable clips, you may need around 625 generations. At launch pricing, that is about $265.63, not $212.50. At Seedance 2.5 pricing, the same 625 generations would be about $2,956.25. The difference matters, and the pricing model that only charges on success reduces the cost of retries.

Honorable Mentions

Other models near the top of the public board deserve attention. MiniMax H3 sits at 1,140 plus or minus 16, which is actually the highest point on the board by a hair. Google's Gemini Omni Flash 1.1 sits at 1,132 plus or minus 17. Alibaba's Wan 3.0 sits at 1,127 plus or minus 16. They are credible models, and the leaderboard margins are small enough that a particular content type might make any of them the winner.

I left them out of the main picks because I cannot compare their speed or 720p cost on the same footing as the fal benchmark and fal prices used here. H3 is listed under MiniMax H3 on a different platform. Gemini and Wan have their own hosting routes. A proper comparison would need consistent latency and price measurements on identical hardware or API infrastructure, which is not what the public leaderboard provides. If one of those models is already in your stack, you should run your own evaluation rather than take my picks as absolute.

How to Choose

Use the decision guide below if you want a fast answer.

Someone is waiting on the result, such as a client on a call or a user in your app: choose FLUX 3 Max. About 12 seconds is a wait people sit through. Nearly five minutes is not.
You need many drafts per review: choose FLUX 3 Max.
The board fixes the first and last frame: choose FLUX 3 Max keyframes-to-video.
Instant previews matter more than the top score: choose H3 Max.
You are locked into Seedance 2.5: keep it, and A/B FLUX 3 Max on the same fal key.
You are generating volume before November 7: choose FLUX 3 Max at launch pricing.

My recommendation is to start on FLUX 3 Max on fal, then A/B Seedance 2.5 on the same key if your team cares about its look. One API covers text, image, and keyframes, so you can try all three modes without a second integration. The evaluation should measure visual preference, latency, cost, and failure rate on your own content. Do not rely on a leaderboard alone.

The Decision Matrix in Practice

Consider a team with four common tasks. For a client kickoff, they need a quick range of styles. FLUX 3 Max gives them 20 options in a few minutes. For a storyboard reveal, they need the ending to match the panel. Keyframes-to-video is the only tool that guarantees that. For a live preview in an editor, they need feedback in seconds. H3 Max is the right choice. For a high-volume batch before a campaign, the launch pricing on FLUX 3 Max wins. The same platform serves all four tasks, which simplifies procurement and integration.

Prompt Design for Image-to-Video

Prompting for video is different from prompting for images. In image generation, you describe a single frame. In video generation, you describe a state change over time. Use action verbs, camera moves, and temporal cues. Avoid static descriptions that do not imply motion.

Goal	Weak prompt	Better prompt
Camera move	zoom in	Slow push-in from a wide establishing shot to a close-up on the character's eyes
Action	the car moves	The car accelerates from a stop and turns left, kicking up dust
Ending	she smiles	She starts with a neutral expression and ends with a confident smile

FLUX 3 Max has built-in prompt expansion, but specificity still helps. The expansion feature is useful when you want to explore quickly. If you need a precise result, write the prompt as if you are directing a camera operator. Mention the subject, the motion, the framing, and the desired mood.

Reasoning Levels and Latency

The model exposes a reasoning_level parameter. At high reasoning, the model may expand short prompts and spend more time planning the output. At low reasoning, it skips extra processing and returns faster. This matters for two reasons. First, high reasoning can improve adherence on complex prompts. Second, low reasoning reduces per-request latency, which is important when you are serving interactive previews.

Test both levels on your own prompts. If the quality difference is small, choose low reasoning for speed. If the model misses important instructions at low reasoning, go back to high. The optimum depends on your content, not on the model's default.

Production Considerations for Image-to-Video APIs

Moving from a playground to production requires more than picking a model. You need to think about queueing, retries, storage, callback handling, and cost controls. The following sections cover the operational details that make or break a video generation pipeline.

Synchronous Requests vs Asynchronous Jobs

A model with a 12-second response time can be used synchronously from a backend. A user clicks a button, the server calls the video API, waits for the result, and returns the URL. This is simple to build and easy to reason about. A model with a 277-second response time cannot be used synchronously in a normal web request. You need a job queue, a database row for each generation, and a way to notify the client when the result is ready.

Even with FLUX 3 Max, synchronous requests have limits. A single web request that lasts 12 seconds can time out if your load balancer has a short timeout. You should either configure the timeout to something generous, such as 30 or 60 seconds, or move the generation to a background worker and poll for the result. The worker approach is more robust and also allows parallel generation.

Managing Concurrent Generation

If you want to generate 50 concept variants, you can fire 50 requests in parallel. The platform will handle the queueing, but you should still think about concurrency from the client side. A simple thread pool in Python or a worker queue in Node.js can keep your code organized. Here is a small Python example that uses a thread pool for parallel image-to-video generation.

from concurrent.futures import ThreadPoolExecutor, as_completed

def generate_clip(first_frame, last_frame, prompt):
    body = {
        'image_url': first_frame,
        'end_image_url': last_frame,
        'prompt': prompt,
        'video_length': 10,
        'generate_audio': True,
        'reasoning_level': 'high'
    }
    response = video_api.submit(body)
    return response.video_url

prompts = [
    'slow zoom into the subject',
    'handheld reveal from the left',
    'top-down shot with a soft shadow',
]

with ThreadPoolExecutor(max_workers=3) as executor:
    futures = [
        executor.submit(generate_clip, start_url, end_url, prompt)
        for prompt in prompts
    ]
    for future in as_completed(futures):
        print(future.result())

This is an illustrative example, not a copy-paste integration for a specific SDK. Use the actual client library and endpoint names for the model you choose. The point is that parallel calls are straightforward and should be part of your design.

Handling Audio Output

FLUX 3 Max generates native audio on by default. If your product already has a music bed or a voiceover, you may want to disable audio or replace it later. Native audio is useful for prototypes and for social-ready clips. It also increases the output size, so plan your storage and streaming choices accordingly. If you do not want audio, look for a parameter such as generate_audio and set it to false in your request.

Storing and Serving Generated Clips

The video API returns a URL. You can treat that URL as the output, but production systems usually copy the video into their own storage. That way you can add retention policies, rewrite URLs, and avoid depending on a temporary host. Cloud object storage with a CDN is a common choice. Keep the video format simple, such as MP4 with H.264, for broad browser support.

Cost Controls and Budgeting

Generate only what you need. Before sending a batch, estimate the number of seconds and the success rate. If a 10-second clip costs $0.43 during the launch discount, a mistaken loop that generates 1,000 variants costs $430. Add a concurrency limit, a daily spending cap, and an alerting mechanism to your integration. The pricing model on fal only charges for successful outputs, but a failed generation still consumes time and may occupy a slot in your queue. Use a small batch for testing before you scale up.

Retry Logic

Video generation can fail for many reasons: a malformed image URL, an unsupported aspect ratio, a prompt that triggers a safety filter, or a temporary service issue. Build retry logic with exponential backoff for transient errors. Do not retry immediately for errors caused by bad input. Log the failure reason and expose it in a dashboard so you can spot recurring problems.

Troubleshooting Common Failure Modes

Even with a strong model, things go wrong. Here are the most common failure modes and how to handle them.

Subject drift. If the main subject changes identity across frames, tighten the start and end frames. Add more descriptive language about the subject's appearance and clothing in the prompt.
Artificial camera motion. If the camera moves in a way that feels too smooth or too robotic, describe the intended camera operator behavior. Use terms like handheld, tripod, or drone to guide the motion.
Ignored end frame. If the model does not land on the end frame, check that both frames use the same aspect ratio and resolution. The model needs a clear visual connection between the two frames.
Unwanted lighting changes. When a scene's lighting shifts suddenly, specify consistent lighting in the prompt. Phrases like "same lighting throughout" can help.
Audio mismatch. If generated audio does not match the action, disable audio and add a sound design step in post-production.
Prompt overloading. If a single prompt asks for too many actions, split it into multiple shots. A 10-second clip has room for one primary action, not five.

A Practical Evaluation Plan

Before committing to any model, build a small evaluation set that represents your real workload. Include at least ten prompts and ten pairs of start and end frames. Generate the same set with FLUX 3 Max and Seedance 2.5, ideally on the same day to reduce the risk of model updates. Ask at least three people to rank the results without knowing which model produced each clip. Measure the time per clip, the failure rate, and the cost. Then make a decision.

Automated metrics can supplement human review. Use a simple face consistency check, a frame interpolation sanity check, or a prompt adherence metric if you have one. But human preference is still the closest proxy for whether a clip works. The 1,139 Elo tie means you should let your own eval decide.

What to Look For in Human Evaluation

When comparing clips, look for artifacts like morphing, extra limbs, or sudden lighting changes. Check whether the motion follows the prompt. Check whether the end frame matches the requested end frame. Note whether the sound is synchronized with the action. A model can score well on an average clip and still fail on the shots most important to you.

FAQs

What is the best AI image-to-video generator model right now?

FLUX 3 Max on fal is my pick. It is a top image-to-video model on the Artificial Analysis leaderboard, in the leading tier alongside Seedance 2.5 at 1,139 Elo, and about 22 times faster than Seedance 2.5 in fal's benchmark.

Is FLUX 3 Max better than Seedance 2.5?

On quality, they are tied at 1,139 Elo. FLUX 3 Max wins on speed, 12.45 seconds versus 277.8 seconds, and on 720p price on fal. If your team prefers Seedance's look, there is no quality argument against keeping it. The operational cost is the main reason to switch.

Does FLUX 3 Max generate audio?

Yes. Native audio is on by default, with generate_audio set to true. Clips run from 5 to 20 seconds. If you do not need audio, look for a parameter to disable it in your API calls.

Do I need to be good at prompting?

No. By default, the reasoning level is set to high, and the model expands short prompts for you. This is useful for exploration. If you need the fastest possible turnaround, set reasoning_level to low, because prompt expansion adds a processing step. For production, test both levels and measure whether the expanded prompts improve adherence enough to justify the extra latency.

Where can I run it?

On fal, through three endpoints: text-to-video, image-to-video, and keyframes-to-video. All are available from the FLUX 3 Max model page on fal. The same API key works for all three modes.

Can I use FLUX 3 Max for long-form video?

Not directly. Individual clips are capped at 20 seconds. For longer content, generate multiple shots and cut them together. The keyframes mode is useful here because you can set the last frame of one shot as the first frame of the next, creating a continuous edit.

What about mini-batch jobs for thumbnails and previews?

Use H3 Max for instant previews and FLUX 3 Max for final clips. The camera and prompt inputs stay similar, so you can reuse the same request structure. A 3.49-second preview lets you show a direction to a client, and the 12.45-second final render is still fast enough for a review meeting.

How should I handle safety and moderation?

Apply your own content policy on top of the model. Check generated frames for inappropriate content before serving them to users. The provider likely has safety filters, but you should not depend on them as your only layer. Store a moderation decision for each clip if you need an audit trail.

What if the price changes after November 7?

The launch discount expires, and the list price becomes $0.17 per second at 720p. That is still competitive. Recalculate your unit economics with the new price. If you have enterprise volume, contact fal sales for custom rates.

Conclusion

The image-to-video space is moving fast enough that leaderboard positions are more like weather reports than permanent rankings. As of this October 2026 comparison, FLUX 3 Max offers the best balance of quality, speed, and price for most teams. H3 Max is the specialist for instant previews, and Seedance 2.5 remains a solid choice for those who value its ecosystem. The best move is to run a small evaluation, measure cost and failure rate on your own data, and choose a model that fits the way your team actually works.

If you are starting today, begin with FLUX 3 Max on fal. Try the image-to-video mode with a still frame, then explore keyframes-to-video for storyboarded work. Keep an eye on the Artificial Analysis board and fal's pricing page, because the next model release could change the recommendation again. In AI video generation, the only constant is that the next update arrives before you finish optimizing the current one.

Reference

This article was written in partnership with fal and originally published on the Pinggy blog.

FLUX 3 Max vs. Seedance 2.5: A Practical Field Guide to AI Image-to-Video Models

Lightning Developer — Wed, 28 Oct 2026 07:29:12 +0000

Introduction: The Image-to-Video Model Shortlist

The Six Picks at a Glance

#	Use case	Pick	Why	Watch out
1	Best overall	FLUX 3 Max	#1-tier quality, about 22x faster than its tie-partner	720p output
2	Agencies iterating on concepts	FLUX 3 Max	Around 22 drafts in the time of one	Run your own eval for the hero cut
3	Storyboarded shots	FLUX 3 Max keyframes-to-video	You set the start and end frames	Both frames have to exist first
4	Raw speed above all	H3 Max on fal	3.49 seconds in fal's benchmark	1,125 Elo, a step below the 1,139 tie
5	Committed to ByteDance's stack	Seedance 2.5 on fal	Same 1,139 Elo, same fal key	About 4.5 minutes and about $4.73 per 10-second clip at 720p
6	Budget at scale	FLUX 3 Max at launch pricing	About $0.43 per 10-second clip	75% off ends November 7

How the Picks Were Scored

The scores and speeds behind the picks are summarized in the table below.

Model	AA image-to-video Elo	fal benchmark: one 10-second clip	Appears in picks
FLUX 3 Max	1,139	12.45 seconds	1, 2, 3, 6
Seedance 2.5	1,139	277.8 seconds	5
H3 Max	1,125 plus or minus 17	3.49 seconds	4
FLUX 3 original	1,089	126.44 seconds	not in picks

The live Artificial Analysis image-to-video board with audio on October 24, 2026. The API pricing column is Artificial Analysis' own per-minute figure. The prices in this post are fal's 720p rates.

Why Elo Alone Is Not Enough

Deep Dive: FLUX 3 Max

What You Can Do with FLUX 3 Max

FLUX 3 Max is not a single endpoint. It is a model family that exposes three modes through fal:

Text-to-video. You provide a prompt and get a clip with no starting image. This is useful for brainstorming and for scenes that do not need a locked composition.
Image-to-video. You provide a starting frame and a prompt. The model animates from that frame. This is the natural fit for product shots, character stills, or any asset that already exists.
Keyframes-to-video. You provide a start frame and an end frame, plus a prompt. The model generates the motion between them. This is the storyboard tool.

1. Best Overall: FLUX 3 Max

When 720p Is Enough

2. Best for Agencies Iterating on Concepts: FLUX 3 Max

The arithmetic assumes sequential, single-request generation. It is not a throughput test, but it is useful for estimating wall-clock time in a linear workflow.

Sequential, single-request math	FLUX 3 Max	Seedance 2.5
One 10-second clip	12.45 seconds	277.8 seconds
Clips in one hour, back to back	about 289	about 13
50 ten-second variants	about 10.4 minutes	about 3.9 hours
Clips in the time of one Seedance 2.5 render	about 22	1

Building an Iteration Loop

3. Best for Storyboarded Shots: FLUX 3 Max Keyframes-to-Video

What you need to lock	Endpoint	Inputs
The opening frame only	Image-to-video	image_url plus prompt
A pinned ending on a quick one-off	Image-to-video	image_url plus optional end_image_url plus prompt
Board-planned shots, start and end	Keyframes-to-video	Controlled start and end frames

The start and end frame inputs in fal's FLUX 3 Max image-to-video playground. Screenshot: fal.ai, October 2026.

Why Keyframes Matter in Production

4. Best When Raw Speed Beats Everything: H3 Max on fal

The Use Case for Ultra-Fast Previews

5. Best If You Are Committed to ByteDance's Stack: Seedance 2.5

The table below shows the cost and speed difference on fal at 720p as of October 2026.

On fal, 720p, as of October 2026	Seedance 2.5	FLUX 3 Max
Price per second	about $0.473 with audio	$0.17 list, $0.0425 at launch
Price per 10-second clip	about $4.73	$1.70 list, about $0.43 at launch
Time to a 10-second clip on fal benchmark	277.8 seconds	12.45 seconds

When to Stay with Seedance 2.5

6. Best Budget at Scale: FLUX 3 Max During Launch Pricing

List price for FLUX 3 Max on fal is $0.17 per second at 720p, or $1.70 per 10-second clip. From October 19 to November 7, it is 75% off. After November 7, check fal's pricing page for current rates.

Window	Discount	Per second	Per 10-second clip
October 19 to November 7	75% off	$0.0425	about $0.43
List	none	$0.17	$1.70

Volume Planning With Failed Generations

Honorable Mentions

How to Choose

Use the decision guide below if you want a fast answer.

Someone is waiting on the result, such as a client on a call or a user in your app: choose FLUX 3 Max. About 12 seconds is a wait people sit through. Nearly five minutes is not.
You need many drafts per review: choose FLUX 3 Max.
The board fixes the first and last frame: choose FLUX 3 Max keyframes-to-video.
Instant previews matter more than the top score: choose H3 Max.
You are locked into Seedance 2.5: keep it, and A/B FLUX 3 Max on the same fal key.
You are generating volume before November 7: choose FLUX 3 Max at launch pricing.

The Decision Matrix in Practice

Prompt Design for Image-to-Video

Goal	Weak prompt	Better prompt
Camera move	zoom in	Slow push-in from a wide establishing shot to a close-up on the character's eyes
Action	the car moves	The car accelerates from a stop and turns left, kicking up dust
Ending	she smiles	She starts with a neutral expression and ends with a confident smile

Reasoning Levels and Latency

Production Considerations for Image-to-Video APIs

Synchronous Requests vs Asynchronous Jobs

Managing Concurrent Generation

from concurrent.futures import ThreadPoolExecutor, as_completed

def generate_clip(first_frame, last_frame, prompt):
    body = {
        'image_url': first_frame,
        'end_image_url': last_frame,
        'prompt': prompt,
        'video_length': 10,
        'generate_audio': True,
        'reasoning_level': 'high'
    }
    response = video_api.submit(body)
    return response.video_url

prompts = [
    'slow zoom into the subject',
    'handheld reveal from the left',
    'top-down shot with a soft shadow',
]

with ThreadPoolExecutor(max_workers=3) as executor:
    futures = [
        executor.submit(generate_clip, start_url, end_url, prompt)
        for prompt in prompts
    ]
    for future in as_completed(futures):
        print(future.result())

Handling Audio Output

Storing and Serving Generated Clips

Cost Controls and Budgeting

Retry Logic

Troubleshooting Common Failure Modes

Even with a strong model, things go wrong. Here are the most common failure modes and how to handle them.

Subject drift. If the main subject changes identity across frames, tighten the start and end frames. Add more descriptive language about the subject's appearance and clothing in the prompt.
Artificial camera motion. If the camera moves in a way that feels too smooth or too robotic, describe the intended camera operator behavior. Use terms like handheld, tripod, or drone to guide the motion.
Ignored end frame. If the model does not land on the end frame, check that both frames use the same aspect ratio and resolution. The model needs a clear visual connection between the two frames.
Unwanted lighting changes. When a scene's lighting shifts suddenly, specify consistent lighting in the prompt. Phrases like "same lighting throughout" can help.
Audio mismatch. If generated audio does not match the action, disable audio and add a sound design step in post-production.
Prompt overloading. If a single prompt asks for too many actions, split it into multiple shots. A 10-second clip has room for one primary action, not five.

A Practical Evaluation Plan

What to Look For in Human Evaluation

FAQs

What is the best AI image-to-video generator model right now?

Is FLUX 3 Max better than Seedance 2.5?

Does FLUX 3 Max generate audio?

Yes. Native audio is on by default, with generate_audio set to true. Clips run from 5 to 20 seconds. If you do not need audio, look for a parameter to disable it in your API calls.

Do I need to be good at prompting?

Where can I run it?

On fal, through three endpoints: text-to-video, image-to-video, and keyframes-to-video. All are available from the FLUX 3 Max model page on fal. The same API key works for all three modes.

Can I use FLUX 3 Max for long-form video?

What about mini-batch jobs for thumbnails and previews?

How should I handle safety and moderation?

What if the price changes after November 7?

Conclusion

Reference

This article was written in partnership with fal and originally published on the Pinggy blog.

Navigating the 2026 AI Decision Model Landscape: A Deep Technical Dive

Lightning Developer — Tue, 27 Oct 2026 11:38:00 +0000

In the modern software ecosystem, the vast majority of AI interactions are not creative writing tasks. Whether it is routing a support ticket, validating a tool call, or scoring an incident, these operations represent discrete, bounded decision problems. Relying on generative chat models to produce prose that must then be parsed into a programmatic condition is inherently suboptimal. It introduces unnecessary latency, ballooning costs, and the risk of malformed output. Instead, we have entered the era of the specialized decision model.

Since the introduction of TypeSafe Jev, the market has exploded with high-performance alternatives from OpenAI, Microsoft, Perplexity, Cloudflare, Liquid AI, and AWS. The Decision Index now tracks 174 distinct entries. These models output typed probabilities across a set of defined answers in a single forward pass, typically billed at a fraction of the cost of their conversational counterparts.

Architectural Divergence: Decision Models vs. Chat Models

When working with a standard chat model, you essentially treat it as a black box that accepts a prompt and produces a token stream. Decision models, however, operate on a fixed contract. You provide a state and a set of questions with predefined types. These types generally fall into three categories:

noul: A binary yes/no probability.
choice: Selecting from a specific list of options.
score: Evaluating an input on a continuous or ordinal scale.

The core advantage here is that the model processes all possible answers in a single pass. There is no risk of the model hallucinating an answer outside of your allowed set. The wire format is increasingly standardized around the TypeSafe POST /v1/systemone specification, which allows developers to switch providers with minimal configuration changes.

The Benchmarking Conundrum

Determining which model is best is non-trivial because the available benchmarks are optimized for different metrics.

JevBench focuses on a harmonic mean of intelligence, speed, and cost, heavily favoring lightweight, performant hosted APIs.
The Decision Index balances public benchmarks with private domain tasks and filters out slower models, making it a better indicator of real-world precision.
Artificial Analysis stands out by comparing decision models against traditional LLMs, finding that while decision models win on cost and speed, they can occasionally be overconfident on complex knowledge queries.

A Comparative Analysis of Top Contenders

1. TypeSafe Jev

Jev remains the industry benchmark. With a cost of $0.042 per million input tokens and output tokens provided for free, it is highly economical. The recent 1.14 update introduced experimental features like bounding boxes and expanded context windows. While some minor discrepancies exist between benchmark rankings for different versions, Jev remains the safest "default" choice for high-reliability integrations.

2. Liquid AI d1-ultra and d1-3B

Liquid AI is currently setting the pace with its hosted d1-ultra model. It consistently outperforms Jev on JevBench while maintaining competitive pricing. For local execution, the d1-3B model is exceptionally fast, though developers should be mindful of the LFM Open License commercial revenue caps.

3. Perplexity pplx-decider v1.2

For those needing an open-weight solution from a reputable vendor, Perplexity offers the most efficient models. The 27B variant is a fine-tune of Qwen and boasts the highest accuracy scores of any model on this list according to the Decision Index. It is an excellent choice if you have the VRAM to support it.

4. Microsoft-Decision-1

Hosted on Microsoft Azure AI Foundry, this model excels in enterprise environments where data residency and existing infrastructure are key. It implements the standard TypeSafe protocol, making it a drop-in replacement for Jev-based codebases.

5. OpenAI Decisions API

If you already utilize OpenAI services, the new /v1/decisions endpoint for gpt-6-luna is the most seamless integration path. It offers the same compliance and security guarantees as the rest of the OpenAI ecosystem, though at a slightly higher price point.

6. Cloudflare Clef

Cloudflare has integrated decision models directly into the Workers ecosystem via Workers AI. Clef and Clef-flash are optimized for low-latency edge computing. The availability of Clef-omni, which handles audio and video, provides a unique capability for multi-modal decision pipelines.

7. AWS Strands Decider 2B

Built by the AWS Strands Labs team, this is the premier model for local, self-hosted deployment.

pip install "strands-decider @ git+https://github.com/strands-labs/strands-decider"
strands-decider serve StrandsAgents/strands-decider-2B-qwen3.5-v1-2610 --port 8000

Production Considerations and Implementation

Running these models locally or in production requires careful attention to input construction. As demonstrated by our testing, the phrasing of your questions and the descriptive labels provided for choices significantly affect the resulting probabilities.

When building out your infrastructure, we recommend implementing a "shadow mode" testing phase. Capture a sample of your traffic, run it through multiple candidate models, and track your metrics over a week. Do not rely solely on third-party leaderboard scores; your specific domain data will behave differently than generalized benchmarks.

To ensure low latency during inference, ensure your environment is configured for the appropriate hardware backend. For Apple Silicon users, utilizing the MPS backend via PyTorch is essential. If you are deploying on server-grade hardware, prioritize models that support continuous batching and quantization to keep costs down.

Managing Complexity and Edge Cases

Decision models are essentially probability engines. When a model returns a confidence score below a certain threshold (e.g., 0.85), you must have a fallback mechanism. This could involve triggering a human-in-the-loop review process or escalating the request to a more capable generative model.

Furthermore, keep track of model versioning. As shown with Jev 1.13 vs 1.14, performance can fluctuate between minor releases. Always pin your model versions in production and run automated regression tests against your core decision-making logic whenever you update to a new checkpoint.

Troubleshooting and Optimization

If you find your model is failing on specific categories of input:

Context Clutter: Ensure you are not sending unnecessary context in the state object. Keep it focused on the decision task.
Calibration: Check your Expected Calibration Error (ECE). If the model's confidence is consistently misaligned with its accuracy, you may need to apply a scaling factor or reconsider your question framing.
Ambiguity: Ensure your option definitions are mutually exclusive. If there is overlap in the semantic definition of two choices, the model will struggle to assign a distinct probability.

In conclusion, the right decision model is the one that best balances cost, speed, and accuracy for your unique workload. With the current rate of innovation, we expect these models to become even more specialized by the end of 2026. Start with Jev for prototyping, test Perplexity or Liquid for performance, and lean on enterprise-grade endpoints from Microsoft or OpenAI for production compliance.