fix: enforce max_tokens as a billing bound and refuse n other than 1

[sakibsadmanshajib]

Closes #1283.

What was broken

Both defects were confirmed against production with the real OpenAI SDK v7.8.0 (workflow run 33209920195, 2026-08-28), so this is shipped behaviour, not a theoretical gap.

1. max_tokens was not enforced. max_tokens: 8 on hive-free returned 1650 completion tokens, and all 1650 were billed. The caller asked for 8 to bound their own spend and was charged roughly 200 times that.
2. n: 2 returned a single choice with HTTP 200 and no indication the parameter had been dropped.

The billing invariant, stated precisely

A request that specifies max_tokens: N must never be billed for more than N completion tokens.

Scope of the guarantee, so nobody has to re-derive it from the diff:

• It applies to every token-priced settlement branch on /v1/chat/completions, /v1/completions and /v1/responses: the measured charge, the content-estimate fallback, the sync zero-content hold capture, and the streaming missing-usage hold capture.
• The ceiling is read from the caller's ORIGINAL body, before any outbound rewrite. EnforceVariablePriceBounds forces a ceiling Hive chose rather than one the caller asked for, so reading it afterwards would bound the charge by our own number and guarantee the caller nothing.
• With both chat spellings present the SMALLER is used. The request is self-contradictory and no reading is provably what the caller meant, so the tie goes to the number that keeps the invariant literally true for whichever field they wrote. That under-charges Hive on a malformed request, the direction every estimate on this path already errs in.
• Prompt tokens are never clamped. Only the completion side is bounded.
• The bound only ever lowers a charge and never to zero: CreditsForTokens floors any non-zero quantity at one credit, so the fail-closed rules in D-034 and D-048 (no served request bills zero) are untouched.
• Carve-out, stated rather than left to be discovered: a variable-price alias (Pricing.IsUpstreamActual) settles on the cost the upstream reported for the generation, not a token count times a catalog rate, so there is no per-token figure to cap. Its spend stays bounded by EnforceVariablePriceBounds forcing the outbound ceiling to VariablePriceMaxCompletionTokens, and by the hold clamp in control-plane's finalizeLocked. No route with a nonzero reasoning reserve is variable-priced today.

Arithmetic is unchanged and still runs through metering.ChargeCredits, so every figure stays math/big. No float64 was introduced.

Root cause of defect 1

applyReasoningHeadroom, shipped by PR #1225 for issue #1171 and live since 2026-08-26, inflated every completion-limit field the caller had set by provider_routes.reasoning_reserve_tokens before dispatch. That column is 4096 on three of the four hive-free pool members, so max_tokens: 8 went upstream as 4104.

Its premise was that hidden reasoning would burn the reserve while visible content survived inside the caller's own budget. The premise is not enforceable: nothing in an OpenAI-compatible request tells an upstream that part of a ceiling is earmarked for hidden reasoning, so the model spends the inflated ceiling on whichever it emits first. On the reported request (Write a long story about the sea.) that was visible story text.

The sharper finding is that the rewrite deliberately skipped a ceiling the caller had NOT set. Its entire effect was therefore overriding ceilings callers HAD set. It had no legitimate operating mode, so it is deleted rather than tuned.

This was not a symptom patched at one call site. applyReasoningHeadroom had exactly three callers (orchestrator.go sync, stream.go, stream_responses.go); all three are gone, and the settlement bound is applied at each path's single metering seam rather than per branch.

Root cause of defect 2

N *int was declared on both ChatCompletionRequest and CompletionRequest and read by nothing. The raw body was forwarded to LiteLLM, the parameter was ignored upstream, and one choice came back with HTTP 200.

Where enforcement lives, and why

Both boundaries. Either alone is a hope rather than a proof.

Request boundary. The caller's ceiling now reaches the provider unchanged. This is the only boundary that can stop a caller receiving 1650 tokens they capped at 8, and it is what makes the reported usage honest rather than merely cheap. It also restores OpenAI semantics, where a reasoning model's hidden reasoning counts against the ceiling.

