TL;DR — Shopify cleaned up cart discount fields with a polite two-release migration window, then yanked
pre_tax_priceout of the REST Order API with no window at all. Sonnet 4.6 landed the same week with a 1M-token beta and enough coding improvements to be the model you actually run the migrations with.
The theme
Two of this week's three items are migrations, and the contrast between them is the whole story. The Storefront cart discount reshape is the well-behaved kind: new fields coexist with the old, deprecation warnings ride along in response extensions, and there are roughly two stable releases of runway before anything breaks. You can schedule it. The REST pre_tax_price removal is the other kind: no version gate, no soft landing, the field just returns null in production regardless of which API version you pinned to. The job that was correct on Monday is silently wrong on Friday.
Both patterns are legitimate — Shopify uses the polite version for additive reshapes and the blunt version for fields it considers actively misleading — and the job of anyone maintaining a Shopify integration is knowing which kind of notice you are looking at before you close the tab. Sonnet 4.6 is on the list this week because it is the first Sonnet release where a multi-file REST-to-GraphQL port actually lands in one pass without needing Opus to babysit it, which makes this a good week to pair the two.
1. Storefront Cart Discount Fields Reshape in API 2026-07 (original)
Overview
Storefront API 2026-07 reshapes discount allocation fields on Cart, CartLine, and CartDeliveryGroup into a single appliedDiscounts connection with stable targetType and targetId fields. The motivation is obvious to anyone who has ever written a custom Hydrogen cart: the old shape had discountAllocations on the cart, a separate discountAllocations on each line, a loose discountCodes list, and a cost block that frequently disagreed with the sum of those allocations because order-level discounts applied after line-level ones. The reconciliation code was always more brittle than the feature it supported.
The new cost.discountedSubtotal finally gives you a single source of truth that matches what the customer sees, and appliedDiscounts surfaces every discount — cart-level, line-level, delivery-group, code-driven, automatic, function-generated — through one consistent shape. The old fields stay live through API 2026-04 and get removed in 2027-01, which gives roughly two stable releases of runway.
Technical
The migration in a Hydrogen app is a cart fragment rewrite plus an API version bump. In app/lib/fragments.ts, replace discountAllocations { discountedAmount { amount } } with appliedDiscounts(first: 10) { nodes { id title discountedAmount { amount } targetType source code } } on both the cart and each line, and add discountedSubtotal { amount } to every cost block. Then flip storefrontApiVersion to '2026-07' in createStorefrontClient.ts. Any reconciler that was summing line allocations into a cart subtotal can be deleted — cost.discountedSubtotal replaces it.
Two edge cases the new shape actually fixes. Function-generated discounts now carry source: FUNCTION and a stable id that maps back to the discount class, so your UI can group them without string-matching titles. Delivery group discounts (free shipping promos) used to be invisible from cart-level allocations and required walking the delivery groups separately; they now show up under cart.appliedDiscounts with targetType: DELIVERY_GROUP, so a single render covers all three tiers. During the transition, deprecated fields still return data but every response carries a Deprecation warning extension — watch your dev console.
Takeaway
Bump a Hydrogen branch to storefrontApiVersion: '2026-07' this week, migrate the cart fragment, and delete any allocation-summing code. If you have analytics events firing on discount application, rewire them to the new source and targetType fields — the reporting gets cleaner for free. Hydrogen apps on auto-version bumps will break on the 2027-01 cutover if you skip this, so either schedule the work now or pin the API version explicitly until you can.
2. REST Order API Drops pre_tax_price — Migrate to GraphQL Now (original)
Overview
Shopify removed pre_tax_price and pre_tax_price_set from REST Order Admin API line items with no version gate. If your sync job still reads line_items[].pre_tax_price off GET /admin/api/2025-10/orders/{id}.json, it now returns null in production regardless of the API version you pinned to. This is the blunt removal: no deprecation warning in the response, no two-release runway, no way to dodge it by holding back the version header. The replacement lives only on the GraphQL Admin API, under discountedUnitPriceSet and discountedTotalSet with explicit shop and presentment money.
This fits the longer pattern anyone on a Shopify integration has been watching for years: REST is feature-frozen, features get pulled when they were always slightly wrong, and GraphQL becomes the only place new work lands. If you still run a REST-only sync because of a legacy dependency, this is the reminder that the runway is shorter than your roadmap.
Technical
The field mapping most people actually need: REST price becomes originalUnitPriceSet.shopMoney, REST pre_tax_price (per unit) becomes discountedUnitPriceSet.shopMoney, and the per-line totals become originalTotalSet and discountedTotalSet. A before/after in TypeScript with the Admin API client is a two-line rewrite: parseFloat(li.pre_tax_price) * li.quantity becomes parseFloat(li.discountedTotalSet.shopMoney.amount). That alone gets most reporting jobs green again.
The correctness upgrade underneath the migration is worth naming. REST pre_tax_price ignored order-level discount allocations entirely — if a 10% sitewide discount got prorated across lines, REST's per-unit field still reflected only line-level discounts and quietly understated the actual customer savings. If you need the true post-discount unit price, the GraphQL query needs to walk discountAllocations on each line, sum allocatedAmountSet.shopMoney.amount across allocations, divide by quantity, and subtract from originalUnitPriceSet. The migration is a good excuse to fix a bug your financial export was shipping without knowing it.
Takeaway
Grep your codebase for pre_tax_price. Every hit is a broken call site as of this week. Replace each one with a GraphQL query that pulls discountedUnitPriceSet plus discountAllocations if you care about order-level proration, bump Admin API to 2026-04 while you are in the file, and audit your financial exports against a known-correct order to confirm the numbers moved in the direction you expected. If a third-party library is holding you on REST, this is the forcing function to either replace it or wrap it.
3. Claude Sonnet 4.6: 1M Context Beta and the New Daily Driver (original)
Overview
Anthropic shipped Claude Sonnet 4.6 on February 17 with upgrades across coding, computer use, agent planning, and a 1M token context window in beta. Sonnet is the model you run day to day because Opus is too expensive and Haiku is too small, and 4.6 sharpens that role rather than changing it. After a week of using it as the default in my daily tooling, the mental model selector has collapsed — Sonnet 4.6 is now the answer to almost everything except the deliberate "this needs Opus" calls.
The single headline item is the 1M context window. It sits behind a beta header, it is rate-limited, and per-token pricing above 200K is higher than the standard rate, but it works. Dumping a ~600K-token TypeScript and Vue codebase into a single call and asking for every use of a specific IPC channel returned all of them, including two I had forgotten existed. Needle-in-haystack reliability at the 800K mark is the thing I expected to be the weakness and it is not.
Technical
Four upgrade vectors worth naming. Coding: a multi-file refactor I previously needed Opus 4.5 for — collapsing two parallel TypeScript stores into a single Pinia composable across roughly fifteen files — finished in one Sonnet 4.6 pass without losing rename context, at about a quarter of the Opus cost. Computer use: roughly 30% fewer wrong-button clicks in the same test harness, and faster recovery when layouts shift underneath the model. Long context: covered above. Agent planning: plans come out tighter, with fewer "and then we will figure it out" steps, which directly reduces wasted budget on dead-end branches in autonomous worker loops.
Wiring is minimal. The 1M window requires the anthropic-beta: context-1m-2026-02 header; without it you get the standard 200K window. The API model ID is claude-sonnet-4-6-20260217. Prompt caching, tool use, batch, and vision all work unchanged. The honest tradeoff: latency climbs steeply past ~700K tokens — an 8-second 200K call becomes 35–40 seconds at 800K — so if you are fronting the long context with a chat UI you need a real streaming progress story rather than a spinner.
Takeaway
Switch your default to Sonnet 4.6 this week. If you have any agent workloads that have been hitting context limits — autonomous workers eating their own logs, long codebase analyses, sprawling research threads — request the beta header and try the long-context upgrade path before you reach for Opus. The two Shopify migrations above are a natural first test: point Sonnet 4.6 at a Hydrogen cart fragment and a REST-to-GraphQL port and let it land both in a single session. Save Opus for the genuinely hard taste calls. Sonnet 4.6 absorbs the rest.
Original sources
- Storefront Cart Discount Fields Reshape in API 2026-07 — originally published 2026-02-09
- REST Order API Drops pre_tax_price — Migrate to GraphQL Now — originally published 2026-02-12
- Claude Sonnet 4.6: 1M Context Beta and the New Daily Driver — originally published 2026-02-17
