Existing laptop configs never get the built-in Bob pricing #1216

Problem

The built-in laptop preset prices IBM Bob, but only on a machine that has never had a ~/.cortex/config.yaml. Anyone who installed before #1201 and upgrades keeps a config with no Bob entry. Their Bob requests stay unpriced, and nothing tells them why.

#1201 added this block to the preset (cmd/cortex/local.go:251):

pricing:
  endpoints:
    - hosts: ["api.us-east.bob.ibm.com"]
      unit: Bobcoins
      models:
        "*":
          input_cost_per_million:       2.00
          output_cost_per_million:      2.00
          cache_read_cost_per_million:  2.00
          cache_write_cost_per_million: 2.00

Every install path writes the preset only when no config exists:

• install.sh (the one-liner), make dev-install (cortex --local --write-config) and cortex --local all go through writeBuiltinConfig. It never overwrites an existing file, on purpose, so the prune list and hand edits survive restarts.
• The only step that edits an existing config is migrateConfig (cmd/agentop/cmd_config_migrate.go), run from agentop service install. It adds the three listener pins (bind_loopback_only, health_addr, transparent_proxy_addr) and nothing else.

So v0.8.0 prices Bob on a fresh install and leaves it unpriced on an upgrade. Today the only fix is to copy the block in by hand.

Proposal

Extend migrateConfig to add the Bob endpoint when no pricing.endpoints entry covers api.us-east.bob.ibm.com. Follow the rules the listener pins already use:

• Only add. Never change or remove a rate, unit or endpoint the user set.
• Decide presence from the parsed document, not a text search, so a commented-out block still counts as absent.
• Keep the existing .before-agentop-migrate backup, and check that the result parses before replacing the file.
• Report the addition in agentop service install output alongside the pins.

Open questions

• Which entries should block the add? An existing entry for the Bob host, even with different rates, means the user has chosen. Should a catch-all entry that would also match that host block it too?
• Opt-out: if someone deletes the Bob entry on purpose, the next service install would add it back. The listener pins have the same property. We might accept that, or record that the migration ran (a marker comment or a version key) so it only runs once.
• Generalise? This is the second preset change that never reached existing configs; the listener pins were the first. A per-key "preset additions" list in the migration would let the next one ship without another hand-written case.

Assisted-By: Claude (Anthropic AI) noreply@anthropic.com