Showdown captain leverage: five slots are forced, one is a decision

A DraftKings Showdown entry is one captain at 1.5x salary and 1.5x points, plus five flex players from the same game. Everyone entering sees the same short list of names worth playing. The usual way to say what follows is that the captain slot is "where you differentiate," which is a slogan. Here is the arithmetic underneath it, and then an honest account of the part nobody in this repository can measure yet.

Six slots, 600%

Ownership is a conserved quantity, and the total is set by the roster rather than by the field's mood. In a Classic contest every entry holds nine players, so the ownership of every player on the slate sums to exactly 900%. A Showdown entry holds six, so the same sum is 600%.

The 600% is not one pool. DraftKings prices and counts the two slots separately, so the identity splits:

captain ownership, summed over the pool  = 100%   (one captain per entry)
flex ownership, summed over the pool     = 500%   (five flex spots per entry)

Both halves are definitional. Every entry names exactly one captain, so across any field the captain column sums to 100%; every entry names five flex players, so that column sums to 500%. GameScript's model is built to satisfy this rather than to discover it — SHOWDOWN_CAPTAIN_SLOTS = 1 and SHOWDOWN_FLEX_SLOTS = 5 in scripts/build-projections/ownership.ts, two softmaxes over the same pool, each scaled to 100 × slots. The captain one resolves first, and what it spends on a player is subtracted from what the flex one is allowed to spend on him; the reason that matters gets a section of its own below.

Now divide by the number of names. The one real DraftKings Showdown export committed to this repository — a byte-for-byte capture of draft group 152114, an LV @ HOU preseason game, taken 2026-08-15 — carries 67 players in 134 rows. On a pool that size the mean flex ownership is 500 / 67 = 7.5% and the mean captain ownership is 100 / 67 = 1.5%. The five flex slots have five times as much of the field's attention to spend on exactly the same names.

That ratio is the whole argument, and it does not depend on anyone's model. Five spots chasing one short list of playable names cannot help but overlap. One spot chasing the same list can.

The captain price makes value a constant

The 1.5x is applied to salary as well as to score. GameScript's format registry writes both multipliers on the same slot — salaryMultiplier: 1.5, pointsMultiplier: 1.5 in src/domain/slate-formats.ts — and the real capture agrees on the one price it carries: every captain row is $11,400 against a $7,600 flex row, exactly 1.5x, in all 67 pairs.

Take the standard value metric, fantasy points per $1,000 of salary, and evaluate it in the captain slot:

flex value    = p / (s / 1000)
captain value = 1.5p / (1.5s / 1000) = p / (s / 1000)

They are the same number. Not close — identical, for every player, on every slate where the captain price is exactly 1.5x. Value cannot rank captains, because the captain slot does not change any player's value. A projection ranking and a value ranking of the same pool disagree constantly; a flex value ranking and a captain value ranking are the same list.

The consequence for a model is sharper than it first looks. GameScript z-scores its features inside the group, and a z-score is invariant under multiplying the whole column by a positive constant. So are the two remaining salary-shaped features: the salary z-score, and the punt flag, which asks whether a player's salary sits under 0.6x the pool median — scale both sides by 1.5 and the comparison is unchanged. Wherever the captain price is exactly 1.5x, which is how the registry prices one, every input to the captain softmax is therefore the same as the input to the flex softmax.

Which means the entire difference between what this model believes about captains and what it believes about flex players is five numbers — five coefficients, weighing identical inputs. One thing does separate the two groups after the softmax runs, and it is a constraint rather than a belief: the flex group is capped per player by what the captain group already spent on him. That is the subject of the last section here, and it changes how much of a player the flex slot may buy, not what the model thinks he is worth.

The five numbers

They are the two beta vectors in scripts/build-projections/ownership.ts, in utility per standard deviation:

Read down the difference column and the model's opinion is legible in one pass: relative to a flex spot, a captain gains 0.30 of utility per standard deviation of projection and loses 0.50 per standard deviation of value, with the cheap-and-productive punt bonus cut to a third. It is the claim that captains are bought on ceiling and flex spots are bought on price, expressed as the only thing that can express it here.

Those five numbers were chosen, not fitted. The code says so — the comment above CAPTAIN_BETAS argues from the structure of the slot, not from a sample of contests, and notes that without a separate vector the captain distribution would be an exact rescaling of the flex one. That is a defensible prior. It is not a measurement, and the rest of this article is about the difference.

A worked example: constructed pool, real model

