Moving a Decision Workload From Drex Max to Gemini Decision 1

The port looks like a URL change and is not one. Drex Max v1.1 and Gemini Decision 1 both take a block of context and a set of typed questions and return probabilities, so the first afternoon of a migration goes well: rename the field, point the client at a different base path, run the test suite. What fails is the second week, when the volume arrives and the two billing models turn out to disagree about what you are buying. This is the account of what actually has to change, written for someone holding a working Drex Max v1.1 integration and wondering whether the newer model's headline score justifies the move.

Start with the honest version of the trade. On the Artificial Analysis Decision Index v2.1, Drex Max v1.1 scores 73 and Gemini Decision 1 scores 66. The older model wins, and it wins by 6.6 points, most of it in the component that carries 30% of the composite. If your workload is document triage, the migration is a downgrade dressed as an upgrade. If it is something else, keep reading, because the two endpoints are not as similar as their request shapes suggest.

The difference that is not on any leaderboard

Drex Max v1.1 gives every question its own 131,072-token budget. Gemini Decision 1 gives the whole request 262,144 tokens, shared between the input and every question in it. Those two sentences describe the same product category and produce opposite engineering advice.

On Drex, asking 200 questions costs 200 separate budgets, and the practical ceiling on a request is your rate limit rather than the context. On Gemini Decision 1, 200 questions and one 200,000-token contract do not fit in the same request: 200,000 tokens of input leaves 62,144 for the questions and instructions, which is comfortable, but a 250,000-token input leaves 12,144 and the request fails. The ceiling is real, it is shared, and it moves depending on how much you send.

This is the single change most likely to break a working Drex integration, because the failure mode is not an error at low volume. A test suite passing 20 questions over a 30,000-token document fits comfortably in both systems. Production, with a 180,000-token record and 900 questions, fits in one and not the other.

What the per-token price hides

Drex Max v1.1 is listed at $0.03 per million input tokens as a launch price against a $0.06 list rate, and Gemini Decision 1 is $0.10. Neither charges for output. Read that column alone and Drex is between 1.7 and 3.3 times cheaper, which is enough to end the conversation for a high-volume team.

Measured per task, the gap narrows. Artificial Analysis puts Drex Max v1.1 at $103 per million decision tasks and Gemini Decision 1 at $345, a ratio of about 3.3 — the list-price comparison, not the launch price. The reason is that Gemini Decision 1 reads more tokens to reach an answer. Its shared context is twice the size and its component scores suggest it is putting more input through each question rather than less. Per task, the honest spread is roughly three to one in Drex's favour, and the launch discount is a temporary condition that will not survive your second contract renewal.

Which means the pricing question is not "which is cheaper" but "what fraction of your tasks would you pay 3× to get right". A rule that routes support tickets to a queue is worth nothing if it is wrong 5% more often than the alternative. A rule that flags a contract clause for legal review is worth the difference immediately.

Document handling is where the scores come from

The 6.6-point composite gap is not spread evenly, and the migration argument depends on knowing where it lives.

• AA-Paperclip, 30% weight — Drex Max v1.1 scores 72.8 and passes 63% of documents outright on the all-or-nothing test; Gemini Decision 1 scores 56.8 and passes 33%. This one component accounts for most of the composite difference.

• When2Call, 10% — Drex 95.3 against Gemini's 80.5, a 14.8-point gap on tool-calling judgement, the widest proportional lead Drex holds anywhere.

• EvalSafe-O*NET-AA, 15% — 88.3 against 87.1. A rounding error, and the one safety-adjacent test in the set.

• AA-Omniscience-Decision v1.1, 15% — Drex 60.3, Gemini 66.3. Gemini's lead, and the reason its launch coverage led with knowledge.

• HLE-MultiChoice v1.1, 15% — Drex 46.6, Gemini 48.7. Narrow, and both models decline rather than guess often enough that raw accuracy is far below these numbers.

• AA-Symmetry v1.1, 15% — Drex 79.8 against 70.5. Whether the answer survives the question being reordered, relabelled and negated, which is the closest thing on the board to a stability test.

