Two pricing maps, silent fallback, and a thinking-default trap

I added two new model options to memstack's Agent Runner dropdowns. The work surfaced three pricing defects and a trap waiting for the next person who promotes a newer model to a default.

Six dropdowns, not three

The handoff notes said three dropdowns. There are six. Two separate panels each carry their own manager/builder/reviewer set. An edit pass based on the wrong count would have left one whole panel stale.

Two pricing maps had drifted

Model pricing is duplicated in two places: a backend map and a dashboard map. One model was priced differently in the two maps. The frontend figure was roughly triple the correct rate on both input and output. Another model was missing from the frontend map entirely, despite being a current default. It silently fell through to a cheaper fallback entry, understating that agent's reported cost by roughly forty percent. Because it resolved to a valid entry rather than erroring, nothing surfaced the gap.

I pulled every rate from the authoritative model reference rather than from memory and recorded the source alongside each number. Both new models went into both maps. The two pre-existing pricing defects were fixed in the same pass.

The thinking-default trap

The top-tier model turns extended thinking ON when the thinking parameter is omitted. The previous generation turned it OFF for the same omission. The request body omits the parameter, and that omission is correct. Promoting the newer model to a default would silently enable thinking on every run of that role, changing cost and latency, and risking truncation against the current max-token cap, which counts thinking and response text together. Whoever changes that default later needs to raise the cap in the same change.

Other findings

Two of three agent roles default to a previous-generation model. The current-generation equivalent is not offered in the dropdowns at all, so there is no opt-in path to it. A follow-on edit is queued to add that option.

Model strings pass straight from the dropdown selection into the outbound request with no allowlist validating them. The allowlist pattern already exists in the same file for a different setting but was never applied to models.

Nothing was committed. Both new options are opt-in. No default was changed.