Binding reference Bindings

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

AI is a supported binding in Devflare, but it is intentionally treated as remote-oriented because real model inference lives on Cloudflare infrastructure.

That means the docs should be honest: Devflare can compile and type the binding cleanly, but meaningful tests usually need remote mode and real account access.

Config key: bindings.ai
Authoring shape: { binding: string }
Best for: Real inference against Workers AI models

Author it in the simplest shape that still says what you mean

AI is one of the clearest examples of Devflare choosing honesty over fantasy. The binding exists in config, the env is typed, and the deploy story is real — but model inference itself still lives on Cloudflare infrastructure.

That is why the testing story leans on remote mode rather than pretending Miniflare can be a credible stand-in for actual model execution.

Workers AI binding authoring

import { defineConfig } from 'devflare/config'

export default defineConfig({

name: 'ai-worker',

bindings: {

ai: {

binding: 'AI'

}

})

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.

Notes worth keeping visible

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.

Cloudflare docs vs the Devflare layer

Cloudflare Workers AI docs is the platform reference. This page is the Devflare translation layer: keep readable in source, understand the typed env surface, and know which local, preview, or remote lane actually matches the binding.

Reference

Cloudflare Workers AI docs

Cloudflare Docs

Platform reference for model access, remote inference behavior, pricing, and account prerequisites.

Question	Cloudflare docs	This Devflare page
Primary focus	Platform reference for model access, remote inference behavior, pricing, and account prerequisites.	How to author , what the runtime surface looks like, and how AI fits a Devflare project.
Testing and runtime lens	Cloudflare’s docs focus on the real remote product behavior, account requirements, and runtime constraints on the platform.	Remote-oriented; local tests require remote mode. Use the Devflare guidance when you need the honest local harness or the right remote gate instead of only the product API shape.
When to open it	When you need the platform contract, limits, APIs, or account-level product details.	When you are wiring, testing, previewing, or reviewing the binding inside a Devflare app.

Go deeper only if this one-page guide stops being enough

Subpage

AI internals

Internals

See normalization, Wrangler binding, and the preview or runtime details behind the authored shape.

Subpage

Testing AI

Testing

Start from after remote mode is enabled, plus and only escalate when the binding or deployment model genuinely needs it.

Subpage

AI example

Example

Adapt one small end-to-end path before you hide the binding behind a bigger abstraction.