Settlement boundary. The metered completion count is capped at the caller's own ceiling before anything reads it. It clamps the ONE usage object both the customer response and the charge derive from, and rewrites the already-marshalled body to match, so the number the caller reads and the number they pay for cannot diverge. Request-boundary correctness cannot carry the money guarantee on its own: it would depend on every upstream honouring a parameter we merely forwarded, on no future rewrite of the outbound body, and on no provider counting hidden reasoning into completion_tokens. PR #1225 is the proof that the outbound body only has to be wrong once.

A settlement-only fix was also rejected. The caller would still receive and be shown a completion count they explicitly capped, and every OpenAI-compatible cost dashboard reads usage.completion_tokens unconditionally.

What issue #1171 keeps, and what it loses

Its zero-content guard, the fail-closed half, is untouched: an empty-content finish_reason=length completion on a reserving pool is still retried once and still captures rather than settling full price. provider_routes.reasoning_reserve_tokens keeps a reader as the flag that gates it, so no column is orphaned.

What issue #1171 loses is the product half: a reasoning member given a very small ceiling can again answer with empty content. That outcome is now strictly cheaper than before this PR, because the capture that follows it is bounded by the caller's ceiling instead of charging the flat DefaultHoldText hold. Routing a small-ceiling request to a non-reasoning member, or sending reasoning_effort: low, are the honest ways to recover the product half and are follow-up work, not a silent rewrite of the caller's request.

Defect 2 decision: reject, not support

n other than 1 now returns 400 unsupported_parameter with param: "n" on both /v1/chat/completions and /v1/completions. Absent and n: 1 pass through untouched; n: 0 and negatives are refused too, which OpenAI also rejects.

Rejecting rather than honouring, because no route in this catalog can serve n > 1: the free pool's Groq members accept only n=1 on their OpenAI-compatible surface, and OpenRouter does not implement the parameter across the pool. Honouring it would additionally multiply generated tokens against a single per-request max_tokens ceiling, which is the invariant above. Silently returning one choice was the only unacceptable option, and a declared 400 is the OpenAI-contract-correct answer for a parameter the upstream genuinely cannot serve.

The refusal message names the parameter and nothing about who serves the request, so it stays provider-blind. support-matrix.json notes for both endpoints now record the refusal and the settlement bound.

Tests, written first and mutation-checked

Every behavioural test below was written before the fix and observed failing against the unfixed code. Each fix was then reverted individually to prove the test catches its absence rather than merely its deletion, and restored.

Mutation	What was reverted	Result
A	reinstate the headroom inflation on the sync path	RED: TestExecuteSync_CallerCeilingReachesProviderUnchanged reported dispatched max_tokens = 4104, want the caller's own 8
B	remove the clampUsageToCeiling call sites in executeSync and executeStreaming, leaving the helper intact so this tests the wiring rather than the function	RED: both TestExecuteSync_BilledCompletionTokensCappedAtCallerCeiling and TestExecuteStreaming_BilledCompletionTokensCappedAtCallerCeiling
C	sync zero-content capture back to reservation.Held()	RED: TestExecuteSync_ZeroContentCaptureBoundedByCallerCeiling reported charged 10000 credits against a ceiling worth 108
D	unsupportedChoiceCount returns false	RED: all three TestNGreaterThanOneRejected subtests
E	streaming missing-usage capture back to reservation.Held()	RED: TestExecuteStreaming_HoldCaptureBoundedByCallerCeiling reported charged 10000 credits against a ceiling worth 32

Every mutation was reverted and the suite returns green.

Negative controls are in the suite too, so the clamp cannot quietly become a discount on every request: TestExecuteSync_NoCeilingLeavesUsageAlone pins that a caller who set no ceiling is metered exactly what the provider reported, TestNOneOrAbsentPassesThrough pins that only the unservable shape is refused, and TestSyncOverrunDispatchesOnce pins that an over-ceiling response does not become a second provider call.

