High token usage in DOCX generation

Summary

When Codex creates or edits a Microsoft Word (.docx) document, it appears to use a potentially very token-expensive validation workflow.

During document generation, Codex may repeatedly render the document, create screenshots/images of individual pages, and then visually inspect those screenshots. For multi-page documents, this can result in many screenshots being generated and viewed, sometimes repeatedly after relatively small edits.

Problem

Image inputs can be substantially more expensive in terms of model context than simply inspecting the underlying document structure or using programmatic validation.

For example, for a document with many pages, Codex may:

1. Generate the DOCX.
2. Render the document to pages.
3. Create screenshots/previews for each page.
4. Inspect every page visually.
5. Make a small correction.
6. Render and inspect many or all pages again.

This potentially causes token/context usage to grow very quickly, particularly for long documents.

The issue is not necessarily that visual inspection is unnecessary. Visual validation is useful for detecting layout problems that cannot be found from document XML alone. The concern is that Codex may be performing substantially more visual inspection than necessary.

Expected behavior

Codex should ideally minimize expensive visual inspections when generating Word documents.

Possible optimizations could include:

• Validate document structure and formatting programmatically first.
• Render pages once after the document is substantially complete.
• Re-render only pages affected by subsequent edits.
• Avoid reopening/re-inspecting unchanged screenshots.
• Use lower-resolution previews when high-resolution visual analysis is unnecessary.
• Track which pages have changed so that unchanged pages do not need to be sent through the model again.
• Prefer deterministic checks for margins, page size, styles, tables, headings, etc. where possible.
• Perform a single final visual QA pass rather than repeatedly inspecting the entire document during construction.

Why this matters

For large documents, repeated screenshot inspection may consume a significant portion of a user's Codex quota even though the underlying task—creating or editing a DOCX—may not require that much model reasoning.

This can make document-generation tasks disproportionately expensive compared with comparable text/code tasks.

It may also contribute to rapid context growth and earlier context compaction during longer document-generation sessions.

Suggested investigation

It would be useful to measure:

• Number of screenshots/images generated during a DOCX task.
• Number of times each page is visually inspected.
• Image/input token usage attributable to those screenshots.
• Whether unchanged pages are repeatedly included in model context.
• Whether screenshots remain in subsequent conversation context after inspection.
• Token/quota consumption for programmatic DOCX validation versus visual validation.

An optimization that performs incremental/differential visual QA rather than repeatedly inspecting every page could potentially reduce token consumption significantly.

No files, tests, or entry points are identified in the issue. Start by locating the DOCX generation and visual-validation workflow, then measure screenshot creation, repeated page inspection, and image-token usage; done would be a validated reduction in redundant visual checks without losing necessary layout validation.