fix: parse string-encoded organization costs

[patrickswedish]

Summary

• accept numeric strings returned by the organization costs API when reading amount.value
• keep the SDK's global JSON coercion rules and raw-field representation unchanged
• continue rejecting malformed and non-finite string values

Why

The costs endpoint can return monetary values as strings, including scientific notation such as "0E-6176" and high-precision decimals. Because the SDK intentionally disables global string-to-float coercion, those values remain raw JsonString instances and Amount.value() throws OpenAIInvalidDataException.

This change handles the wire-format variation only at the affected accessor. Normal JSON numbers, missing/null fields, and invalid values retain their existing behavior.

Tests

• added focused regression coverage for scientific-notation and long-decimal strings
• added negative coverage for malformed numeric strings
• ./gradlew :openai-java-core:lint
• git diff --check

Fixes #769

[chatgpt-codex-connector]

💡 Codex Review

Here are some automated review suggestions for this pull request.

Reviewed commit: 21b1c917a9

ℹ️ About Codex in GitHub

Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you

• Open a pull request for review
• Mark a draft as ready
• Comment "@codex review".

If Codex has suggestions, it will comment; otherwise it will react with 👍.

Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".

[jbeckwith-oai]

Reviewed exact head 07dfe0fc5b88597f160243dfbe560ddd40c0647a comprehensively. The fallback is correctly scoped to the affected organization-cost accessor, so it leaves global Jackson coercion, the public Optional<Double> API, builders, raw JsonField representation, and serialization unchanged. The regex implements JSON's decimal/scientific number grammar; conversion preserves the SDK's existing Double precision contract, accepts the reported underflow/high-precision payloads, and rejects malformed or non-finite/overflowing string values. Existing numeric values and missing/null fields retain their prior paths and behavior.

Validation: focused UsageCostsResponseTest passed under JDK 21; :openai-java-core:lint passed; diff check passed; and the branch merges cleanly with current main. The earlier automated finding about JVM-only numeric spellings is addressed by the exact-head grammar guard and negative test matrix. No blocking findings. (GitHub has not published remote checks for this external-contributor head.)

[patrickswedish]

Friendly ping — happy to rebase on latest main or add any additional test coverage if that would help get this over the line. The fix is isolated to the string-encoded monetary value path and leaves all other SDK behavior unchanged.

[jlangch]

Hi everyone,

It appears that OpenAI has fixed the issue on the server side and is now returning JSON floating-point values instead of strings for cost amounts, as specified by the API contract.

Could anyone from OpenAI please confirm that this issue has indeed been resolved by the OpenAI server team?

See issue #769