The money tests price against the real hive-free catalog row (1,000,000 credits per million input, 4,000,000 per million output, D-048 and migration 20260824_02_free_pool_router.sql) rather than a fixture, so the magnitude they assert is the magnitude the issue measured.

TestExecuteSync_ZeroContentLength_Twice_CapturesHold was amended rather than deleted: its request now sets no ceiling, which is the condition under which a capture is still at the full hold. Both halves of that behaviour are now pinned, one per test. The three tests that pinned the headroom inflation are removed along with the behaviour they described.

Verification

Run in the repo's Docker toolchain, on a throwaway toolchain container with a worktree-unique COMPOSE_PROJECT_NAME. No shared database was touched; these are -short unit tests.

go vet ./apps/edge-api/... ./apps/control-plane/...
go test ./apps/edge-api/... ./apps/control-plane/... -count=1 -short

Zero failures across both modules. gofmt is clean on every file this PR touches. Two pre-existing gofmt misalignments in chat_completions.go and completions.go were left alone as unrelated noise.

Review round two, first stream: five defects found in this branch, all fixed

An independent adversarial money-path review of a2f4539 reproduced five defects in this branch itself. Every one is answered in 8078f56, and every reproduction is kept as a regression guard in completion_ceiling_review_test.go.

Finding 1, HIGH, caller-triggerable revenue bypass. The ceiling was read as the smaller of max_tokens and max_completion_tokens, but once the headroom rewrite was deleted the outbound body forwarded both fields verbatim, so the request boundary and the settlement boundary enforced different numbers. OpenAI treats max_completion_tokens as authoritative and max_tokens as deprecated, and Groq documents the same preference, so a caller pairing max_tokens: 1 with max_completion_tokens: 100000 received a full-size generation and paid for one completion token, on the four-to-one expensive output side and unbounded in generation size. pinCompletionCeiling now writes the settled minimum back over every ceiling field present, on all three dispatch paths, before EnforceVariablePriceBounds so a variable-price alias still gets its own cap applied on top. It only ever narrows: an absent field stays absent, and an unreadable or non-positive one is left as written, because raising it would widen what the provider may generate.

Finding 2, HIGH, overcharge past the ceiling. clampUsageToCeiling is a no-op when the upstream sent no usage block, which is exactly the branch that then prices the request from content length, so a synchronous 200 carrying content and no usage charged far past the ceiling. Streaming survived only by accident, because its unconfirmed branch discards that estimate for a hold capture that is already bounded. The bound went into settlementCredits, the single function both settlement paths route through, which also closes the same hole on the session chat surface through ChatSettlementCredits.

Finding 3, MEDIUM, variable-price aliases. On an upstream_actual alias the charge is derived from the cost the upstream reported for the generation, which the clamp never touches, so clamping the usage block only advertised a completion count nobody was billed on: the exact divergence that function exists to prevent. The clamp is now gated on the pricing mode, the same test capCaptureAtCeiling already applies. hive-auto is live in that mode.

Finding 4, MEDIUM, published contract. The never-billed-past-N sentence is now qualified for the variable-price case on both endpoints that serve hive-auto, rather than deleted.

Finding 5, MEDIUM, best_of. The identical unfixed defect n had, on the same endpoint: nothing read or refused it, the outbound body is re-marshalled from a map so it reached the provider intact, and the generated OpenAPI contract advertised it. Refused on the same terms as n, with the same guard shape and the same provider-blindness assertions.

Finding 6, LOW, documentation only. That max_tokens: 0, negatives, 8.0 and "8" all read as no ceiling is now stated where the invariant is stated, with the reasoning. No behaviour change.

Finding 7 requested no change and was rebutted on the thread.

All five code findings were red before the fix and green after, and the whole of ./apps/edge-api/... and ./apps/control-plane/... passes with go vet clean and gofmt clean on every touched file.

Review round two, second stream: three more defects, all fixed

A second independent adversarial stream ran against 8078f56, the commit that answered the first stream. Codex is exhausted until 2026-09-10 and was replaced by Antigravity rather than skipped, on owner instruction. It found three real defects in code this pull request introduced, all fixed in 446151c, plus one performance observation. Full stream output and the mutation table are in the pull request comment.

