Context: API Makeathon participant; found while running repeated generations against /ai/text-to-cad/{format}.
Behavior
Submitting a prompt the service has already generated appears to hit a dedupe/cache path:
POST /ai/text-to-cad/step?kcl=true returns a fresh id as usual;GET /user/text-to-cad/{id} shows completed immediately (first poll, ~0s), with the cached KCL in code;GET /async/operations/{id} returns 404 — permanently (still 404 an hour later);- and since
/user/text-to-cad/{id} never carries outputs while /async/operations/{id} is the only surface that does, the exported files of a completed, acknowledged job cannot be retrieved through any surface we can find.
Novel prompts run normally (150–270 s) and their /async/operations/{id} records resolve with full outputs. Two identical prompts submitted concurrently (second dispatched before the first completes) both run for real. Only after a completed generation exists does a repeat submission short-circuit.
Sample affected ids from 2026-07-22 (35 total on this account, happy to provide the full list): f7aa8cdc-d5a6-4e16-8e3c-c6c170f30a0f, dd6d37c4-c22f-44a6-838e-99c265cff680, d1bf86ad-15fa-4502-9695-50e9b650c2ba.
Why it matters
Dedupe itself is a great optimization (and appears not to bill — thank you). But callers polling the documented job surface get a completed job with no way to fetch its files; the workaround is nonce-ing prompts to force real generations, which defeats the cache.
Suggested fixes (any one resolves it)
- Dedupe hits return/point at the original job's async-operation (or its outputs directly);
outputs (or output URLs) carried on /user/text-to-cad/{id};- A re-export endpoint for a completed job id.
Related small nits while in this area: outputs values are unpadded base64 (strict decoders reject them), and the outputs-only-on-async-operations split itself is undocumented — either doc note would have saved us a debugging session.
Context: API Makeathon participant; found while running repeated generations against
/ai/text-to-cad/{format}.Behavior
Submitting a prompt the service has already generated appears to hit a dedupe/cache path:
POST /ai/text-to-cad/step?kcl=truereturns a fresh id as usual;GET /user/text-to-cad/{id}showscompletedimmediately (first poll, ~0s), with the cached KCL incode;GET /async/operations/{id}returns 404 — permanently (still 404 an hour later);/user/text-to-cad/{id}never carriesoutputswhile/async/operations/{id}is the only surface that does, the exported files of a completed, acknowledged job cannot be retrieved through any surface we can find.Novel prompts run normally (150–270 s) and their
/async/operations/{id}records resolve with fulloutputs. Two identical prompts submitted concurrently (second dispatched before the first completes) both run for real. Only after a completed generation exists does a repeat submission short-circuit.Sample affected ids from 2026-07-22 (35 total on this account, happy to provide the full list):
f7aa8cdc-d5a6-4e16-8e3c-c6c170f30a0f,dd6d37c4-c22f-44a6-838e-99c265cff680,d1bf86ad-15fa-4502-9695-50e9b650c2ba.Why it matters
Dedupe itself is a great optimization (and appears not to bill — thank you). But callers polling the documented job surface get a
completedjob with no way to fetch its files; the workaround is nonce-ing prompts to force real generations, which defeats the cache.Suggested fixes (any one resolves it)
outputs(or output URLs) carried on/user/text-to-cad/{id};Related small nits while in this area:
outputsvalues are unpadded base64 (strict decoders reject them), and the outputs-only-on-async-operations split itself is undocumented — either doc note would have saved us a debugging session.