News & Updates
The latest news and updates from companies in the WLTH portfolio.
Vercel AI SDK in production: when DefaultChatTransport needs a session layer
A self-audit for Vercel AI SDK developers: four production requirements DefaultChatTransport wasn't designed for, when they become blockers, and what a session layer adds. You've built an AI chat app on the Vercel AI SDK. It works in development. The model responds, the stream comes through, and the UI updates cleanly. Then you ship to production, and the transport layer starts showing its edges. Most of these failures are quiet: things that work in demos and break in ways that are hard to pin down until you know where to look. They share a common cause: is built for HTTP, and HTTP has structural properties that some production requirements exceed. This piece explains what those limits are, which ones matter for your application, and what replacing the transport actually involves. Key takeaways * uses HTTP POST and Server-Sent Events (SSE). These protocols are one-way and point-to-point. That's correct behavior for a stateless serverless platform, not a bug in the SDK. * fires the abort signal client-side and returns immediately. GitHub issue #9707 (open, October 2025) confirms the server cannot distinguish an intentional stop from a dropped connection, and may continue generating and billing until completion. * The official Vercel AI SDK stream resumption pattern requires Redis, the resumable-stream package, two custom API endpoints, and a dedicated stop handler. In a resumable stream setup, is treated as a disconnect, not a cancel. * The interface is pluggable by design. Vercel's serverless platform cannot host persistent WebSocket connections, so they made the transport layer swappable. Replacing with a WebSocket-based transport layer creates a durable session between your agent and client, without changing your agent, tool calls, or UI rendering. How DefaultChatTransport works, and the conditions it was built for When you call without a transport option, or pass a default config, is what runs. It sends outgoing messages via HTTP POST, and receives responses as an SSE stream. For a single user on a stable connection, sending a message and waiting for the response, this is the right choice. A stateless serverless function receives the request, calls the model, and streams the response back. HTTP is the right tool for that, and uses it correctly. That behavior follows from a platform constraint: Vercel's serverless functions terminate after responding, so there is no persistent process to hold a socket open. That's the root of all four limits. They're architectural, not configurable, because HTTP on a stateless platform simply can't do what they require. The Ably guide to WebSockets on Vercel covers this constraint in depth if you want the full picture. That's also why Vercel made pluggable in AI SDK 5. is not broken: it's correct for the conditions it was built for. But Vercel designed the interface precisely so teams can swap in a transport that isn't bound by those conditions. It's not just that has this constraint. Even , the other built-in option, explicitly documents that it "does not support reconnection since there is no persistent server-side stream to reconnect to." Reconnection is a transport-layer property. The default implementations don't have it because the platform they're built for doesn't support it. Four things DefaultChatTransport can't do in production These are the limits that surface when you move beyond a single-user chatbot: a customer support agent that hands off between devices, a chat interface where a human and an AI both participate, or any application where the connection dropping mid-generation has a visible cost to the user. Each follows from the same root: HTTP/SSE is built for one connection, one client, one response. When production asks for more, that constraint becomes visible. Cancellation is ambiguous, and you may be paying for it. When a user clicks stop, closes the HTTP connection client-side, and returns immediately, without waiting for the server to acknowledge or terminate the generation. The server receives a connection close event. It has no way to distinguish that from a tab close, a network drop, or a mobile device going to sleep. So it keeps generating. GitHub issue #9707 (filed October 2025, still open) documents this directly: does not detect the abort signal server-side, making it "impossible to stop ongoing AI generation and leading to unnecessary costs and poor UX." GitHub issue #10844 adds that Vercel's own config flag behaves unreliably in production deployments. The cost is real: orphaned generations run to completion, and there's no reliable mechanism to stop them without a custom server-side endpoint. Multi-device delivery silently fails. SSE is one-to-one. One HTTP connection, one client, one stream. A user with the same session open on their laptop and phone receives the response only on the device that sent the request. The second device gets nothing: no error, no partial content, no indication that anything is in flight. This isn't a useChat configuration gap. It's a structural property of HTTP. Multi-device fan-out is absent from the vast majority of AI transport implementations because SSE is one-to-one by design. is no exception. The same architectural root connects the next limit. Where multi-device delivery requires fan-out that HTTP cannot provide, stream resumption requires session persistence that HTTP cannot maintain. Stream resumption requires infrastructure that you build and own. The Vercel AI SDK stream resumption documentation lists the prerequisites directly: a Redis instance, the resumable-stream package, a POST handler that creates resumable streams using , a GET handler at that resumes them with , and a dedicated stop endpoint. stop() and resumable streams are also architecturally incompatible. The docs state it directly: "In a resumable stream setup, client-side aborts are treated as disconnects. Closing a tab, refreshing the page, or calling stop() only closes the current HTTP connection and should not cancel the underlying generation." Adding a working stop button requires a separate server-side endpoint to cancel the underlying work and clear the active stream record. Tab switches and mobile backgrounding are a further gap the resumable-stream pattern doesn't cover in the same way as a page reload. The Ably guide on Vercel AI SDK resumable streams covers the distinction. The single-response assumption breaks multi-user sessions. Vercel designed around one user sending one message and receiving one response. It tracks one at a time. If a second user joins, or an observer device needs the same response lifecycle, the only available mechanism is . This bypasses lifecycle hooks, tool-call notifications, and callbacks entirely. It works, but it's a workaround. Zak Knill's post on building the Ably transport covers the implementation detail. Each of the four limits above has the same root cause but surfaces differently. The table below maps them to their production cost: How a WebSocket-based transport layer creates a durable session between agent and client Replacing with a WebSocket-based transport layer replaces a stateless HTTP connection with a durable session between your agent and your users. One that persists beyond any single connection and addresses all four limits directly. It also removes the custom infrastructure that those limits force you to build. The Ably topic page on implementing a custom covers the full capability surface. This section covers what disappears from your backlog. With a WebSocket-based transport layer, you no longer need: * The Redis buffer for resumable streams * The stop endpoint with race condition protection * The fan-out layer for multi-device delivery * The workaround for multi-user sessions The mechanism that makes this possible is straightforward. A session is decoupled from the connection. The session persists independently; a connection is how a client subscribes to it. When a client disconnects and reconnects, it presents its last position to the session and receives only the messages it missed. A cancel signal is sent explicitly on the session: the server reads it as intent, not as a connection close event it has to interpret. Ably AI Transport is built as the session layer for production AI applications: the infrastructure between your agent and your users that handles the delivery concerns that can't. It plugs into as a implementation via a single configuration change: In practice: stop() sends a typed signal the server can act on, instead of a connection close event that it has to guess at. Any device subscribed to the same session receives the stream, so a user switching from laptop to phone doesn't lose the conversation. If the connection drops mid-generation, the client reconnects and catches up from where it left off, because the session persists independently of any single connection. What stays unchanged: your agent, tool calls, message persistence logic, and UI rendering. The swap is the option in . Everything built on top of it carries over. For the implementation detail on own-turns, observer-turns, and handling, see Zak Knill's post. For how transport options compare more broadly, see the durable sessions guide for Vercel AI SDK applications. The four questions in the next section will help you work out whether you're at that decision point yet. When DefaultChatTransport is still the right choice The four limits above are real, but they only become blockers if you need cancellation that reaches the server, multi-device delivery, stream resumption beyond page reloads, or more than one user in the same conversation. For many applications, remains the right starting point. A practical way to assess your own situation is to work through four questions: If the answer to all four is no, is a defensible choice. If any answer is yes, the relevant section above describes the specific limit you'll encounter. The right time to replace the transport is when those limits start costing you. If the self-audit above lands on yes for any of the four questions, has reached its limit for your use case. The transport layer is the right place to fix it, and replacing it changes nothing else in your application. The next step is understanding the interface: what and require, and what to look for in an implementation. The Ably ChatTransport topic page covers that in full. To get started with Ably AI Transport directly, the Vercel AI SDK integration guide is the right starting point. Frequently asked questions Does the Vercel AI SDK support multi-device AI chat out of the box? Not with . SSE is scoped to a single HTTP connection, so a second device has no way to join a stream already in progress. Multi-device delivery requires a transport where the session exists independently of the connection, so any subscribed client receives it. The Ably guide on why Vercel AI SDK can't stream to multiple devices provides the full picture. Why doesn't cancel server-side generation in Vercel AI SDK? Because has no signal path back to the server. When stop() closes the HTTP connection, the server receives a TCP close it can't distinguish from a network drop, so generation continues and billing runs to completion. With a WebSocket-based transport layer, stop() sends a typed cancel message on the session; the server reads it as intent, not inference. The Ably guide on why stop() doesn't cancel the stream covers the full mechanism. How much infrastructure does Vercel AI SDK stream resumption require? The official pattern requires a Redis instance, the package, a POST handler with , a GET handler at , and a dedicated stop endpoint with race condition handling. and resumable streams are also architecturally incompatible. In a resumable stream setup, a client abort is treated as a disconnect, not a cancel. See the Ably guide to Vercel AI SDK resumable streams for the full breakdown. When should I replace ? When the limits start affecting your production application. The four-question self-audit in the "When DefaultChatTransport is still the right choice" section gives a practical framework. In short: if you need to reliably cancel server-side generation, multi-device delivery, stream resumption beyond page reloads, or multi-user sessions, the default transport can't provide those. The Ably durable sessions guide for Vercel AI SDK covers the transport options available once you've decided to move on. Why replace with a WebSocket-based transport layer? When 's design scope no longer fits your production requirements. If you're hitting unconfirmed cancellations, single-device delivery, Redis-dependent stream resumption, or the setMessages workaround for multi-user sessions, those are properties of HTTP/SSE that a WebSocket-based transport layer resolves at the transport level. Your agent, tool calls, and UI code don't change. Vercel AI SDK custom transport vs default transport, what actually changes? The delivery mechanism only. Your agent, tool calls, message persistence, and UI rendering stay the same. The swap is the option in , one configuration change. For a full before/after and getting started guide, see the Ably AI Transport Vercel integration guide.
Anthropic Is Turning Claude Design Into More Than an AI Design Generator - Memeburn
The tool is available in beta for paid Pro, Max, Team, and Enterprise users on web and desktop, not as a separate standalone product. Claude Design launched in April with the kind of traction most product teams only dream about: over a million users in its first week. It also had a problem just as fast. One PCWorld reviewer burned through 80 percent of a weekly Claude Pro allowance in about 25 minutes, and got just three variations of a single webpage out of it. Anthropic's June update is meant to address that, and it changes a lot more than just the token math. When Claude Design Launched, and Why It Needed Work Claude Design launched in April 2026 as a research preview. The early rollout showed what the product could do. It also made one gap obvious fast: people liked the output, but the tool was too expensive to use more than a few times before hitting a wall. Anthropic shipped the new update on June 17. The stated goal is to make the tool more practical and less wasteful for everyday use. A Closer Look at the New Features Claude Design now connects more directly with the rest of a designer's toolkit, from imported brand systems to a real editor to a tighter handoff with Claude Code, covered in detail below. Design System Imports Claude Design pulls specs from GitHub repositories, design files, or local codebases, then validates them before output. The result is interfaces built from a team's real components, spacing, and typography instead of generic layouts. Canvas Editing and Layout Tools Anthropic added finer control over every element on the canvas. Users can drag, resize, and align components without wasting a model turn on every small tweak. Stability Fixes Anthropic says the update includes hundreds of stability fixes. That should mean fewer errors, fewer regenerations, and less token drain than before. Claude Code Sync Claude Design now syncs both ways with Claude Code. The /design-sync command pulls a design system into a project, while /design lets developers create, edit, and sync designs from the terminal. Finished work can also go back into the canvas for visual polish. Expanded Export Options Claude Design now exports to PDF and PowerPoint, plus connects to Adobe, Base44, Canva, Gamma, Lovable, Miro, Replit, Vercel, and Wix. Anthropic wants it to be the start of the workflow, not the end. Admin Controls for Enterprise Teams A new admin role lets one person approve and lock a design system so the rest of the team stays on brand. The feature is reportedly off by default on Enterprise plans. Why the Token Problem Mattered So Much Liking a tool and being able to use it regularly are different things. The PCWorld example made that gap obvious: strong results, but usage limits ran out long before the work did. Anthropic's fix works on two fronts. The company says the average turn now uses fewer tokens for the same result, with lower error rates. Claude Design also now shares usage limits with chat, Claude Cowork, and Claude Code. That matters because people can return to the tool for repeat work without burning through their plan so quickly. How People Are Using It Day to Day Start with a prompt to generate mockups. Import an existing design system so the output matches the brand. Edit elements directly on the canvas instead of rewriting prompts for small fixes. One early example comes from Tenex, where a team member called Claude Design their first stop for design directions, brand assets, and presentations. They pointed to the mix of frontier model intelligence with traditional design tool functionality, plus a smoother handoff into Claude Code. Where It Fits in Pricing Claude Design is included in beta with every paid Claude plan, not sold separately. Here's how the plans break down: For individuals, the question is simple: does your current plan leave enough usage headroom for design work too. For teams, the admin controls and Claude Code integration are the bigger draw. Why It Matters Now Most AI design tools focus on generating something that looks good. Anthropic is going after the layer underneath that: who owns the workflow once design work needs to become real software. Tying design, code, and brand control into one product is also a platform play, not just a feature update. It gives teams fewer reasons to leave the Claude ecosystem once they start building in it. Whether Claude Design earns a permanent spot in daily workflows, rather than getting tried once and shelved, is the open question now.
Anthropic Supercharges Claude Design With Code Integration & Direct Editing
Anthropic is making its next move with a major update to Claude Design. After attracting more than one million users in its first week, Claude Design is getting a significant expansion focused on helping teams move faster between design, development, and deployment. At the center of the update is deeper support for design systems. Users can now import components from GitHub repositories, existing design files, or raw uploads, allowing Claude Design to generate interfaces that align with company standards from the start. For larger organizations, Anthropic is also introducing new administrative controls that let teams approve and lock a single design system across projects. Anthrooic deeply integrates Claude Design and Claude Code Anthropic is also deeply integrating the connection between Claude Design and Claude Code as well. Designers can use the new "/design-sync" command to pull existing design systems into projects, while developers can create, edit, and sync designs directly from the terminal using "/design." The company is also rolling out a rebuilt editor with direct canvas controls, giving users the ability to drag, resize, align, and fine-tune elements without relying entirely on prompts. Besides design and code workflows, Anthropic is expanding Claude Design's ecosystem with new integrations across Adobe, Canva, Gamma, Miro, Replit, Vercel, Wix, Lovable, Base44, and several other platforms. Claude Design now lives directly in the Claude desktop app sidebar and remains available in beta for Pro, Max, Team, and Enterprise subscribers.
Eve - Vercel
An instructions.md file is a complete agent. Describe its role in Markdown, then run eve. Eve uses a default model. Add agent.ts when you want to choose a model or configure the runtime. Skills are Markdown playbooks loaded when they are relevant. The agent gets focused guidance without carrying it in every prompt. Add a TypeScript file to tools/ and the model can call it. The filename becomes the tool name. No registration required. Every agent includes an isolated sandbox and file tools. Add sandbox/sandbox.ts to choose a backend or customize its setup. Add channel files to use the same agent in Slack, Discord, Teams, or the web. Connections handle authentication for services such as GitHub, Stripe, and Linear. Tools can call them without managing tokens. Add subagents for specialized work. The main agent delegates tasks and combines the results. Schedules run agents automatically for jobs such as daily reports and weekly digests. Work continues durably without an active session.