Finding 1, HIGH, an unparseable ceiling field survived into the outbound body. pinCompletionCeiling kept any ceiling field it could not parse as an integer, on the reasoning that overwriting it would widen what the provider may generate. That reasoning does not hold for a field this gateway cannot read: it cannot be called smaller either, and the provider may well parse it. So max_tokens: 1 paired with max_completion_tokens: 100000.5 reopened the entire first-stream bypass through a spelling the JSON number type happens not to cover. A field is now kept only when it reads as a positive integer at or below the ceiling, which is the rule clampCompletionLimit already applied to what it cannot read.

Finding 2, HIGH, the gateway invented a ceiling larger than the one the caller set. clampCompletionLimit fills in every ceiling field the endpoint speaks, and filled them at VariablePriceMaxCompletionTokens regardless of a smaller ceiling already present. On chat that wrote max_completion_tokens: 16384 in beside a max_tokens: 1, and since the newer spelling is the authoritative one, a variable-price alias generated four orders of magnitude more than was asked for and billed the upstream cost of it, with no settlement clamp behind it because that mode has none. The filled value is now the lower of that constant and any smaller ceiling the caller set, and the same limit narrows present fields too, so the function is correct independently of call order.

Finding 3, HIGH, hold captures priced the prompt at zero. Both capture branches bound the charge with capCaptureAtCeiling, whose bound is the catalog price of the whole request at the ceiling, prompt included. Both are reached precisely because no usable usage block arrived, so the metered input count is zero, and passing that through priced a large prompt at nothing: a 100,000-token prompt capped at ten output tokens collapsed the capture from the hold to roughly forty credits, a free serve of the expensive half of the request. captureInputTokens now falls back to the same content-length prompt estimate settlementCredits uses on the same no-usage path. TestExecuteStreaming_HoldCaptureBoundedByCallerCeiling was amended rather than deleted, because its upper bound had encoded exactly this zero-priced prompt.

Finding 4, LOW, three JSON decodes of the request body before dispatch. Partly taken: pinCompletionCeiling now settles the common single-ceiling chat request with a byte scan and returns before decoding. The rest was declined on the thread, since threading one shared decoded map through three functions with different contracts, one of which refuses the request outright on a decode error, is a larger and riskier diff on a money path than a call count justifies, on a request already about to make a network call to a language model.

Each of the three fixes was mutation-checked: reverting it turns its own test red, and all three were red together before the fixes landed.

Not in scope

• Issues POST /v1/files returns 500 "Failed to store file" in production, breaking Files and Batches #1282, audio.speech.create and audio.transcriptions.create return 500 in production #1285, images.generate returns fake-success 200 with empty data array instead of erroring #1286, usage.prompt_tokens_details.cached_tokens and stream_options.include_usage inconsistent across aliases #1288 and Unauthenticated GET to unknown path returns 401 in production, 404 unknown_endpoint locally #1289 in the same batch are unrelated defects with different root causes: storage writes, voice, images, usage-shape reporting and production route ordering respectively. None share a cause with this one, so none are folded in. GET /v1/models leaks provider identity in hive-stt/hive-tts descriptions #1284 is assigned elsewhere and untouched.
• The SDK conformance assertions for these two parameters land with PR test: extend OpenAI SDK conformance suite, add live-gateway workflow #1268, which adds sampling-params.test.ts. Adding the same file here would collide with it.
• The WHY prose in migration 20260826_01_route_reasoning_reserve.sql still describes the headroom mechanism. Applied migrations are never edited in this repo; the column's surviving purpose is documented at its remaining reader in zero_content_guard.go.

Buglog entry

