Binding reference Bindings

Use the AI binding when the worker needs real Workers AI inference, not just a local mock

Workers AI lets Workers run Cloudflare-hosted machine-learning models through an env binding.

Devflare makes Workers AI usable by keeping the binding tiny in config, the worker call obvious, and the remote smoke test explicit instead of fake.

AI is still remote-oriented, but the first useful path is simple: one worker route, one call, and one skip-aware remote test that says clearly when the real platform was involved.

Config key
Authoring shape
Best for: Real inference against Workers AI models

Add the binding to config

AI is a remote-oriented binding, but the first worker path should still be tiny and concrete: receive one request, call one model, return one JSON response.

The Devflare-specific win is not fake local inference. It is that config, worker code, and remote test gating stay explicit enough that you know when the real platform was actually exercised.

Workers AI binding authoring

import { defineConfig } from 'devflare/config'

export default defineConfig({

name: 'ai-worker',

bindings: {

ai: {

binding: 'AI'

}

})

Use the binding from application code

After Devflare generates the worker env, import from and keep the first AI path close to the route, handler, or service method that needs it.

Keep this first path small enough that the config, env binding, and user-visible behavior are easy to review together.

A tiny inference endpoint

import { env } from 'devflare/runtime'

export async function fetch(): Promise<Response> {

const result = await env.AI.run('@cf/meta/llama-3.2-1b-instruct', {

messages: [{ role: 'user', content: 'Reply with OK only.' }],

max_tokens: 4

})

return Response.json({ result })

}

Local and Remote Support

Devflare supports the config, generated env shape, docs, and local application-flow work, but full fidelity requires Cloudflare remote infrastructure. Use local shims or fixtures for code your app owns, then connect to Cloudflare when the product behavior is the assertion.

Remote-oriented; local tests require remote mode. Keep local coverage focused on deterministic application flow through fixtures, mocks, shims, or Miniflare-backed wiring instead of pretending to reproduce Cloudflare-hosted product behavior.

Use Cloudflare when the ai call is expensive, flaky, or business-critical enough to need a separate release gate. This is the lane for full AI product fidelity, remote state, lifecycle behavior, and platform-specific limits.

When this binding fits best

Use AI when the worker should call a real Workers AI model.
Keep the binding dedicated to model work instead of pretending every route needs AI by default.
If the only goal is local happy-path UI wiring, use a normal fake at the app edge and reserve remote AI tests for the worker boundary.

Testing path

AI is remote-oriented, so local-only test runs should not be expected to exercise real inference.
Cloudflare auth and a resolvable account are part of the contract for meaningful AI tests. An explicit helps when the target account would otherwise be ambiguous, but it is not the only way Devflare can resolve one.
Because inference has cost and availability implications, it deserves more deliberate test gating than local-first bindings.

Do not present AI as a local-first binding

The honest story is that Devflare supports the binding cleanly, but real AI behavior still requires remote infrastructure.

Open the next page when you need it

Subpage

AI internals

Internals

Check emitted Wrangler binding, preview behavior, and Cloudflare-specific details.

Subpage

Testing AI

Testing

Pick the after remote mode is enabled, plus path first, then move to remote checks only when the test needs them.

Subpage

AI example

Example

Copy a fuller application path when the quick example is too small.