Combine Claude and OpenAI in Make.com: model selection & fallback

Published by GreenCircuit on

Flowchart of a Make.com scenario: trigger -> classifier -> router to Claude or OpenAI -> validator -> fallback branch -> logging and cost dashboard

Problem Context

Teams building production automations on Make.com often want to leverage both Anthropic Claude and OpenAI models in the same scenario so each task uses the model best suited to the job. Examples: using Claude for long-form summarization with high-recall safety guards, and OpenAI for short prompt completions, code transformations or embeddings. The challenge is implementing deterministic model selection, graceful fallbacks when a model fails or produces poor outputs, and maintaining cost and token visibility inside Make. The pattern below gives a concrete scenario you can implement immediately: task categorization, module sequencing, decision branches, retries, and telemetry.

Implementation Workflow

Overview: build a single Make scenario that receives an input (webhook, Google Doc trigger, or queue item), classifies the task type, routes the request to the preferred model, evaluates the response with lightweight validators, and falls back to the alternate provider when necessary. Key Make modules used: Webhook/Trigger, Router, OpenAI modules, Anthropic Claude module, Tools (JSON, Set variable), Iterator/Array aggregator, Error handler, and Logging (Google Sheets / monitoring).

  1. Trigger & Normalization

    Start with a webhook or native app trigger (Google Docs / Gmail / Slack). Immediately normalize payload into a single JSON object: {request_id, source, text, metadata}. Use the JSON module to enforce consistent field names and trim content to an initial token budget (e.g., 2,000 tokens) to avoid unexpected costs.

  2. Task Classifier

    Classify the task into a small set of types: summarize, extract, rewrite, generate, embed, analyze. Use a low-cost model (gpt-3.5 or a Claude lite call) with a short prompt that returns {task_type, confidence}. If you already have deterministic rules (keywords, length thresholds), implement them first and only call a model when rules are ambiguous. Persist classification and confidence to scenario variables for later auditing.

  3. Router & Preferred Mapping

    Use Make’s Router to map task_type to a preferred provider. Example mappings: summarize -> Claude (strong long-form coherence); extract -> OpenAI (structured extraction + embeddings); generate -> OpenAI GPT-4 / Sora; embed -> OpenAI Embeddings. In each branch call the appropriate provider module with a standardized prompt template that includes: request_id, task_type, instructions, and a token budget variable.

  4. Response Validation

    After the model returns, run deterministic validators: check response length, required fields for extraction tasks, and simple pattern checks (dates, numeric IDs). Run a quick quality check by asking a fast model for a 1–5 fidelity score or use heuristics (e.g., Jaccard overlap with source for extract tasks). Store validator outputs and quality score.

  5. Fallback Logic

    If the validator fails or quality score is below threshold, route to a fallback branch: (a) rerun with the alternate provider and adjusted prompt (explicitly request conservative answers or cite sources), (b) run both providers in parallel and call an aggregator model to merge results, or (c) escalate to human review. Limit retries to 1–2 attempts and annotate the run with failure reasons and attempts_count.

  6. Post-processing & Delivery

    Normalize final output, write provenance (chosen model, attempts, quality score, token usage) to your destination (Google Doc, CMS, database, Slack). Emit a telemetry row to your logging sink (Google Sheets or Datadog) containing: request_id, task_type, initial_model, final_model, fallback_used, quality_score, tokens_in, tokens_out, estimated_cost, latency, and error_reason if any.

  7. Error Handling

    Wrap provider calls with Make’s error handler. For transient HTTP errors or rate limits, implement exponential backoff (Make sleep + retry). For sustained rate limits or quota exhaustion, route non-critical tasks to a queued path that uses cheaper models later or waits for a scheduled window.

Architecture Notes

  • Use Make MCP Server for enterprise-grade credential management where available. MCP centralizes OpenAI keys and Claude Desktop access, reduces exposure in scenario designers, and simplifies rotation and auditing.
  • Keep prompt templates in an external source (Google Drive, Git) and load them at runtime. This enables prompt iteration without redeploying scenarios and keeps version history.
  • Token & cost accounting: capture usage fields returned by OpenAI modules and Claude responses. Compute per-call cost in a code module or Google Sheets and store daily aggregates for alerts.
  • Design idempotent operations: include request_id and dedupe logic to prevent duplicate model calls when retries occur or webhooks replay.
  • Parallelization trade-offs: calling both providers improves quality but doubles cost and increases orchestration complexity—prefer parallel calls only when high-fidelity output is required.

Risks and Guardrails

  • Safety & Hallucination: Use conservative prompt framing for factual tasks and include explicit refusal rules. Block outputs failing validator checks and route them to human review with context.
  • Data Leakage: Redact or hash PII before sending to models. Maintain a redaction module that replaces or masks sensitive fields and logs redaction actions for auditability.
  • Cost Overruns: Enforce hard token budgets, route non-critical jobs to lower-cost models, and implement daily spend alerts based on logged cost estimates.
  • Latency: Multi-model or aggregator flows increase response time. Use asynchronous user UX (acknowledge + notify when ready) for non-real-time tasks or spawn background scenario runs for heavy processing.

What To Do Next

  1. Inventory your workflow types and mark which truly need Claude’s strengths vs OpenAI’s capabilities (embeddings, code, speed).
  2. Build a single prototype scenario: trigger → classifier → router → provider → validator → output. Enable verbose logging for the first 1000 runs to tune thresholds and fallback behavior.
  3. Enable MCP or centralized credential management. Create a cost dashboard (Google Sheets) and Slack alerts for spend thresholds and repeated fallback patterns.
  4. When stable, extract classifier + router + validator into a reusable Make scenario template you can clone across business automations, and store prompt templates centrally to iterate safely.

Sources

This pattern focuses on deterministic model selection by task, pragmatic fallback logic, and operational guardrails to run multi-model automations reliably on Make.com.

Related Reading