{"id":"bug-2026-08-28-max-tokens-not-enforced","date":"2026-08-28","title":"max_tokens silently inflated by the reasoning reserve, billing 206x the caller's ceiling; n>1 silently truncated to one choice","error_message":"max_tokens: 8 on hive-free returned usage.completion_tokens 1650, all billed; n: 2 returned HTTP 200 with choices.length 1 and no error","root_cause":"applyReasoningHeadroom (PR #1225, issue #1171) inflated every completion-limit field the caller had set by provider_routes.reasoning_reserve_tokens (4096 on three of four hive-free members) before dispatch, so max_tokens 8 went upstream as 4104. Its premise that hidden reasoning would burn the reserve while visible content stayed inside the caller's budget is unenforceable: nothing upstream separates the two, so the model spent the inflated ceiling on visible output. Because the rewrite skipped a ceiling the caller had NOT set, its entire effect was overriding ceilings callers HAD set. Separately, ChatCompletionRequest.N and CompletionRequest.N were declared and read by nothing, so n was forwarded, ignored upstream, and one choice returned with no error. Two hold-capture branches (sync zero-content, streaming missing-usage) also charged the flat DefaultHoldText authorization floor regardless of the caller's ceiling, a far larger breach of the same invariant.","fix":"Deleted applyReasoningHeadroom and its three call sites so the caller's ceiling reaches the provider unchanged. Added completion_ceiling.go: requestedCompletionCeiling reads the ceiling from the caller's original body before any outbound rewrite, clampUsageToCeiling caps usage.CompletionTokens at it on the single usage object both the response and the charge derive from, rewriteNormalizedUsage keeps the response body in step, and capCaptureAtCeiling bounds both hold-capture branches without ever reaching zero. Refused n other than 1 with 400 unsupported_parameter and param n on both chat and legacy completions.","tags":["billing","money-path","overcharge","max_tokens","openai-conformance","issue-1283","issue-1171","edge-api","inference","free-pool"]}

A second entry for the three defects the review found in this branch. Both lines go to main together in the buglog-only pull request.

{"id":"bug-2026-08-28-completion-ceiling-review-defects","date":"2026-08-28","title":"Completion-ceiling fix shipped a caller-triggerable revenue bypass, an unbounded content estimate, and a usage clamp on aliases it could not bill","error_message":"Request {max_tokens: 1, max_completion_tokens: 100000} was dispatched unchanged and settled at output_tokens 1, actual_credits 24 where the unclamped generation was worth 6620; a synchronous 200 carrying content and no usage block against max_tokens 8 charged 1323 credits versus 32 ceiling-priced; on an upstream_actual alias the caller read completion_tokens 8 while paying the upstream cost of 1650","root_cause":"Three separate causes in one change. First, requestedCompletionCeiling takes the smaller of the two chat spellings but nothing rewrote the outbound body, so after applyReasoningHeadroom was deleted both fields were forwarded verbatim and the request boundary enforced a different number than settlement; OpenAI and Groq both prefer max_completion_tokens, so the larger field governed generation while the smaller governed billing. Second, clampUsageToCeiling returns early when usage is nil, which is the same condition that routes settlement into the content-length estimate in settlementCredits, leaving the one path that guesses the completion count as the one path with no ceiling on it; the streaming path was masked because settleStream overwrites the estimate with a bounded hold capture. Third, clampUsageToCeiling was called unconditionally, but an upstream_actual alias settles from respBody or acc.RawUsageChunk, which the clamp never reads, so it lowered the number the caller reads without lowering the charge.","fix":"Added pinCompletionCeiling, which writes the settled minimum back over every ceiling field present in the outbound body before dispatch and only ever narrows, wired on executeSync, executeStreaming and executeResponsesStreaming ahead of EnforceVariablePriceBounds. Added a ceiling parameter to settlementCredits that bounds the content-length completion estimate, with ChatSettlementCredits reading the ceiling from the request bytes it already parses so the session chat surface is covered too. Gated clampUsageToCeiling on route.Pricing.IsUpstreamActual, the same test capCaptureAtCeiling applies. Refused best_of other than 1 on legacy completions. Qualified the support-matrix sentence for the variable-price case and documented that non-positive and non-integer ceiling spellings read as no ceiling.","tags":["billing","money-path","revenue-bypass","overcharge","max_tokens","max_completion_tokens","best_of","upstream-actual","issue-1283","pr-1305","edge-api","inference","code-review"]}

