Real case

A TrexID workflow that has already run end to end.

This case comes from a staging workflow that has already run end to end, where release summaries, on-call handoff, rollback rules, and enterprise follow-up all shared the same long context. It shows reconciled token savings and TrexID latency measured on the live path.

Data window: 2026-03-12 / 2026-03-13Source: ClawDiary staging runCustomer name withheld, case anonymized
6,1841,973Input token change in a reconciled real event
4,211Input tokens saved on that single event
$0.001107Upstream input cost avoided on that event
0.79sMeasured return time for a later TrexID reference

Original scenario

A release-coordination workflow needed to feed the same long release packet to the on-call engineer, the rollback owner, and the enterprise follow-up step. The packet mixed narrative text with exact fields that had to survive unchanged, including `DEPLOY-2026-03-A`, the `22:00 UTC` rollback window, and a `USD 15,000` budget guardrail.

Integration approach

  • Replace the OpenAI-compatible client `baseURL` with `https://api.trexapi.com/v1`.
  • Switch `apiKey` to a Trex proxy key and bind the upstream provider key in the dashboard.
  • Settle the first long release packet into a TrexID, then let on-call, rollback, and enterprise follow-up flows reference the same TrexID.

Before and after

DimensionBeforeAfter
How context movedEach follow-up resent the full release packet inside the prompt.The first pass settled the packet into a TrexID and later hops passed it by reference.
Exact-content protectionIDs, rollback windows, budget guardrails, and execution intent lived inside the same long narrative.Trex explicitly marked `execute_intent`, `contains_structured_id`, and `contains_financial_value`, so those spans stayed on the exact-preserve path.
Actual upstream inputIn the direct reconciled event, the upstream provider billed against 6,184 input tokens.The same class of workflow reconciled down to 1,973 input tokens on the Trex path.

How much it saved

  • In a real reconciled event on 2026-03-12, the workflow moved from 6,184 raw input tokens to 1,973 actual upstream input tokens.
  • That single event saved 4,211 input tokens and avoided $0.001107 of upstream input-side cost.
  • That is only a single reconciled event. Once later steps keep referencing the same TrexID, savings continue to accumulate instead of every system paying to resend the full long-context body.

Latency change

  • On the first long-text pass, POST /v1/payloads/route-text returned in 1.08s on staging and immediately handed back a PROCESSING TrexID.
  • After the same TrexID hit the fast path, GET /v1/payloads/resolve/:trex_id measured 0.63s and returned from KV.
  • A later request carrying only [TZP: ...] measured 0.79s end to end. The important shift is not shaving every first packet to the floor, but removing long-text reprocessing from later hops.

Will this workflow continue using TrexAPI?

Yes. This run showed that TrexAPI can settle real long context behind a TrexID while keeping execution intent, structured identifiers, and financial values on the exact-preserve path. For release summaries, on-call handoff, rollback playbooks, and enterprise follow-up that repeatedly reuse the same context, this pattern can continue to scale in a stable way.

What this case proves

This page shows a workflow that has already run successfully: long context settled into a TrexID, savings were reconciled, and later reference latency was measured on the live path.

A validated operating path

The savings numbers come from a reconciled real event, and the latency numbers come from a live staging measurement.

Protects high-risk fields

This run triggered exact-preserve reasons including `execute_intent`, `contains_structured_id`, and `contains_financial_value`.

Ready to scale

This path can be extended to more workflows that reuse the same shared context.

Want to run the same kind of real path for your own workflow?

The shortest path is still the same three-step rollout: replace the compatible URL, switch to a Trex key, and bind your own provider key in the dashboard.