Pi: amazon-bedrock sessions are dropped from cost history, and 1-hour cache writes are priced as 5-minute writes

[oryband]

Problem

With the Pi provider enabled, codexbar cost --provider pi shows no history for Pi sessions that run on Amazon Bedrock. Pi writes "provider": "amazon-bedrock" on each assistant message. PiSessionCostScanner.mappedProvider(fromPiProvider:) accepts only openai-codex and anthropic, so the scanner drops every Bedrock row as an unsupported backend. docs/pi.md documents this limit. Bedrock is a common way to run Pi inside a company AWS account.

I saw this on 0.66.0. The mapping is the same on 0.69.0 and on main at 25bba9b7.

Example assistant row from a Pi session file (content removed):

{"type":"message","message":{"role":"assistant","provider":"amazon-bedrock","api":"bedrock-converse-stream","model":"global.anthropic.claude-opus-5-5","usage":{"input":4,"output":360,"cacheRead":55528,"cacheWrite":161,"cacheWrite1h":161,"totalTokens":56053,"cost":{"input":0.000016,"output":0.0072,"cacheRead":0.0111056,"cacheWrite":0.001288,"total":0.0196096}}}}

Model IDs that Pi records on Bedrock: global.anthropic.claude-*, us.anthropic.claude-*, global.openai.gpt-5.6-*, global.openai.gpt-6-*, global.xai.grok-4.6.

Second problem: 1-hour cache writes

extractUsage passes cacheWrite to claudeCostUSD without a 1-hour count, so the scanner prices every cache write at 1.25x input. With PI_CACHE_RETENTION=long, Pi records 1-hour writes in usage.cacheWrite1h. Anthropic and Bedrock charge those at 2x input. The code comment says that Pi JSONL does not record cache retention, but current Pi records it for both anthropic-messages and bedrock-converse-stream.

This already affects supported anthropic sessions. On one month of my Opus 5.5 usage with long retention, the scanner formula came out about 20% below the recorded cost.

Pricing check

I compared the rates for the models above in three places:

• The AWS public price list offer files for us-east-1 and us-east-2.
• The models.dev amazon-bedrock catalog.
• The usage.cost values that Pi records.

The input, output, cache-read and cache-write rates agree, including the 10% premium for regional profiles (us., eu. and others) over global.. The usage.cost.total value that Pi records matched AWS list rates on each of about 7,000 Claude rows that I checked.

Suggested fix

One of these:

1. Map amazon-bedrock rows by model family (anthropic.claude-* to Claude, openai.gpt-* to Codex). Price them from the models.dev amazon-bedrock catalog with the full model ID, so that a regional prefix keeps its own rate. Read cacheWrite1h for Claude rows.
2. Use the usage.cost.total value that Pi records when it is present, as feat(core): expand pi session attribution and reported cost handling #2575 proposed.

I can test a build against real Bedrock sessions.

[clawsweeper]

Codex review: this still needs some work. Reviewed September 29, 2026, 10:20 AM ET / 14:20 UTC.

Summary
Current main still omits Pi sessions using Amazon Bedrock and underprices one-hour cache writes in supported Anthropic sessions. The related proposal at #2575 closed without merging. Bedrock coverage remains useful, but its pricing and attribution contract needs a maintainer decision.

Reproducibility: yes. at source level: the supplied Bedrock row follows the scanner's unsupported-backend path, and the Anthropic pricing call omits its available one-hour parameter. No scanner test was run in this read-only review.

Maintainer decision needed

Question	Recommendation
Should Pi Bedrock sessions use CodexBar's independent API-rate estimates or Pi's recorded per-message costs, and should they remain solely in Pi history?	Extend estimated Pi history: Keep Bedrock rows in Pi history and price full Bedrock model IDs from a verified catalog while separately correcting one-hour cache writes.

Why: Current documentation promises estimates and deliberately limits backend attribution; either proposed expansion changes that contract and could misstate regional prices or provider totals.

Next step
The supported Anthropic pricing defect is narrowly source-proven, but a combined repair should wait for the Bedrock pricing and attribution decision; #2575 is closed unmerged.

Review details

Best possible solution:

Keep Bedrock sessions identifiable within Pi history, use their full provider-specific model IDs for pricing, apply the recorded one-hour cache count where valid, and reprice compatible caches with focused fresh-scan and upgrade tests.

Do we have a high-confidence way to reproduce the issue?

Yes, at source level: the supplied Bedrock row follows the scanner's unsupported-backend path, and the Anthropic pricing call omits its available one-hour parameter. No scanner test was run in this read-only review.

Is this the best way to solve the issue?

Unclear until the pricing and attribution contract is chosen. A narrow implementation should preserve the Pi source boundary, price the full Bedrock model ID, and use the existing one-hour Claude tariff.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• Bedrock support needs an explicit choice between Pi-recorded costs and CodexBar's estimated-pricing contract, including regional model rates and where those sessions appear in provider totals.

Codex review notes: model internal, reasoning medium; reviewed against 25bba9b7fd9c.

Label changes

Label changes:

No label changes.

Label justifications:

• P2: Missing Bedrock history and understated cache costs affect a bounded Pi cost-reporting workflow.
• impact:other: The concrete impact is incomplete and inaccurate local spend history, outside the more specific owned impact labels.

Evidence reviewed

What I checked:

• Current backend limit: The Pi provider mapping accepts only openai-codex and anthropic; the supplied amazon-bedrock row reaches the unsupported-backend path. (Sources/CodexBarCore/PiSessionCostScanner.swift:1328, 25bba9b7fd9c)
• Current pricing path: The scanner reads cacheWrite but not cacheWrite1h, and passes the aggregate write count to Claude pricing without a one-hour count. (Sources/CodexBarCore/PiSessionCostScanner.swift:1216, 25bba9b7fd9c)
• Available one-hour tariff: Claude pricing already accepts a one-hour cache-write count and applies the separate two-times-input rate. (Sources/CodexBarCore/Vendored/CostUsage/CostUsagePricing.swift:733, 25bba9b7fd9c)
• Documented product boundary: The Pi documentation explicitly limits current scanning to two backends and describes costs as API-rate estimates rather than billing totals. (docs/pi.md:10, 25bba9b7fd9c)
• Existing coverage: Tests cover the two supported backends and preserve incomplete-history signaling for unsupported backends; no Bedrock or one-hour Pi case was found in the inspected Pi tests. (Tests/CodexBarTests/PiSessionCostReliabilityTests.swift:133, 25bba9b7fd9c)
• Cache repricing boundary: Pi pricing uses a formula version in its cache key, so a changed pricing formula needs cache invalidation to reprice saved history. (Sources/CodexBarCore/PiSessionCostScanner.swift:412, 25bba9b7fd9c)

Likely related people:

• Yuxin Qiao: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• Peter Steinberger: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• Kevin Mahoney: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.