A third entry for the three defects the second adversarial stream found. All three lines go to main together in the buglog-only pull request.

{"id":"bug-2026-08-28-completion-ceiling-second-stream-defects","date":"2026-08-28","title":"Ceiling pinning kept unreadable fields, the variable-price bound invented a larger ceiling than the caller set, and hold captures priced the prompt at zero","error_message":"Request {max_tokens: 1, max_completion_tokens: 100000.5} was dispatched with the float intact; a variable-price request sending only {max_tokens: 1} was dispatched with max_completion_tokens 16384 written in beside it; a streaming request with a prompt of roughly 11334 tokens and max_tokens 8 whose upstream sent no usage block settled at 32 credits rather than the price of the prompt","root_cause":"Three causes in the fix for the first adversarial stream. First, pinCompletionCeiling skipped any present ceiling field that failed to unmarshal into int64, on a never-widen rule that does not hold for a value the gateway cannot read at all, since the provider may parse what encoding/json refuses and OpenAI treats max_completion_tokens as authoritative. Second, clampCompletionLimit sets every field the endpoint speaks to VariablePriceMaxCompletionTokens when absent, with no reference to a smaller ceiling already present, and an upstream_actual alias has no settlement clamp behind that. Third, capCaptureAtCeiling computes its bound as the catalog price of the whole request at the ceiling, but both callers pass the metered input count, which is zero exactly because those branches are reached when no usable usage block arrived, so the prompt was priced at nothing and the capture collapsed to the output side alone.","fix":"pinCompletionCeiling now keeps a field only when it reads as a positive integer at or below the ceiling and overwrites everything else present, logging the raw literal truncated. clampCompletionLimit derives an effective limit as the lower of VariablePriceMaxCompletionTokens and any smaller positive ceiling already in the body, and uses it both to fill absent fields and to narrow present ones. Added captureInputTokens, which falls back to the content-length prompt estimate settlementCredits already uses when the upstream reported no usage, and wired it into both capCaptureAtCeiling call sites. Added a byte-scan early-out to pinCompletionCeiling so an ordinary single-ceiling chat request pays no extra decode.","tags":["billing","money-path","revenue-bypass","free-serve","max_tokens","max_completion_tokens","upstream-actual","hold-capture","issue-1283","pr-1305","edge-api","inference","code-review"]}

[chatgpt-codex-connector]

You have reached your Codex usage limits for code reviews. You can see your limits in the Codex usage dashboard.

[coderabbitai]

Warning

Review limit reached

Next included review available in 21 minutes.

View limit details

Limit details: You’ve used the included review currently available.

You've used all free OSS reviews for now. Wait for the free limit to reset to keep reviewing this public repository.

Learn how review limits work.

Review configuration:

⚙️ Run configuration

Configuration used: defaults

Review profile: CHILL

Plan: Pro Plus

Run ID: e19a2395-90d5-4dc5-acd0-dbec6c0cb989

📥 Commits

Reviewing files that changed from the base of the PR and between b442af4 and f284fc1.

📒 Files selected for processing (18)

• apps/edge-api/internal/inference/chat_completions.go
• apps/edge-api/internal/inference/completion_ceiling.go
• apps/edge-api/internal/inference/completion_ceiling_review_test.go
• apps/edge-api/internal/inference/completions.go
• apps/edge-api/internal/inference/errors.go
• apps/edge-api/internal/inference/max_tokens_enforcement_test.go
• apps/edge-api/internal/inference/n_parameter_test.go
• apps/edge-api/internal/inference/orchestrator.go
• apps/edge-api/internal/inference/pricing.go
• apps/edge-api/internal/inference/reasoning_headroom.go
• apps/edge-api/internal/inference/settlement_test.go
• apps/edge-api/internal/inference/stream.go
• apps/edge-api/internal/inference/stream_responses.go
• apps/edge-api/internal/inference/stream_settle_context_test.go
• apps/edge-api/internal/inference/types.go
• apps/edge-api/internal/inference/zero_content_guard.go
• apps/edge-api/internal/inference/zero_content_guard_test.go
• packages/openai-contract/matrix/support-matrix.json

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[sakibsadmanshajib]

