Change models.
See what breaks.

INSEAT builds open-source tools to check AI model changes and plan coding-agent workflows.

Illustrative offline walkthroughs below.

Switch / the refund check

Expected

42.5refunded

Observed

0still shipped

FAIL The call was valid. The refund wasn’t recorded.

Synthetic saved example · No live model call
Switch

Offline CLI · Early development

View Switch source

Expected a refund.
Got one?

Give Switch an expectation and a saved response. See which checks pass, fail—or can’t be tested.

Illustrative playback · saved example

Choose a saved refund scenario

Refund for order ORD-123456

Expected result

42.5

Refund recorded · refunded

Observed result

0

No refund recorded · order still shipped

Saved call: issue_refund · 42.5

Checker result FAIL

The recorded refund does not match.

  • PASS Tool name
  • PASS Arguments
  • FAIL Outcome
Inspect saved fixture 06

Same request. No saved outcome.

Expected result

Refunded

Status only · no amount assertion

Observed result

No record

Refund status and amount unknown

Saved call: issue_refund · 42.5

Checker result NOT TESTED

Missing evidence is not a pass.

  • NOT TESTED Outcome
  • Tool checks not requested
Inspect saved fixture 08
What this checks · fixture details and limits

Switch checks saved responses, not live providers. It does not execute refunds or verifiers. A pass covers only the configured checks and supplied evidence—not a universally safe model migration.

Fixture 06 · mismatch

expected: order.status = "refunded"
          order.refund.amount = 42.5
observed: order.status = "shipped"
          order.refund.amount = 0
tool-name: PASS
tool-arguments: PASS
outcome-assertion: FAIL

Fixture 08 · missing record

expected: order.status = "refunded"
checks: ["outcome-assertion"]
outcomeEvidence.candidate.record: absent
outcome-assertion: SKIP / not-tested
reason: no-outcome-evidence

Both synthetic fixtures save issue_refund({ orderId: "ORD-123456", amount: 42.5 }). Only fixture 06 checks that call. Other supported checks include structured output; outcome assertions support deep equality, JSON schema, property paths and saved verifier records.

Fusion

Dry-run planner · Experimental

View Fusion source

Who writes?
Who checks?

Give Fusion a task, risk level and model bindings. Inspect the planned roles and fallback paths before any agents run.

Dry-run plan · no agents executed

Choose a task to plan

You provide Low risk

Fix typo in CLI help text

One primary model; a typecheck command.

Need: a single solver for a narrow change.

Static policy chosen

Single

Low risk → one solver

Fusion produces Inspectable plan · PLANNED

  1. Solver

    Codex · read-write

    Fix the typo

One leg. No fallback or review leg in this plan.

Inspect low-risk task

You provide Medium risk

Add pagination to list endpoint

Primary + fallback models; typecheck and tests.

Need: a fallback if verification or scope fails.

Static policy chosen

Cascade

Medium risk + fallback + verification

Fusion produces Inspectable plan · PLANNED

  1. Solver

    Codex · read-write

    Add pagination

  2. Fallback solver

    Claude Code · read-write

    Only if solver fails verify or patch-scope

If both gates pass, no fallback. Repair limit: 0.

Inspect medium-risk task

You provide High risk

Rotate session token signing key

Primary + critic models; tests and security lint.

Need: independent review and bounded repair.

Static policy chosen

Critique

High risk + configured critic

Fusion produces Inspectable plan · PLANNED

  1. Solver

    Claude Code · read-write

    Propose key rotation

  2. Critic

    Codex · read-only

    Only if solver passes verify

  3. Bounded repair

    Claude Code · at most once

    Only if critic reports a blocking finding

Review cannot edit. No blocking finding → no repair.

Inspect high-risk task
What is available today · policies, gates and limits

These are three checked-in synthetic tasks under default-static-v1, not a live model router. The output is a plan, not a verified patch. No providers, worktrees, verifiers or changes are executed.

Planned gates

All solvers: verify and patch-scope. Critic: critic-output-valid. Every plan ends with verify, patch-scope and base-unchanged. All are PLANNED, not passed.

Critique allows at most one repair; Single and Cascade allow zero.

Fixture bindings

Single: codex:gpt-5-codex
Cascade: codex:gpt-5-codex
  → claude-code:claude-opus-5
Critique: claude-code:claude-opus-5
  → codex:gpt-5-codex (read-only)
  → claude-code:claude-opus-5

Model identifiers above are example fixture bindings, not recommendations or evidence of live compatibility. Current scope: static planning, adapter invocation construction/parsing, progress-schema validation and deterministic simulations. Budget fields are metadata, not aggregate spending enforcement; no cost or quality claim is made.

Try the source.

Public repos. Apache-2.0. No signup.

abenezer@inseat.app
Try Switch locallyApache-2.0

Node.js 22+ and npm. Clone the public repo, install, then run the checked-in fixture.

git clone https://github.com/inseat-labs/inseat-switch.git
cd inseat-switch
npm ci
npm run dev -- check examples/fixtures/06-tool-passes-outcome-fails.json

The fixture intentionally reports FAIL and exits nonzero. That is the expected result.

Inspect a Fusion planApache-2.0

Node.js 22+ and npm. This prints a plan without launching providers.

git clone https://github.com/inseat-labs/inseat-fusion.git
cd inseat-fusion
npm ci
npm run dev -- plan examples/tasks/high-risk-critique.json