HarnessAgent, Vercel's AI SDK layer, now accepts images across all agent adapters

Vercel updated HarnessAgent, the AI SDK layer that abstracts code agents running inside sandboxes, to accept image input across all available adapters. According to the changelog published by Vercel, this means any harness supported today can receive an image alongside text in the same message, without extra conversion code.

Before, giving visual context to an autonomous code agent required a workaround: manually describing the image in text, calling a separate vision model and pasting the result into the prompt, or simply not offering that kind of input at all. Now the harness itself delegates image processing to the vision model that already sits behind it.

What HarnessAgent is, for those who haven't been following

HarnessAgent is the AI SDK piece that standardizes how you instantiate, give a session to, and talk with third-party coding agents, known as harnesses. Instead of writing custom integration for each tool, the dev imports a harness (codex, for example) and uses the same HarnessAgent API to create a session, send messages, and receive responses, while actual execution runs isolated inside a sandbox.

The adapters covered by the update are Claude Code, Cline, Codex, Cursor, Deep Agents, fx, GitHub Copilot, Grok Build, OpenCode, and Pi. That's the entire list of harnesses the AI SDK supports today, which makes the change less a one-off feature and more a leveling of capability across all of them.

What the code looks like in practice

The image enters as one more item in the message's content array, in the same format the AI SDK already uses for multimodality in other contexts: a { type: 'text' } item next to a { type: 'file' } item with mediaType and data. The changelog's own example shows the codex harness describing an image read from disk:

import { HarnessAgent } from '@ai-sdk/harness/agent';
import { codex } from '@ai-sdk/harness-codex';
import { createVercelNetworkSandboxSession } from '@ai-sdk/sandbox-vercel';
import { readFileSync } from 'node:fs';

const agent = new HarnessAgent({ harness: codex });

const sandboxSession = await createVercelNetworkSandboxSession({
 runtime: 'node24',
 ports: [4000],
 template: await agent.getSandboxTemplate(),
});
const session = await agent.createSession({ sandboxSession });

const result = await agent.generate({
 session,
 messages: [
 {
 role: 'user',
 content: [
 { type: 'text', text: 'Describe the image in one sentence.' },
 {
 type: 'file',
 mediaType: 'image/png',
 data: readFileSync('image.png'),
 },
 ],
 },
 ],
});

Vercel's example is deliberately simple, but the pattern applies to any scenario where the agent needs to see something beyond text. Thinking about front-end work, the obvious application is sending a screenshot of a visual regression or a design crop for the agent to compare against the code it will itself edit inside the sandbox, without leaving the agent.generate() flow.

What this replaces and where the gain is real

In short: the change doesn't create a new function, it removes a workaround that was already common in agent pipelines. Anyone who today injects a text description of a screenshot into the prompt, or makes a separate call to a vision model before talking to the harness, can cut that step and let the harness itself handle the image.

This matters especially for those using HarnessAgent in a sandbox with an exposed port (as in the example, with ports: [4000]), because it opens up the possibility of closing the whole loop within the same session: the agent runs a development server, someone (or another process) takes a screenshot of the exposed port, and that screenshot comes back as image input in the next message, without leaving the session's context or switching APIs.

The limits that don't show up in the changelog

The changelog is short and doesn't go into detail about quality: it only confirms that image processing is done by the "underlying vision model of each harness." This has a direct implication worth pointing out, because it isn't explicitly written in the source:

• the ability to interpret images isn't uniform across the ten adapters, because each harness carries its own model underneath;
• a harness whose default model isn't optimized for vision will understand the image worse than another one, even with the same HarnessAgent API on top;
• there is, per the documentation cited, no way to force a specific vision model independent of the harness chosen.

In practice, this means it's worth testing the same prompt with an image across two or three harnesses before settling on which to use in production, instead of assuming Codex, Claude Code, and GitHub Copilot will react the same way to the same screenshot.

When it's not worth using this input

For tasks that require fine visual precision, such as measuring whether a spacing is within 2px of what's specified in a design, delegating the image to the harness is the wrong path: the interpretation goes through a language model with vision, not a pixel-diff tool. In these cases, automated visual regression checking (Percy, Chromatic, Playwright with screenshot comparison) remains more reliable than asking the agent to "look" at the image and evaluate it.

It's also worth remembering the cost: images consume more tokens than equivalent text in practically every multimodal model, and that adds to the normal cost of running an autonomous agent in a sandbox across several iterations. For a flow with a few one-off calls the impact is small, but for an agent that runs in a loop repeatedly reviewing UI, the extra token consumption per image is something to monitor before putting it into production.

The HarnessAgent image input documentation, referenced in Vercel's own changelog, is the natural next step for anyone already using one of the ten harnesses who wants to try the feature without rewriting their existing integration.