Independent security and money-path review (stage 6, mandatory)

The prior reviewer on this PR was lost to a session limit before posting, so this is the first independent pass. Streams run: adversarial money-path review (this one), security-reviewer domain pass, CodeRabbit CLI. /codex:adversarial-review is SKIPPED, stated explicitly rather than counted as a pass: the Codex CLI reports You've hit your usage limit ... try again at Sep 10th, 2026, so it produced no opinion at all. Note also that the CodeRabbit GitHub App check on this PR reports pass with the annotation Review rate limited, which is likewise not a clean pass; the CodeRabbit CLI run below is the one that actually executed.

What I verified rather than took on trust

The deletion is justified. I read the removed applyReasoningHeadroom at the base commit. Its field loop is raw, present := decoded[field]; if !present { continue }, so a caller who set no ceiling was never inflated. One hundred percent of its effect was therefore raising ceilings callers had set. The author's central claim holds and deletion over repair is the right call.

Mutations re-run independently, not read off the table. Four of the five, each applied to a clean checkout of a2f45392a in an isolated worktree and run in the repo Docker toolchain:

Mutation	Observed
B, remove both clampUsageToCeiling call sites	RED. Sync: finalize output_tokens = 1650, want 8, actual_credits = 6620, want 52. Streaming: same figures plus the forwarded usage frame still carrying "completion_tokens":1650
C, sync zero-content capture back to reservation.Held()	RED. charged 10000 credits against a ceiling worth 108, the exact message the PR body quotes
D, unsupportedChoiceCount returns false	RED, all three subtests
E, streaming missing-usage capture back to reservation.Held()	RED. charged 10000 credits against a ceiling worth 32

The suite is green unmutated: go vet and go test -short clean across ./apps/edge-api/... and ./apps/control-plane/.... gofmt -l lists chat_completions.go and completions.go, but the diff is pre-existing struct-literal alignment on NeedStreaming and NeedReasoning lines this PR never touched, exactly as the PR body says.

Deleted and amended tests. The three removed tests all pinned the deleted behaviour and their removal is correct; TestExecuteSync_CallerCeilingReachesProviderUnchanged is the inverse of the strongest one. The amendment to TestExecuteSync_ZeroContentLength_Twice_CapturesHold is honest rather than a weakening: dropping max_tokens:200 from its body is required for the test to keep asserting a full-hold capture, because a ceiling of 200 now bounds that capture, and the with-ceiling half is pinned by a separate new test. Both halves are covered, one per test.

Nothing bills zero. capCaptureAtCeiling only calls CreditsForTokens with ceiling > 0, so the nonzero-quantity branch always applies and the one-credit floor at pricing.go:243 always fires. D-034 and D-048 fail-closed are intact, and the new tests assert credits < 1 is a failure.

Arithmetic. No float64 anywhere in the new production code. The only new arithmetic is int64 token addition; every credit figure still routes through metering.ChargeCredits.

No blanket under-billing. TestExecuteSync_NoCeilingLeavesUsageAlone is a real negative control and I confirmed the clamp is a no-op at ceiling <= 0. But see the two specific under-billing holes below, which that control does not cover.

Verdict

The invariant holds on the four branches the tests pin, and the two-boundary design is right. It does not hold on two further branches, both reproduced empirically, and one of them is a caller-triggerable revenue bypass. Findings are inline. My recommendation is do not merge as is: F1 and F2 are small, contained fixes in files this PR already owns, and shipping the contract sentence in support-matrix.json while those two branches exist publishes a guarantee the code does not keep.

Nothing here is a customer overcharge regression, so this is not an emergency; F1 costs Hive money, F2 overcharges only on a branch that needs a misbehaving upstream.

[sakibsadmanshajib]

