A large batch becomes easier to operate when every record does not follow the same path. Start with DeepSeek V4 Flash for a tightly scoped first pass, then route selected records to Qwen3.7 Plus for review. Treat this split as a workflow hypothesis to validate, not a guarantee that one model handles every difficult case better.
This first lap builds a restartable pipeline for tagging support tickets. The same structure works for catalog cleanup, document extraction, and other record-oriented jobs.
1. Define the ticket contract before splitting the batch
Choose a small, explicit output contract: record identifier, category, urgency, supporting excerpt, and review reason. Define allowed category and urgency values. Require the supporting excerpt to come directly from the input, and allow an unknown value when evidence is missing.
Give each source record a stable identifier and attach a prompt version. Save the original input separately from model output. These details make it possible to trace a bad label, rerun one record, and compare results after changing instructions.
2. Connect both model routes through SwiftRelay
SwiftRelay is a practical fit when you want both routes behind one OpenAI-compatible integration with pay-as-you-go, per-token billing. Sign up for SwiftRelay, create an API key, and keep it in an environment variable rather than in source control.
For an OpenAI-compatible SDK, set the base URL to https://api.fastapirelay.com/v1. Configure separate model settings for DeepSeek V4 Flash and Qwen3.7 Plus, using the exact API identifiers available in your account. Do not assume display names are valid request identifiers. First send one test request through each route and inspect the response format.
3. Calibrate the split on labeled tickets
Before launching the full dataset, assemble a labeled sample containing routine tickets, ambiguous requests, missing context, and conflicting signals. Run both models against the same contract. Measure category correctness, urgency errors, unsupported excerpts, and invalid outputs against your labels.
Use those results to decide which cases deserve review. If Qwen3.7 Plus does not improve a particular error class, change the prompt or routing rule rather than sending more records there automatically. Record token usage during this test to estimate the cost of the proposed split.
4. Give DeepSeek V4 Flash the first-pass queue
Start with one ticket per request to simplify retries and isolate malformed responses. Ask DeepSeek V4 Flash to produce only the required fields, then validate them in application code. Check allowed values, required fields, identifier matches, and whether the supporting excerpt actually appears in the ticket.
Use a bounded worker queue instead of launching the entire dataset at once. Set request timeouts and output limits appropriate to the contract. Save each completed result immediately so a process restart does not discard finished work.
5. Route review candidates to Qwen3.7 Plus
Send records to Qwen3.7 Plus when deterministic checks fail or when your calibrated rules identify ambiguity. Useful triggers include missing evidence, an unknown category, or ticket content that matches multiple category definitions. Do not rely only on a model-generated confidence score.
Give the reviewer the original ticket, category definitions, and the specific review trigger. Ask for a fresh decision grounded in the source. You can initially omit the first-pass answer to reduce anchoring. If review still leaves insufficient evidence, mark the record unresolved rather than inventing a label.
6. Make retries and checkpoints safe for both routes
Track pending, running, completed, review-needed, and failed states. Persist the route, attempt count, prompt version, validation outcome, and available usage metadata. Retry transient failures with capped exponential backoff and jitter; do not endlessly retry invalid credentials or malformed requests.
Use the record identifier and prompt version as your local deduplication key. This prevents duplicate result writes, but does not guarantee duplicate API calls are free. After an interrupted request, reconcile saved state before resubmitting.
7. Reconcile the batch before publishing labels
Require every input identifier to end with exactly one accepted result or an explicit unresolved status. Audit samples from both routes, including records that never triggered review. Compare actual token spending with your estimate and inspect which routing rules generated useful corrections.
Publish only validated outputs. Keep unresolved tickets in a separate queue, then adjust the next run using observed errors rather than assumptions about either model.