What Are the Four Product Paths in Bring Your AI?
Updated
Bring Your AI splits its toolkit into four distinct jobs: Move an existing setup between tools, Sync machines through a local hub, Distill a sanitized snapshot, and Build a first setup from public GitHub history. Which one fits you depends on whether you already have a working agent setup, whether you work across multiple machines, and whether you need to share or hand off context safely.
All four paths share the same constraints: the CLI runs locally, source files are read-only, target files are snapshotted before any write, and platform-native config stays target-local.
The four paths at a glance
| Path | Use it when | What it produces |
|---|---|---|
| 01 Move my setup | You already built context in one harness and want it in another | Migrated memories, rules, voice, workflows, MCP review notes, hooks, validation files, session analytics artifacts |
| 02 Sync machines | You work across machines and want one central hub | A local hub (placeable in your own Git repo) syncing Claude Code, Codex, and Cursor |
| 03 Distill a snapshot | You want to share or archive the useful parts without the risky ones | A sanitized Claude, Codex, or Cursor harness bundle with redaction metadata and verification |
| 04 Build from history | You have no setup yet and don't want to start from a blank rules file | A reviewed starter kit with confidence scores and source citations |
01 Move my setup
This is for keeping context you already built rather than rebuilding it. The migration carries memories, rules, voice, workflows, MCP review notes, hooks, validation files, and session analytics artifacts from a source harness to a target harness.
The workflow is preview-then-migrate:
$ bringyour preview --from claude-code --to codex
Claude Code found.
Codex found.
Move supported: yes
Existing setup can be kept: yes
Original files will not be changed.
$ bringyour migrate --from claude-code --to codex --policy merge
rollback snapshot: ~/.codex/.bringyour-snapshots/...
validation: BRINGYOUR-VALIDATE.md
✓ memories + rules
✓ MCP review notes
✓ skills + validation
✓ rollback snapshots
! hook differences flagged
✓ PII scrub audit
Two things to note in the output. First, --policy merge keeps your existing Codex setup rather than overwriting it. Second, hook differences are flagged, not silently applied — hooks are the part most likely to need manual review because they are platform-specific.
02 Sync machines
Sync keeps a central local hub without a hosted account. You place the hub in your own Git repo, and Claude Code, Codex, and Cursor sync through it.
The design constraint matters here: plans stay review-gated, and platform-native config stays target-local. So syncing does not mean one machine's config silently overwrites another's native settings — you review before anything lands.
Choose this path if you regularly switch between machines and are tired of drift between them. Skip it if you work on a single machine, where Move or Build covers you.
03 Distill a snapshot
Distill answers a different question: not "how do I move this" but "what is safe to keep or hand off?" It creates a sanitized harness bundle for Claude, Codex, or Cursor, with redaction metadata and verification attached.
The audit artifact checks hooks, MCP review notes, secrets, AGENTS.md/CLAUDE.md scope, and validation notes. The MCP migration guide preserves command and env references while flagging values that should stay in Keychain or environment variables rather than in the bundle.
Pick this path when you want to share a setup with a teammate, archive it, or publish it — anywhere the raw version would leak secrets or machine-specific paths.
04 Build from history
Build is for the blank-page problem. Instead of writing a rules file from scratch, it turns public GitHub work history into a first Claude Code or Codex setup, with confidence scores and source citations so you can see where each suggestion came from.
This is the only path that assumes you have no existing setup to move. If you already have context worth keeping, start with Move instead.
How to choose
- Have a working setup in one tool, want it in another? → 01 Move
- Work across multiple machines? → 02 Sync
- Need to share, archive, or publish a setup safely? → 03 Distill
- Starting from nothing? → 04 Build
The paths are not exclusive. A common sequence is Build (or Move) first, then Sync once you work across machines, then Distill when you need to hand context to someone else.
Pricing note
The site lists a Team Migration Pack at $499 for up to 10 people, alongside a Pricing page and a Buy page. The page also references "lifetime access while the product is young" and states "no subscription." Check the pricing page directly for current tiers and what each includes, since the available material does not break down per-path pricing.