---

name: together-upgrade-migration description: >- Migrate Together AI Python SDK v1, OpenAI-compatible clients, deprecated models, or legacy dedicated endpoints with inventory, contract tests, canaries, and rollback. Use when upgrading Together dependencies or provider resources. Trigger with "upgrade Together SDK", "Together model migration", or "migrate Together endpoint v1". argument-hint: "[repository-path] [sdk|model|endpoint] [target]" allowed-tools: Read, Glob, Grep, WebFetch, Write, Edit version: 1.9.0 author: Jeremy Longshore jeremy@intentsolutions.io license: MIT tags:

• saas
• together-ai
• migration model: inherit effort: high compatibility: Designed for Claude Code; live migration verification requires authorized Together AI access

---

Together AI Upgrade and Migration

Overview

This skill moves one Together contract at a time while preserving response, model-quality, cost, and rollback evidence.

Prerequisites

• An inventory of SDK versions, API calls, model IDs, and dedicated resources
• Current migration, model lifecycle, and deprecation documentation
• Golden requests/evaluations plus latency and cost baselines
• A rollback target and owners for traffic, data, billing, and teardown

Tool Discipline

Use Read, Glob, and Grep to locate dependencies, direct calls, model constants, response assumptions, and endpoint management. Use WebFetch for current migration and deprecation contracts. Use Write or Edit only after scope and rollback are agreed.

Current Contract

• Python v1 is maintenance-only; new features target together>=2.0.0 and may use changed method/response shapes.
• OpenAI-compatible migration requires Together's base URL, project key, and Together model IDs.
• Same-lineage model upgrades may redirect after notice; materially new models require explicit migration and evaluation.
• New dedicated capacity uses v2 DMI; legacy v1 create/restart paths are retired.

Authentication

Preserve project-scoped TOGETHER_API_KEY injection while changing clients or endpoints. Never reuse development keys in production or expose a key during dual-run comparison.

Instructions

1. Classify the migration as SDK, model, compatibility layer, or dedicated endpoint and freeze the baseline.
2. Inventory every call, parameter, response field, model, job, retry, and management resource in scope.
3. Build contract and golden-quality tests before changing dependencies or routing.
4. Implement the target behind a reversible configuration or traffic boundary.
5. Canary with sanitized requests; compare behavior, latency, usage, errors, limits, and cost.
6. Promote explicitly, monitor, remove obsolete resources only after retention/rollback approval, and update the runbook.

Approval Boundaries

Do not accept silent model substitution, delete legacy endpoints, revoke keys, or shift production traffic without evaluated behavior and an executable rollback.

Output

Return source/target contracts, inventory, test delta, canary metrics, model/deprecation evidence, traffic state, rollback proof, obsolete-resource disposition, and owners.

Error Handling

Condition	Response
SDK response shape changes	Adapt at the provider boundary and keep caller contracts stable.
Model quality regresses	Roll back routing and revisit the candidate.
Legacy endpoint cannot restart	Move to v2 DMI; do not rely on v1 recovery.
Redirect is detected	Record the effective model and run migration evaluations.

Examples

The example below shows the minimum redacted evidence expected from a successful invocation of this operator workflow.

source=python-v1; target=python-v2; contracts=pass; canary=pass; rollback=verified

Resources

• Skill-specific official documentation
• Python v2 migration
• Deprecations
• Dedicated v1 migration