Runtime sizing

Resource claims should come from evidence.

Teleza now has a repeatable resource-profile rehearsal that renders representative starter templates and records memory, CPU time, elapsed time, output sizes, and document-family coverage.

Representative render set

Default evidence covers 12 starter templates across finance, logistics, labels, claims, compliance, field service, procurement, legal, and statements.

Measured process footprint

The manifest records elapsed time, CPU time, average CPU cores, peak working set, private memory, output count, and output bytes.

No overclaiming

The local manifest is useful for sizing and regression checks, but it is not a hosted concurrency SLA.

Current local baseline

The first local profile captured on 2026-06-06 rendered 12 representative templates across 11 document families and produced 50 output artifacts. On the local Windows development machine, the run completed in roughly 3.5 seconds with a peak working set of roughly 74 MB.

This is local renderer evidence. VPS/container capacity must be captured separately before Teleza publishes hosted sizing guidance or stronger concurrency claims.

Evidence command

Operators can regenerate the manifest from the repository root:

powershell -NoProfile -ExecutionPolicy Bypass -File .\scripts\New-ResourceConsumptionManifest.ps1 powershell -NoProfile -ExecutionPolicy Bypass -File .\scripts\Test-ResourceConsumptionManifest.ps1

Hosted/VPS render-load evidence

Target evidence is separate from local profiling. It uses a disposable scoped API key to run bounded preview and PDF render batches against the deployed API, records health before and after, validates lineage hashes, stores output artifacts, and captures latency, output-size, and failure-category data.

This script mutates target telemetry and usage records, so it is gated by explicit approval and is still a private-beta rehearsal, not a hosted concurrency SLA.

powershell -NoProfile -ExecutionPolicy Bypass -File .\scripts\Test-TargetRenderLoadEvidence.ps1 ` -ApiBaseUrl "https://api.teleza.tech" ` -ApiKey "sk_live_..." ` -Iterations 6 ` -ConcurrentRequests 2 ` -RowsPerRender 3 ` -AllowTargetMutation

How enterprise reviewers should use it

  • Use local resource-profile evidence to detect render regressions before a release.
  • Use peak memory and output-size evidence as a starting point for Docker sizing.
  • Keep row, file, and provider caps enabled until target-host evidence proves higher limits are safe.
  • Require separate VPS/container evidence before publishing hosted capacity numbers.
  • Treat concurrent API render evidence as a separate release gate, not as an assumption from local rendering.
Read operations posture Read security posture