AskDocumentProfile
Description
AskDocumentProfile returns fast metadata about the document you sent and how long it is likely to take: the number of pages, the sheet format, and a processing-time estimate.
It is answered from the file's shape before any interpretation begins and without asking a model anything, so it arrives almost immediately and costs nothing extra. Ask for it next to the asks you actually need, and it is the first result you receive.
When to use
- Show a waiting user how long they are waiting. Reading a drawing takes seconds to minutes. With the profile, a progress bar or an ETA can replace an open-ended spinner.
- Size timeouts. Use
processing_time.seconds_p95rather than a fixed number. - Decide early whether to keep waiting, for example on a document with many more pages than you expected.
Show seconds_p50, size against seconds_p95
The estimate is a range and not a single number, because processing time has a long right tail: the median is around half a minute while the 99th percentile is over two minutes. Show seconds_p50 to a user; size timeouts and progress bars against seconds_p95.
processing_time is null when the document's shape is too unusual to compare against anything measured. Treat that as "no estimate", not as "fast".
A few things the fields do not say:
page_countis the length of the whole document, before any page limit is applied. It can therefore be larger than the number of pages that are read.paper_sizeisnullfor inputs that state no physical size, which is every raster image: a photograph or a scan carries pixels, not millimetres.CUSTOMis a real sheet that is not one of the named formats.- What kind of page the document holds is not part of this ask. Request
AskPageAssessmentfor the page type and for whether the pages carry welding callouts. The two are separate asks on purpose: asking for both gets you the profile straight away and the assessment later, rather than making the fast answer wait for the slow one.
Example Usage
To use the estimate while the read is still running, iterate over the messages as they arrive. The profile comes first:
ResponseDocumentProfile
Bases: Response
The document's shape: how big it is, and how long it is likely to take.
Read off the file itself, before any interpretation begins and without asking a model anything, so it arrives in milliseconds rather than seconds. Use it to tell a waiting user how long they are waiting.
What kind of page this is is no longer here. It costs a vision call, which is thousands of times slower than everything in this response, so keeping the two together meant the fast answer waited for the slow one. Ask AskPageAssessment for it, and for whether the pages carry welding.
| PARAMETER | DESCRIPTION |
|---|---|
ask_version | TYPE: |
ask_type | TYPE: |
page_count | Number of pages in the document, before any page limit is applied. Note that this does NOT drive the processing-time estimate: measured over 4,639 requests, two-page documents come back faster than one-page ones, so the estimate is keyed on sheet size instead. TYPE: |
paper_size | The sheet format. CUSTOM for a real sheet that is not one of the named formats. None for inputs that state no physical size, which is every raster image: a photograph or a scan carries pixels, not millimetres. TYPE: |
processing_time | How long this document is likely to take. None when the shape is too unusual to compare against anything we have measured; treat that as 'no estimate' rather than 'fast'. TYPE: |
Source code in werk24/models/v2/responses.py
ProcessingTimeEstimate
Bases: BaseModel
How long this document is likely to take to read.
Deliberately a range and not a single number. Werk24's processing time has a long right tail — the median is around half a minute while the 99th percentile is over two — so a point estimate would be wrong in the only case where being wrong is expensive: the request you are still waiting on. Show seconds_p50 to a user; size timeouts and progress bars against seconds_p95.
The estimate is made from the document's sheet size at the moment the file is read, before any interpretation, so it is available almost immediately and does not depend on what the drawing turns out to contain.
Deliberately not from page count, which is the obvious candidate and is wrong: measured over 4,639 requests, two-page documents come back faster than one-page ones (median 9.3 s against 18.7 s), almost certainly because a two-page PDF is usually a drawing plus a cover. Scaling by it would make the estimate worse.
| PARAMETER | DESCRIPTION |
|---|---|
seconds_p50 | Median expected processing time in seconds. Half of comparable documents finish faster than this. TYPE: |
seconds_p95 | 95th-percentile expected processing time in seconds. Size timeouts against this rather than against the median. TYPE: |
Source code in werk24/models/v2/models.py
Example Response
One response for the whole document: