This is an advice post, not a code post.

I have worked on CLI based field service software tools before. The UI for such things can be problematic. For what its worth, I'll make a few comments from my experience and resulting "scar tissue". For one project I was assigned the job of UI czar for 70 utilities. Learned a lot by talking with users about what was wrong. I had to "fix" the UI's of a bunch of programs that had already been written - this was hard to do. But I learned some stuff.

Some important factors are: who your users are, how much experience they have running your program and what their expectations are for "timeliness" of the results. We had some situations where the tech's would come to believe that the program was "stuck" and they would abend it in some aggressive fashion (like CTRL-C). For a variety of reasons this "premature program abortion" often made the service problem worse!

One of these things that we found out was that this simple "spinner" type gizmo doesn't work very well. The users quickly came to realize that this "spinner" thing or Windows "hour glass of death" idea was a separate process that just kept their eyes busy, but had no relationship as to whether actual work was being done or not. It looks cool, but didn't affect the user's decision to abend the program much if at all.

One effective way to present "work is still happening" via CLI is to just print a "." every so many "work units". Tweak the number of "work units" each dot represents. If the dots come at irregular time intervals, so much the better. This re-enforces the user perception that something "real" is happening underneath the covers. The user is less likely to abend the program. Again a simple "spinner" is not as effective - users know that "spinners" are usually "nonsense".

Best is of course if you can predict in advance say "how many work units" are needed and then present progress in percent towards that goal. If the "progress bar" moves every 30 seconds or so, that is enough. However a fancy progress bar is not needed, all that is needed is to present some status that clearly indicates "I am not hung, I just did X more records". The users will be patient if they are convinced that the program is actually doing something.

In your Amazon application, is it possible to give the user some metric about the size of the request? The users will via experience learn how long a "level 10" request vs a "level 1000" takes. If "level 10", ok wait for it right away, "level 10,000", let's go to lunch. For frequent users familiar with the program this approach can work very well even if you can't provide an on-going update about progress of the current request. I think this might have application in your situation?

I don't know if in this case whether it is possible or not, but consider breaking down complex requests (if at all possible) so that something happens for the user every say 20 seconds. By that I mean some kind of increment of user data is obtained, not just print a dot.

The users will trust the U/I if it "doesn't lie". Don't say "might take a long time" if you don't think that it will. An experienced user will allow at least 10-15 seconds for a command. Once a command runs for 60-90 seconds without apparent results, even an experienced user can come to doubt that something is happening. And again, just because some hour glass thing is there, that makes little difference in the determination that "program is hung".