Flue

​

How Flue differs from the built-in runtimes

​

How a turn runs

​

Start with a prompt

agent.toml
prompt.md
skills/
  triage/
    SKILL.md

name = "support-triage"
model = "anthropic/claude-haiku-4-5"

[runtime]
family = "flue"

​

Deploy from GitHub

1. Push a prompt-defined root to GitHub, fork the Flue starter, or push your own app.
2. Open Agents → Create agent → Import from GitHub.
3. Install the OpenComputer GitHub App on the repository, then select the repository, production branch, and root directory.
4. Choose Review agent. OpenComputer resolves one exact commit and checks the root without running repository code.
5. Review the detected Flue entrypoint and model. Give the OpenComputer agent a human-readable name; it may differ from the agent.toml Flue entrypoint.
6. Choose Deploy agent. A guided setup page opens immediately and keeps the deployment running in the background. It shows compact Prepare, Build, and Deploy progress; expand the build log only when you need it.
7. Choose Connect Slack as the next step. Slack authorization returns to setup, which changes to Open Slack as soon as both the agent and connection are ready and prompts you to send your first message.
8. Send the message in Slack. Setup detects the real managed-Slack session, previews the first exchange, and links to the full session in OpenComputer. If you leave early, use Continue setup from the agent page.

​

Deploy from your machine

oc agent init ./support --runtime flue
cd support
$EDITOR prompt.md

# Upload source, build in isolation, verify the live Worker, and print its URL.
oc agent deploy

git clone https://github.com/diggerhq/oc-flue-starter
cd oc-flue-starter
npm install

# Builds the Cloudflare target locally, deploys it, verifies the live Worker, and activates a revision.
# The agent is created from agent.toml when it does not exist yet.
oc agent deploy

# The deploy result prints the permanent Agent URL and this next command.
oc agent invoke support-triage \
  --data '{"message":"Order 2203 arrived with a torn shoulder strap. What happens next?"}'

​

Validate or build without deploying

# Reads and validates source without installing dependencies or running repository code.
oc agent build --dir . --check-only --json

npm ci
oc agent build \
  --dir . \
  --target cloudflare \
  --output /tmp/flue-build \
  --json

​

Add OpenComputer to a Flue app

npm install @opencomputer/flue

import { defineAgent, defineAgentProfile } from "@flue/runtime";
import { DEFAULT_MODEL, route, useOcGateway } from "@opencomputer/flue";

export { route };

export default defineAgent((ctx) => {
  useOcGateway(ctx);

  return {
    profile: defineAgentProfile({
      instructions:
        "Triage customer requests and give the next concrete action.",
    }),
    model: DEFAULT_MODEL,
  };
});

export { default } from "@opencomputer/flue/app";

name = "support-triage"
model = "anthropic/claude-haiku-4-5"

[runtime]
family = "flue"

​

What @opencomputer/flue supplies

​

Custom tools and packaged skills

import { defineTool } from "@flue/runtime";
import * as v from "valibot";
import orders from "../data/orders.json" with { type: "json" };

export const lookupOrder = defineTool({
  name: "lookup_order",
  description: "Look up an order by id.",
  input: v.object({ order_id: v.string() }),
  run({ input }) {
    return (
      (orders as Record<string, unknown>)[input.order_id] ?? { found: false }
    );
  },
});

import triage from '../skills/triage/SKILL.md' with { type: 'skill' };

// Inside the object returned by defineAgent:
{
  tools: [lookupOrder],
  skills: [triage],
}

​

Optional sandbox and working repositories

import { defineAgent, defineAgentProfile } from "@flue/runtime";
import {
  DEFAULT_MODEL,
  ocRepoTools,
  ocSandbox,
  route,
  useOcGateway,
} from "@opencomputer/flue";

export { route };

export default defineAgent((ctx) => {
  useOcGateway(ctx);

  return {
    profile: defineAgentProfile({
      instructions:
        "Work in the sandbox only when a shell or file operation is needed.",
    }),
    model: DEFAULT_MODEL,
    sandbox: ocSandbox(ctx.env),
    tools: [...ocRepoTools(ctx)],
  };
});