Two of those rows are worth a second look before you commit. On document extraction Drex is nearly twice as reliable on a strict metric, and on symmetry it is nine points steadier — meaning a Drex-based pipeline produces fewer answers that flip when the same question is phrased differently. If your product surfaces a single answer to a user, instability is a bug report. If it feeds a downstream score, instability is variance you can average away.

Speed, and the case for keeping both

Drex Max v1.1 runs a task in a median 283 milliseconds. Gemini Decision 1 runs the same task in 211. The newer model is faster despite doing more work, which is the one place the migration helps without qualification. For a synchronous check in front of a user-facing action, 70 milliseconds is not nothing.

Speed and price and accuracy rarely line up this cleanly in one direction, and here they do not: Gemini is faster and worse, Drex is slower and better, and the cost ratio follows the quality ratio rather than the latency one. That is the signature of two models with genuinely different designs rather than one being a strict improvement.

Which is the actual recommendation. A decision service that has one scoring model has one point of failure and one opinion. Running both costs a second integration and buys a disagreement signal: when the two models return different answers at high confidence, the case is genuinely ambiguous and probably should not be automated. That pattern is old, it is boring, and it catches errors that no single model's confidence score will.

Porting the call itself

The mechanical part is smaller than the accounting part, with three traps worth naming before you start.

First, Drex is called at /v1/systemone with the model id pinned as drex-max; the drex-latest alias in the quickstart is not the pinned id, and using it means your model changes underneath you without a deploy. Gemini Decision 1 has the opposite problem: there is no alias at all, only gemini-decision-1, and a request naming gemini-decision will not resolve. Pin on both sides, and treat the model id as a version number in your config, not a constant in your source.

Second, media limits do not translate. Drex Max v1.1 accepts up to 8 images per request. Gemini Decision 1 accepts text, image, audio, video and PDF with limits of 100 MB of inline base64, 50 MB per PDF and 15 MB per HTTPS URL, and refuses YouTube links and gs:// URIs outright. A Drex pipeline that batches eight page scans per request becomes a Gemini pipeline that either sends the pages as one PDF or splits the batch.

Third, the question types are close but the bounds are not identical. Both support yes/no, choice and score. Gemini caps choice and score at 2–255 options or levels and clamps the yes/no probability to 0.01–0.99, so any threshold your Drex code set above 0.99 silently never fires after the port. Check every threshold constant in the codebase, not just the ones in the config file.

Where a router fits, and where it does not

OrcaRouter carries neither gemini-decision-1 nor drex-max. Both are probabilities-only endpoints, and a router in our shape fronts chat-completions targets; claiming otherwise would be an availability claim that fails at the first request. What the router is for in this migration is the part of the pipeline that is not the scorer.

Nearly every decision service is drafted before it is scored: a generative model extracts candidate clauses, proposes the rubric, or summarises the record into the shared context the decision model then reads. That drafting call is where vendor choice actually matters and where a second contract hurts, and it can run across more than 200 models on one endpoint with provider list price passed through at 0% markup. Routing DSL matters more here than in a chat product, because drafting calls are heterogeneous — a cheap model for triage, a long-context model for the 180,000-token record — and expressing that as rules beats expressing it as three SDKs.

The honest limit: failover protects the drafting call, not the scoring call. There is one place to send a decision request, and if it is unavailable your service is unavailable. If that dependency is unacceptable, the two-model pattern above is not just an accuracy measure — it is the only real redundancy available, because it is the only way to have two independent scoring endpoints.

Bottom line

Move to Gemini Decision 1 if your decisions are knowledge-shaped, if speed matters, or if you want a shared context large enough to hold a whole record once. Stay on Drex Max v1.1 if they are document-shaped — and the pass rate says they probably are, since document extraction is what most decision workloads turn out to be once you look. Run both if a wrong answer is expensive, and budget for the three-to-one cost ratio before you promise anyone a saving. The migration is a day of work and a quarter of re-tuning; the decision to make it is about which component of the index your workload actually resembles.