Feature Request: `text_only` output support

[ritwik-g]

The current cli output for whisperer extraction contains the result and the metadata as well.

Retrieve API supports a text_only output which simply shows the text result as it is (If it is layout preserved the output will also be layout preserved. This mode can be useful when we only need the result_text.

[miraj2729]

Hi @ritwik-g, I'd like to work on adding the --text-only flag support for whisperer extraction. Could you please assign this issue to me?

[ritwik-g]

Hi @ritwik-g, I'd like to work on adding the --text-only flag support for whisperer extraction. Could you please assign this issue to me?

Hi @miraj2729 please feel free to raise a PR and share here. We can assign it to you once the initial PR is opened

[miraj2729]

Thanks @ritwik-g! I'm currently setting up the environment and writing the code for this. I'll submit the PR shortly. Please hold this issue for me!

[miraj2729]

Hi, I have addressed all the feedback and fixed the checks. The PR is ready for review when you get a chance. Thanks!

[ritwik-g]

#16

This is the PR right? @chandrasekharan-zipstack

[chandrasekharan-zipstack]

This is already covered on main by the generic -o raw output format, which prints the extraction's result_text alone, unwrapped, with layout preserved:

unstract whisper extract invoice.pdf -o raw > invoice.txt
unstract whisper retrieve <whisper_hash> -o raw

-o raw works across product commands (each declares which field it prints; unstract --discover full lists them), so there is no whisperer-specific flag to add.

How close is it to the API's text_only? Functionally identical for the caller: result_text is the layout-preserved text, and that is all that reaches stdout. The only difference is on the wire: with text_only=true the server skips sending the metadata bytes, whereas the CLI receives the full JSON and drops everything but the text locally. For a single retrieve that is negligible.

Why not pass text_only straight through to the API? The CLI calls the API via the llmwhisperer-client SDK (currently pinned at 2.9.0), and whisper_retrieve() there does not expose a text_only argument yet. A true passthrough would need that added to the client and released first, then the CLI pin bumped. Given the local -o raw already gives the same output, that is not worth chasing on its own; if the client gains the argument for other reasons, wiring it in becomes a one-liner.

If the gap here was discoverability rather than capability, a README example or a line in the whisper retrieve help text is the change to make.

---

Correction (2026-09-18): the two examples above put -o raw after the subcommand, which fails today with No such option '-o' (the bug in #12 / #15). Until #19 merges, global flags go before the subcommand:

unstract -o raw whisper extract invoice.pdf > invoice.txt
unstract -o raw whisper retrieve <whisper_hash>

PR #19 makes both placements work and closes this issue.

[ritwik-g]

This is already covered on main by the generic -o raw output format, which prints the extraction's result_text alone, unwrapped, with layout preserved:

unstract whisper extract invoice.pdf -o raw > invoice.txt
unstract whisper retrieve <whisper_hash> -o raw
-o raw works across product commands (each declares which field it prints; unstract --discover full lists them), so there is no whisperer-specific flag to add.

How close is it to the API's text_only? Functionally identical for the caller: result_text is the layout-preserved text, and that is all that reaches stdout. The only difference is on the wire: with text_only=true the server skips sending the metadata bytes, whereas the CLI receives the full JSON and drops everything but the text locally. For a single retrieve that is negligible.

Why not pass text_only straight through to the API? The CLI calls the API via the llmwhisperer-client SDK (currently pinned at 2.9.0), and whisper_retrieve() there does not expose a text_only argument yet. A true passthrough would need that added to the client and released first, then the CLI pin bumped. Given the local -o raw already gives the same output, that is not worth chasing on its own; if the client gains the argument for other reasons, wiring it in becomes a one-liner.

If the gap here was discoverability rather than capability, a README example or a line in the whisper retrieve help text is the change to make.

Okay @chandrasekharan-zipstack in that case this ticket is invalid. Lets close this. Lets close the PR also. But anyway please note there are some bugs that might make this usage itself bit difficult.

#12

@miraj2729 thank you for the effort. But apologies since this might not be an actual requirement anymore. Please feel free to raise contributions in the future.

[miraj2729]

Thank you for the clarification, @ritwik-g! Completely understand. It was a great learning experience working on this repository. Looking forward to contributing to other issues in the future!

…

On Fri, 18 Sept 2026 at 13:49, Ritwik G ***@***.***> wrote: *ritwik-g* left a comment (Zipstack/unstract-cli#14) <#14 (comment)> This is already covered on main by the generic -o raw output format, which prints the extraction's result_text alone, unwrapped, with layout preserved: unstract whisper extract invoice.pdf -o raw > invoice.txt unstract whisper retrieve <whisper_hash> -o raw -o raw works across product commands (each declares which field it prints; unstract --discover full lists them), so there is no whisperer-specific flag to add. *How close is it to the API's text_only?* Functionally identical for the caller: result_text *is* the layout-preserved text, and that is all that reaches stdout. The only difference is on the wire: with text_only=true the server skips sending the metadata bytes, whereas the CLI receives the full JSON and drops everything but the text locally. For a single retrieve that is negligible. *Why not pass text_only straight through to the API?* The CLI calls the API via the llmwhisperer-client SDK (currently pinned at 2.9.0), and whisper_retrieve() there does not expose a text_only argument yet. A true passthrough would need that added to the client and released first, then the CLI pin bumped. Given the local -o raw already gives the same output, that is not worth chasing on its own; if the client gains the argument for other reasons, wiring it in becomes a one-liner. If the gap here was discoverability rather than capability, a README example or a line in the whisper retrieve help text is the change to make. Okay @chandrasekharan-zipstack <https://github.com/chandrasekharan-zipstack> in that case this ticket is invalid. Lets close this. Lets close the PR also. But anyway please note there are some bugs that might make this usage itself bit difficult. #12 <#12> @miraj2729 <https://github.com/miraj2729> thank you for the effort. But apologies since this might not be an actual requirement anymore. Please feel free to raise contributions in the future. — Reply to this email directly, view it on GitHub <#14?email_source=notifications&email_token=COTTY52XZ2AYNIX2UB4LZE35PTSKJA5CNFSNUABFM5UWIORPF5TWS5BNNB2WEL2JONZXKZKDN5WW2ZLOOQXTKNZSGY4TIMJUGA2KM4TFMFZW63VHNVSW45DJN5XKKZLWMVXHJLDGN5XXIZLSL5RWY2LDNM#issuecomment-5726941404>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/COTTY54XMEPTPSSMHSWCH6L5PTSKJAVCNFSNUABGKJSXA33TNF2G64TZHMYTGMBXG4YTKOJZG45US43TOVSTWNJUHEYDINBWGQ3TTILWAI> . You are receiving this because you were mentioned.Message ID: <Zipstack/unstract-cli/issues/14/5726941404 ***@***.***>