​

Variables and secrets

[vars]
SUPPORT_REGION = "eu-west"

printf '%s' "$SUPPORT_API_KEY" | oc agent secret set SUPPORT_API_KEY --from-stdin
oc agent secret list

# A configuration change takes effect on the next deployment.
oc agent deploy

oc agent secret delete SUPPORT_API_KEY
oc agent deploy

​

Deployment and revision behavior

1. Scans the source tree for credential-shaped values.
2. Runs the app’s installed flue build --target cloudflare.
3. Uploads only the generated JavaScript modules and a restricted deployment descriptor.
4. Applies platform-owned bindings, variables, secrets, and Durable Object migrations, then uploads the agent Worker.
5. Keeps the deployment in verifying until the exact live Worker returns two consecutive healthy responses. Only then does the CLI report the revision as ready.

​

Session behavior

• Session creation and steering return after durable acceptance. Model execution continues asynchronously.
• Each accepted input receives an OpenComputer trn_... id. Flue’s internal submission identity is not part of the public API.
• Follow-up messages queue behind the working turn and run in order.
• The model is compiled into the deployed app. Per-session model overrides are rejected.
• Durable model-call usage is folded into turn and session usage with attribution: "best_effort". Use it for visibility; the agent/org gateway is the hard spend-enforcement authority.
• Generic tokens, turn_seconds, and turns limits are not yet enforced on the Flue execution path. Do not use them as a safety boundary for this runtime.
• Archiving makes the OpenComputer session read-only but retains the Flue conversation in Durable Object storage. Each session is subject to Cloudflare’s 10 GB Durable Object storage limit.

​

Current limitations

• Dashboard sessions and the OpenComputer-managed Slack app deliver direct text through the hosted session wire. Native Flue channel bindings and workflows are not exposed by this hosting path.
• Working-repository checkout and pull-request publishing are available through the owner-bound OpenComputer GitHub App. Pull-request watches are not part of the current Flue profile.
• Repository deployment accepts one self-contained npm root with a committed npm lockfile. Pushes to its linked production branch deploy automatically; preview branches and staged Flue Workers are not supported.
• Each production push is re-inspected at its exact commit. Valid Flue changes—including the entrypoint, model, variables, package, and app source—deploy within the pinned flue-app-v1 profile; removing or replacing that profile stops before build and leaves the active revision unchanged.
• File and image attachments are not supported.
• The managed gateway currently supports Anthropic models and requires Managed model access for the organization. Per-session model selection is not supported.
• Worker code has a platform-managed outbound allowlist. Tenant-configurable egress is not available.
• Platform turn deadlines, maximum-turn enforcement, automatic conversation compaction, and automatic tenant-Worker rollback are not available yet.
• Subagents may execute inside Flue, but their event projection and lifecycle are outside the tested profile.

​

Troubleshooting

• Repository inspection fails: confirm the GitHub App can read the repository, the selected branch and root exist, and the root contains agent.toml, package.json, and package-lock.json.
• Managed install or build fails: open the deployment detail page. The safe error summary remains available even if log output was truncated; fix the source and push the production branch again.
• flue build is unavailable: run npm install with Node 22.19 or newer. oc agent deploy never downloads a missing build tool for you.
• Credential scan refuses the deploy: remove the reported key from source and store application secrets with oc agent secret set ... --from-stdin.
• Deployment fails while verifying: the uploaded Worker did not reach a stable healthy response. Inspect the deployment error, correct the import-time or health-route failure, and deploy again.
• Provider authentication fails on the first turn: confirm that Managed model access is active for the organization and that the agent uses an anthropic/... model.
• A skill is missing: import its SKILL.md with with { type: 'skill' } and include it in the agent’s skills array.
• A session shows an error or stops advancing: inspect the dashboard’s All events view or run oc session logs <session-id>. Runtime failures are recorded without requiring a diagnostic redeployment.