Try it

See what your pipeline compiles to

Otium takes a multi-stage pipeline as one artifact and works out which dependencies are real, where the scheduler must stop chaining, and what the whole thing costs — before anything runs.

This is the real compiler, running in your browser. Nothing you type is sent to us — no account, no upload, no retention.

The starter pipeline has a deliberate flaw — one step waits on another for no reason. The compiler finds it below; delete the after: line it names and watch the graph get one step shallower.

Your pipeline Format guide →

name: support-triage
description: Classify a ticket, draft a reply, and tag it for routing.

input:
  schema:
    type: object
    required: [ticket]
    properties:
      ticket: { type: string }

schemas:
  classified:
    type: object
    required: [category, severity]
    properties:
      category: { type: string, enum: [billing, bug, howto, other] }
      severity: { type: string, enum: [low, normal, urgent] }
  reply:
    type: object
    required: [body]
    properties:
      body: { type: string }
  tags:
    type: object
    properties:
      tags: { type: array, items: { type: string } }

nodes:
  classify:
    target: { product: otium-small }
    # Your expected token usage. Otium can count the static bytes of this template, but not
    # your ticket text — so without this the cost below is a guess, and it says so.
    estimate: { tokens_in: 900, tokens_out: 60 }
    body:
      messages:
        - role: system
          content: "Classify the support ticket. Reply as JSON."
        - role: user
          content: "${input.ticket}"
    output:
      validators:
        - type: json_schema
          schema: { $ref: "#/schemas/classified" }
      on_invalid: { retry: 2, then: fallback }
    fallback:
      - { target: { product: otium-medium } }

  draft_reply:
    # Drafting is the creative lane, so it runs on a bigger model. The compiler notices the
    # lane change and records a barrier: the scheduler stops chaining here.
    target: { product: otium-medium }
    estimate: { tokens_in: 1100, tokens_out: 400 }
    body:
      messages:
        - role: system
          content: "Draft a support reply. Reply as JSON."
        - role: user
          content: |
            Category: ${nodes.classify.output.category}
            Severity: ${nodes.classify.output.severity}
            Ticket: ${input.ticket}
    output:
      validators:
        - type: json_schema
          schema: { $ref: "#/schemas/reply" }
      on_invalid: { retry: 2 }
      on_failure: continue

  tag:
    target: { product: otium-small }
    estimate: { tokens_in: 950, tokens_out: 40 }
    # Try deleting this line. Tagging reads the ticket and the classification — nothing the
    # draft produced — so this is an ordering constraint the data does not require, and the
    # compiler will say so.
    after: [draft_reply]
    body:
      messages:
        - role: system
          content: "Produce routing tags. Reply as JSON."
        - role: user
          content: |
            Category: ${nodes.classify.output.category}
            Ticket: ${input.ticket}
    output:
      validators:
        - type: json_schema
          schema: { $ref: "#/schemas/tags" }
      on_invalid: { retry: 1 }

name: support-triage
description: Classify a ticket, draft a reply, and tag it for routing.

input:
  schema:
    type: object
    required: [ticket]
    properties:
      ticket: { type: string }

schemas:
  classified:
    type: object
    required: [category, severity]
    properties:
      category: { type: string, enum: [billing, bug, howto, other] }
      severity: { type: string, enum: [low, normal, urgent] }
  reply:
    type: object
    required: [body]
    properties:
      body: { type: string }
  tags:
    type: object
    properties:
      tags: { type: array, items: { type: string } }

nodes:
  classify:
    target: { product: otium-small }
    # Your expected token usage. Otium can count the static bytes of this template, but not
    # your ticket text — so without this the cost below is a guess, and it says so.
    estimate: { tokens_in: 900, tokens_out: 60 }
    body:
      messages:
        - role: system
          content: "Classify the support ticket. Reply as JSON."
        - role: user
          content: "${input.ticket}"
    output:
      validators:
        - type: json_schema
          schema: { $ref: "#/schemas/classified" }
      on_invalid: { retry: 2, then: fallback }
    fallback:
      - { target: { product: otium-medium } }

draft_reply:
    # Drafting is the creative lane, so it runs on a bigger model. The compiler notices the
    # lane change and records a barrier: the scheduler stops chaining here.
    target: { product: otium-medium }
    estimate: { tokens_in: 1100, tokens_out: 400 }
    body:
      messages:
        - role: system
          content: "Draft a support reply. Reply as JSON."
        - role: user
          content: |
            Category: ${nodes.classify.output.category}
            Severity: ${nodes.classify.output.severity}
            Ticket: ${input.ticket}
    output:
      validators:
        - type: json_schema
          schema: { $ref: "#/schemas/reply" }
      on_invalid: { retry: 2 }
      on_failure: continue

tag:
    target: { product: otium-small }
    estimate: { tokens_in: 950, tokens_out: 40 }
    # Try deleting this line. Tagging reads the ticket and the classification — nothing the
    # draft produced — so this is an ordering constraint the data does not require, and the
    # compiler will say so.
    after: [draft_reply]
    body:
      messages:
        - role: system
          content: "Produce routing tags. Reply as JSON."
        - role: user
          content: |
            Category: ${nodes.classify.output.category}
            Ticket: ${input.ticket}
    output:
      validators:
        - type: json_schema
          schema: { $ref: "#/schemas/tags" }
      on_invalid: { retry: 1 }

Quick reference — what the keys mean

name: What the workflow is called. You submit against it by name and version.
input.schema: The shape of one item you submit. `${input.…}` reads from it.
nodes.<key>: One inference step. Its body is an OpenAI chat request with bindings substituted in.
target.product: What you bought — a SKU, not a model. Otium resolves the model at dispatch.
${nodes.x.output.y}: Read an upstream node’s output. This is what creates a dependency — you never declare edges.
after: [x]: Ordering with no data flowing. The only edge you write by hand, and the one the lint questions.
when: A structured guard. If it is false the node is skipped, and the skip propagates.
output.validators: What a good output looks like. A failure retries in place instead of costing another batch window.
fallback: Where to retry when validation keeps failing — a different product, or the same one with different parameters.
estimate: Your expected tokens in and out. Without it the cost figure is assumed from prompt size, and says so.
type: external: A step you run. The run parks, you do the work, you resume it — Otium never runs your code.

The full format — assets, external nodes, predicates, fallback policy — is in the workflow guide.