Review round two, stream 2 of 2: Antigravity adversarial pass

Second independent adversarial stream on this money path, run against 8078f56 with agy --model gemini-3.1-pro-high --effort high. Codex is exhausted until 2026-09-10 and was replaced by this rather than skipped, on owner instruction.

Four findings. Three were real defects in code this pull request introduced and are fixed in 446151c, each mutation-checked. The fourth is declined with reasoning below.

1, HIGH, unparseable ceiling field left in the outbound body. pinCompletionCeiling kept any ceiling field it could not parse as an integer, on my reasoning that overwriting it would widen what the provider may generate. That reasoning does not hold for a field this gateway cannot read: it cannot be called smaller either, and the provider may well parse it. So {"max_tokens": 1, "max_completion_tokens": 100000.5} reopened the entire finding-1 bypass through a spelling the JSON number type happens not to cover. Fixed: a field is kept only when it reads as a positive integer at or below the ceiling, which is the same rule clampCompletionLimit already applied to what it cannot read. Guard: TestExecuteSync_UnreadableCeilingFieldIsPinnedToo.

2, HIGH, an invented ceiling larger than the one the caller set. clampCompletionLimit fills in every ceiling field the endpoint speaks, and filled them at VariablePriceMaxCompletionTokens regardless of a smaller ceiling already present. On chat that wrote max_completion_tokens: 16384 in beside a max_tokens: 1, and since OpenAI treats the newer spelling as authoritative, a variable-price alias generated four orders of magnitude more than was asked for and billed the upstream cost of it, with no settlement clamp behind it because that mode has none. Fixed: the filled value is the lower of that constant and any smaller ceiling the caller set, and the same limit now narrows present fields too, so the function is correct independently of whether pinCompletionCeiling ran first. Guard: TestEnforceVariablePriceBounds_DoesNotRaiseACeilingTheCallerSet.

3, HIGH, hold captures priced the prompt at zero. Both capture branches bound the charge with capCaptureAtCeiling, whose bound is the catalog price of the whole request at the ceiling, prompt included. Both branches are reached precisely because no usable usage block arrived, so the metered input count is zero, and passing that straight through priced a large prompt at nothing: a 100,000-token prompt capped at 10 output tokens collapsed the capture from the hold to roughly forty credits. That is a free serve of the expensive half of the request, which is what D-034 exists to prevent. Fixed with captureInputTokens, which falls back to the same content-length prompt estimate settlementCredits already uses on the same no-usage path. Guard: TestExecuteStreaming_HoldCaptureKeepsThePromptCost. TestExecuteStreaming_HoldCaptureBoundedByCallerCeiling was amended rather than deleted, because its upper bound had encoded exactly this zero-priced prompt.

4, LOW, three JSON decodes of the request body before dispatch. Partly taken, mostly declined. Taken: pinCompletionCeiling now settles the common case with a byte scan for two ceiling field names and returns before decoding, so the ordinary single-ceiling chat request pays no second decode at all, and it already marshals only when it changed something. Declined: threading one shared map[string]json.RawMessage through requestedCompletionCeiling, pinCompletionCeiling and EnforceVariablePriceBounds would couple three functions with different contracts, one of which refuses the request outright on a decode error, and it would put a mutable decoded body in scope across the whole pre-dispatch block on the exact path this pull request is fixing money defects in. That is a larger and riskier diff than the measurement justifies, on a request that is already about to make a network call to a language model. Worth revisiting with a profile behind it, not on the strength of a call count.

Mutation evidence for the three fixes, all reverted afterwards:

Mutation	Result
pinCompletionCeiling back to keeping unreadable fields	RED: dispatched body still carried max_completion_tokens: 100000.5
clampCompletionLimit back to a fixed 16384 fill	RED: max_completion_tokens = 16384, want 1
capCaptureAtCeiling back to the raw accumulator input count	RED: charged 32 credits against a prompt of roughly 11,334 tokens

go vet and the full ./apps/edge-api/... and ./apps/control-plane/... suites pass, and gofmt is clean on every file touched.