First off, inputs to the API are not collected as training data unless you opt-in to data sharing in the platform site (with the motivation that some may be offered free daily tokens in the same dialog for doing so).
First: I would look into real OCR software as a primary automation. AI vision that can read documents is a happenstance byproduct of image training, and instead of characters mis-recognized, the output can be complete hallucination and language fabrication.
The only reliable input method for documents as a whole is PDF file attachment to a user message. The AI can read through multiple pages, but this is best for knowledge, as there can be far greater input than the AI is willing to recite, and may produce refusals to do so just on “looks copyrighted, I’m confused” grounds.
So then you have placement of images.
AI image input has a limitation in that on the full-size models, a page would have a maximum width of 768 pixels, downsized by the API backend. This can crush the text below what is needed to “see”. Slicing of documents into your own sections, such as 1536x768, with overlaps, then becomes a good technique, where you can interleave “full thumbnail”, “zoomed slice 1”, text with the images and see the AI ability to produce meaningful recitation of images described or tables reproduced also. This also means less semantic information per slice besides the resolution, which is a benefit.
Newer “mini” AI models like gpt-4.1 have a different formulation: resolution can be a bit higher on a page, but internally is a “patches” type of vision, billed differently.
You can look on the bottom of the public pricing page for a little calculator per model. Or check this more interactive version.
You would want to evaluate models yourself against this use case, and then multiply those costs of image inputs per call by a million.
