Wrap one provider client now. Upgrade the consequential lane into NORNR next.

Spend-aware wrappers are the low-friction wedge for teams with existing OpenAI- or Anthropic-style code. They are not the end state. They should lead straight into review ownership, proof packets and finance-safe exports once the lane matters.

Open wrapper guide Open MCP control server

The wrapper is useful because it lowers the first step. NORNR wins when that first step still leads into decision, review and defended export later.

Best fit A team already has provider code in production, wants a spend-aware ingress immediately, and is not ready to re-architect the runtime this week.

The wrapper buys time and control. It should not become a permanent excuse to avoid the full packet model once the lane turns consequential.

Low friction Drop NORNR into an existing client in one line instead of redesigning the whole stack.

Searchable Developers already search for budget caps and wrapper patterns before they search for control planes.

Upgrade path The first consequential lane should then move into runtime, MCP or browser governance with the same owner and packet logic.

What the wrapper is for

A wrapper is an ingress, not a substitute for the control plane.

Use it when you need an immediate budget-aware boundary on code that already exists.

Existing code

Keep the provider client and add one spend-aware preflight

Use create_spend_aware_openai_client(...) or the generic client wrapper when the existing code path is already working and you need one tighter control point fast.

What it adds

Budget-aware ingress with NORNR as the decision boundary

The wrapper uses NORNR before the provider request clears, so the first step is already policy-aware instead of only relying on provider caps after the fact.

What it does not replace

Review, proof packet, finance close and counterparty posture still matter

Once the lane matters to ops or finance, the wrapper should lead upward into one governed runtime lane, one MCP lane or one browser lane that exports the full defended record.

Upgrade path

The thin wrapper should always point to the thicker NORNR surface next.

That is how this stays a wedge instead of turning NORNR into a generic budget-cap utility.

Wrap one existing provider client

Use the spend-aware wrapper to get a policy boundary into working code immediately.

Choose one consequential lane

Find the provider call that matters to a real owner, budget or counterparty posture.

Replay a named pack

Use research-safe or another default pack before widening the lane.

Upgrade the lane

Move the consequential path into governed runtime, MCP control server or browser checkout governance when review and defended export need to survive.

Carry the same packet model forward

The lane should end in the same proof packet, review bundle and finance packet as the rest of NORNR.