The pool below is invented — two teams, twenty names each, the favourite implied for 27 and the underdog for 20, salaries and projections chosen to look like a priced regular-season slate. The ownership columns are not invented: they are what computeShowdownOwnership returns for those inputs. The pool is committed at scripts/showdown-captain-example.ts and pnpm showdown:example prints this table, so the claim that you can reproduce these figures is a command rather than an assurance — and a test asserts, cell by cell, that what the model emits is what this page prints, so the day the model changes this article fails a check instead of quietly going stale. The top of the pool, sorted by captain share:

Five things in that table are worth more than the rest of it.

The columns sum, by construction. Over all forty names the flex column totals 500.00 and the captain column totals 100.00. That is the identity being obeyed rather than discovered — each group is scaled to its slot count on purpose — and it is worth showing for the same reason it is worth summing anyone else's ownership column: a source that scores players independently instead of as competitors for a fixed number of seats misses the total by a mile, and every leverage call made from it is wrong in the same direction.

Read the flex column with the captain column, because the model does. The rows are sorted by captain share and the flex column is not sorted at all — it rises from 41.42 to 58.03 and then falls away. That is not noise. Five of these players sit exactly at a ceiling, and the ceiling is a different number for each of them: what the captain slot left of him. QB A1's 41.42 is not an output of the flex softmax at all. It is 65 − 23.58, arithmetic, and you can do it in your head. The player the model most wants to captain is the player it can least afford to also flex, and after this subtraction he is only the fifth most-rostered flex player in the pool.

The flex slots are crowded, though less bluntly than that reads. 500% spread over forty names is a mean of 12.5%, and the top of a single-game pool is where it piles up: eight names carry 351.08 of the 500, and the four highest flex shares average 51.5%. That is the honest version and it is weaker than the one this paragraph used to make, which was that four players sat pinned at a flat 65% — in about two thirds of entries each. They no longer do, because the total-exposure bound took that share back off them and pushed it down the pool. About half of entries, spread over a few more names, is a real constraint on how different your flex slots can be. It is not the wall the previous number implied, and the previous number was measuring an error.

The captain slot is still the one that separates entries, by a narrower margin. Suppose entries were built independently at exactly these shares — they are not, and the numbers here are a shape rather than a duplicate count. Two of them would then share 1.83 of their five flex players, about 37% agreement per flex slot, and would name the same captain 14% of the time. The captain remains the slot two entries are least likely to have in common, 14% against 37%. The margin has moved twice and in both directions: before the exposure bound landed those figures were 26% against 45%, and house-v2 bounding how far the softmax extrapolates from a group's tail took the captain figure down again. The conclusion is the one thing that has not moved through either change, which is the only kind of survival worth anything.

The kicker is the mechanism in one row. K A has the best points-per-dollar in the pool at 2.11, and the model puts him in 29.53% of entries as a flex player and 1.55% as a captain. Nothing about him changed between those two columns except which beta vector read him. That is the -0.50 on value and the -0.10 on punt, doing the only job they exist to do.

What the roster shape settles without any ownership data at all

Two things fall straight out of src/domain/slate-formats.ts and need no model:

• Some bring-back is mandatory. A Showdown lineup must span two teams (minTeams: 2), so at most five of your six players come from one side — slateFormatMaxPlayersPerTeam is lineupSize - (minTeams - 1). In Classic, a bring-back is a decision about correlation. Here one player from the other side is a rule of the roster shape rather than a decision.

What the roster shape does not settle is which player, or whether the rest of the six hang together at all: five skill players from one team with the other team's quarterback satisfies minTeams perfectly and orphans both sides' points. So GameScript does express correlation rules on this format, in the reading one game supports, and they are on by default — each rostered quarterback needs a same-team pass catcher and an opposing skill player, at most two of a team's receivers may be rostered without their quarterback, and the captain seat has to pair with its own quarterback. docs/draftkings-csv.md carries the table; dfs_set_stack_rules is what replaces them.

• The captain is a salary decision before it is an ownership one. Captaining the $11,400 player above costs $17,100 of a $50,000 cap — 34.2% of the budget on one of six slots, and $5,700 more than flexing the same player. The 1.5x is not free upside; it is upside you buy at list price.

And one thing falls out of the scoring rules. A Showdown score is the sum of six raw scores plus half of the captain's, so one set of six players is six different lineups, and the best and worst of them differ by 0.5 x (best raw score - worst raw score). Two entrants can agree on every player in the game and still not tie. That is the sentence the slogan was reaching for.

What this article does not know

This piece sat in the repository as a draft from 2026-09-04, carrying its own list of what it needed before publishing: real captain-ownership distributions, and a worked example on a live Showdown slate. Both items now have answers. Neither answer is the one the draft was waiting for, and the reasons are more useful than the list was.

