feat: add word_confidence_threshold param to whisper

[johnyrahul]

Summary

Adds the wordConfidenceThreshold option (default 0.3) to the whisper API, mirroring the corresponding changes in the Python client and docs:

• Python client: feat: add word_confidence_threshold parameter to whisper llm-whisperer-python-client#33
• Docs: https://github.com/Zipstack/llmwhisperer-docs/pull/57

Words whose OCR confidence falls below the configured threshold are excluded from the extracted text. The parameter works only with form, high_quality and table modes.

Changes

• index.js: new wordConfidenceThreshold option (default 0.3), forwarded as word_confidence_threshold in the /whisper request params, plus JSDoc.
• Version bump 2.5.1 → 2.6.0.

Notes

No unit test added: the JS test suite is integration-only (hits the live API with real files) and has no request-mocking setup equivalent to the Python PR's mocked URL-param assertions.

🤖 Generated with Claude Code

[greptile-apps]

Greptile Summary

This PR adds the wordConfidenceThreshold option to the whisper method, mirroring equivalent changes in the Python client. The new parameter filters out low-confidence OCR words before returning extracted text, and is forwarded to the API as word_confidence_threshold.

• index.js: Adds the wordConfidenceThreshold param (default 0.3) to the function signature and the params object, with accompanying JSDoc.
• test/retry.test.js: Adds two adapter-based unit tests verifying that both a custom threshold and the default 0.3 are forwarded correctly.
• package.json / package-lock.json: Minor version bump 2.5.1 → 2.6.0.

Confidence Score: 5/5

Safe to merge — the change is additive, follows established patterns in the codebase, and is covered by new unit tests.

The new parameter is wired identically to every other query param in the whisper method, defaults to a reasonable value (0.3), and does not alter any existing behavior when the caller omits it. Two new tests verify both the custom and default cases.

No files require special attention.

Important Files Changed

Filename	Overview
index.js	Adds wordConfidenceThreshold param (default 0.3) to whisper() and forwards it as word_confidence_threshold; follows existing patterns for parameter handling.
test/retry.test.js	Adds two axios-adapter-based tests confirming the new param is forwarded with both a custom value and its default; consistent with the rest of the test file's mocking style.
package.json	Version bump 2.5.1 to 2.6.0; correct semver minor bump for a new backward-compatible feature.
package-lock.json	Lock file updated to reflect the version bump; no dependency changes.

Sequence Diagram

sequenceDiagram
    participant Caller
    participant whisperFn as whisper method
    participant AxiosClient as Axios Client
    participant API as /whisper API

    Caller->>whisperFn: wordConfidenceThreshold: 0.7
    whisperFn->>whisperFn: build params with word_confidence_threshold
    whisperFn->>AxiosClient: "POST /whisper with word_confidence_threshold=0.7"
    AxiosClient->>API: HTTP POST with query params
    API-->>AxiosClient: 200/202 response
    AxiosClient-->>whisperFn: response object
    whisperFn-->>Caller: Promise resolves with response

Loading

_{Reviews (3): Last reviewed commit: "test: add word_confidence_threshold forw..." | Re-trigger Greptile}

[jaseemjaskp]

Automated review (Claude PR Review Toolkit). The change is small and consistent with the existing param-forwarding pattern. Two non-blocking findings below; details and a test-coverage note are in the PR thread summary.

[jaseemjaskp]

[P2 · behavior] Client now forces word_confidence_threshold on every request.

With wordConfidenceThreshold = 0.3 as a client-side default, the param is sent on every whisper call (line 243) — including output_mode/mode combinations where the JSDoc says it has no effect (only form/high_quality/table). For callers who upgrade without touching their code, this silently pins the threshold to 0.3 instead of letting the server apply its own default.

• If the server default is already 0.3, this is a no-op and fine — please confirm it matches so there's no behavior change on upgrade.
• This follows the existing convention (all params are forwarded unconditionally), so it's consistent — flagging only the divergence risk.

[P3 · validation] No range check. Confidence is expected in [0, 1]; an out-of-range value (e.g. 30 instead of 0.3) is forwarded as-is. Other numeric params aren't validated either, so this is optional — but a confidence score is more error-prone to mistype than a filter size.

[johnyrahul]

Thanks for the review. Addressed in 11cc514:

• JSDoc formatting (P2): fixed (the blank line now has a leading *).
• Param-forwarding tests (P2): you're right, the PR description was inaccurate — added two tests in test/retry.test.js using the existing captured-config adapter pattern, asserting word_confidence_threshold is forwarded for a custom value (0.7) and for the omitted default (0.3).
• Forced-on-every-request (P2): confirmed the server default is also 0.3, so there's no behavior change on upgrade. Keeping the param forwarded unconditionally to stay consistent with the existing convention and with the Python client (PR #33), which uses the same 0.3 default.
• Range validation (P3): leaving as-is for parity with the other numeric params and the Python client, which don't validate either.

[jaseemjaskp]

Re-reviewed via the PR Review Toolkit (code-review, silent-failure, type-design, test-coverage, comment-analysis, simplification). The feature wiring is mechanically correct and idiomatic, and the two added forwarding tests lock in the snake_case mapping + default. The substantive behavioral concern (unconditional 0.3 default) and the range-validation note are already captured in my earlier open thread on index.js:218, which remains the right place to resolve that discussion. Remaining observations (engines/axios bundling, JSDoc wording, test DRY) are intentional or minor. Approving.