together-deploy-integration
Deploy and roll back Together AI integrations across serverless inference or v2 Dedicated Model Inference with secret injection, health probes, traffic control, and cost shutdown. Use when releasing Together-backed services or dedicated models. Trigger with "deploy Together", "Together dedicated endpoint", or "Together rollout".
Allowed Tools
Provided by Plugin
together-pack
16 source-grounded operator skills for Together AI inference, batch, fine-tuning, deployment, security, and operations
Installation
This skill is included in the together-pack plugin:
/plugin install together-pack@claude-code-plugins-plus
Click to copy
Instructions
Together AI Deployment Integration
Overview
This skill separates application release from paid Together capacity changes and defines a reversible deployment for serverless or current v2 dedicated inference.
Prerequisites
- A tested application artifact and model-quality evidence
- Environment-scoped secret references and network egress policy
- Current model availability plus serverless or dedicated capacity decision
- Health, canary, rollback, cost, and teardown owners
Tool Discipline
Use Read, Glob, and Grep to inspect manifests, secret wiring, health checks, and rollback automation. Use WebFetch for current Together model and DMI lifecycle contracts. Use Write or Edit only for approved deployment files after the target platform is confirmed.
Current Contract
- Serverless needs no GPU provisioning and uses the shared inference API with a current model ID.
- New dedicated deployments use Together's v2 endpoint/deployment model and beta management surfaces.
- Legacy v1 endpoint creation is retired; do not publish
client.endpoints.create(model=..., hardware=...)as the new path. - Dedicated replicas bill while running. Scale to zero or delete after an approved rollback or experiment.
Authentication
Inject a project-scoped TOGETHER_API_KEY from the deployment platform's secret manager. Dedicated management also requires authorized project context; never expose management identifiers or Bearer headers unnecessarily.
Instructions
- Classify the workload as serverless or dedicated from latency, throughput, model, and utilization evidence.
- Pin the application artifact, SDK major, configuration schema, model policy, and secret references.
- For dedicated v2, resolve model/config resources, create the deployment, and poll to ready before routing traffic.
- Run a non-sensitive health probe that validates provider reachability and response shape.
- Shift a bounded canary while monitoring error rate, latency, usage, quality, and cost.
- Promote or roll back explicitly; scale obsolete dedicated replicas to zero and verify billing disposition.
Approval Boundaries
Do not provision paid hardware, change traffic weights, rotate production keys, or promote a model without the named owners and an executable rollback.
Output
Return deployment mode, artifact/model/config identities, secret reference, readiness and canary evidence, traffic state, cost state, rollback result, and teardown owner.
Error Handling
| Condition | Response |
|---|---|
Legacy v1 create returns 403 |
Stop and migrate to the current v2 DMI flow. |
| Deployment ready but routing fails | Verify traffic split and endpoint inference name. |
| Canary regresses | Route back and preserve redacted evidence. |
| Teardown unverified | Keep the change open; dedicated replicas may still bill. |
Examples
The example below shows the minimum redacted evidence expected from a successful invocation of this operator workflow.
mode=dedicated-v2; deployment=ready; canary=5%; rollback=verified; obsolete-replicas=zero