There is no reported captain-ownership distribution here, and it is not an oversight. Reported ownership — what a field actually did, rather than what a model guessed — comes out of DraftKings' full contest standings export, and that export is served only to a signed-in entrant; to anybody else it answers with a redirect to the login page. It is user-supplied data, uploaded by the account that played the contest, which is exactly how GameScript's contest_ownership_uploads table describes it. The repository's research store is open-web material, and it is pointed somewhere else: the Week 1 2026 scans reviewed 424 sources across a twelve-game main slate and contain no captain-ownership figure of any kind, because nothing in them touches a single-game contest.

The product is honest about this in the one place it matters. Every captain ownership figure GameScript reports is the house model's, always, and the optimizer says so in as many words: no projection upload column carries captain ownership, so a captain figure existing at all is itself the statement that it was modelled.

So the following are open, and this article claims none of them:

• Whether real fields concentrate on captains the way this model does. On the constructed pool above the model puts 23.6% of entries on one captain, which is still a claim about a field made by a prior with no contest behind it. It read 45.7% until house-v2 bounded how far the softmax extrapolates past a group's ordinary range, which is a large move for a change nobody made to the captain betas — and a fair warning about how much of that figure was ever a measurement. Nobody here has taken the one that would settle it.
• Whether a cheap kicker or defense in the captain slot is a real edge. The 2026-09-04 draft of this article asserted that they are "rarely right, occasionally the whole prize pool." Nothing in this repository supports either half of that sentence, so it has been cut rather than softened. What survives is narrower and checkable: the model discounts them heavily in the captain slot, for a stated reason.
• Whether the two softmaxes should be independent at all — found broken here, and since fixed. The version of this article drafted on 2026-09-04 ran its example through a model that resolved the captain and flex groups independently, and nothing tied a single player's two shares together. On this pool the top name came out at 110.7% across the two columns.

It is worth stating the bound exactly, because it is easy to state loosely. A player is either somebody's captain or somebody's flex or in neither slot, never two at once, so his two shares are shares of disjoint sets of entries and their sum cannot exceed 100%. That is an identity about a field, not a preference. Any tighter ceiling is a modelling choice sitting inside it. 110.7% broke the identity, which is why it was a defect rather than a debatable calibration, and the build-time check could not see it: it validated that the flex column reached 500% and nothing else.

The model now resolves the captain slot first and gives each player a flex ceiling of OWNERSHIP_CAP_PCT - cptOwnPct — what the captain slot left of him. So the binding constraint on this pool is 65.00%, not 100%: total exposure is now held at the model's own single-group cap, which is the choice, comfortably inside the identity it was violating. Both column totals are still exact. The check validates the captain total and the joint bound too, so the thing that hid this cannot hide the next one. What remains genuinely open is the calibration underneath: whether 65% is the right ceiling for a player's total exposure in a single-game contest is a question no contest in this repository can answer, and it is the same missing measurement as everything else in this section.

The second item on the draft's list resolves the same way. This repository holds a real Showdown pool and no real Showdown contest: the capture above is a genuine DraftKings export with genuine prices, and it is a preseason game, priced flat at $7,600 flex and $11,400 captain for all 67 players. Flat pricing makes value degenerate for everybody, which makes the one real pool available here the one pool that cannot demonstrate the value argument. So the worked example runs on a constructed pool and says so. A worked example on a live Showdown slate stays unwritten until a contest's standings sit in front of the model, and calling a constructed pool a live one to close the item would have cost more than the item is worth.

What would actually settle it

One upload. dfs_import_contest_standings takes a DraftKings full-standings export from the account that entered the contest; dfs_compare_ownership puts the model's projected captain share next to the field's actual captain share, player by player. Two or three of those, across contests of different sizes, would replace the five numbers in the beta table with something fitted.

Note the shape of what that produces, because it constrains what could ever be claimed from it: ownership belongs to a contest field, not to a slate. The same player is one number in a large-field tournament and a very different one in a three-entry-max, which is why the upload table keys on the contest rather than the slate. A captain distribution measured on one contest is a fact about that contest, and the sample needed before "captains are owned like this" becomes a general claim is larger than one Sunday.

Until then, the defensible version is the one this article is willing to sign: the flex slots are a 500% budget the field cannot help but spend the same way, the captain slot is a 100% budget over the same names, points-per-dollar is provably useless for ranking it, and the number GameScript prints next to a captain is a model's opinion with five stated coefficients behind it. That is less than the article set out to say in September. It has the advantage of being true.