AesCode 8B: Calculating the Cost of Aesthetic Code Generation Tasks

Why Token Cost Is Not Enough

The cost of generating a page with AesCode 8B does not necessarily reduce to input and output tokens. The model produces structured visual artifacts in HTML and CSS, and the workflow described by the project includes rendering the result in a browser and checking properties of the code and the page. If a result does not meet established criteria, a team may also decide to correct it or generate a new version.

It is therefore useful to distinguish inference cost, verification cost, and iteration cost. In a local deployment, these components may correspond to different resources: inference may consume GPU, while rendering and some checks may use CPU, memory, and a browser. The economic cost depends on how those resources are allocated and on the retry policy.

AesCode documentation describes the method and its verifiers, but does not publish rates, per-verification latencies, or a universal first-attempt success rate. The figures in this guide are variables for your own calculation, not measurements of AesCode 8B. The project's aggregate evaluation also does not equate to the probability that a particular task will pass all product criteria.

Cost Components

A useful estimate separates the workflow phases rather than assigning a single cost to each generation. Inference covers prompt processing and the production of HTML and CSS. Its duration depends, among other factors, on hardware, model configuration, input length, and the number of tokens generated.

The verification described by the project renders the HTML in a Playwright browser and executes deterministic checks. Among the properties examined are execution, text, element boundaries, table and chart data, semantic layout, and whitespace. The repository documents how these controls work, not their resource consumption or per-task latency.

Iteration appears when the workflow requires another generation or a correction after detecting a failure. Not all teams repeat the process in the same way: some set a maximum number of attempts, others correct only the code, and others incorporate human review. The average cost depends on that policy, the resources used in each phase, and the results observed on representative tasks.

Calculation Model and Assumptions

To estimate inference cost per attempt, you can divide the number of generated tokens by the effective generation speed. The result is an approximate time. If GPU cost is expressed per hour, the time can be converted to that unit and multiplied by the corresponding rate or internal cost. This approximation does not by itself represent the entire system utilization, especially when there are concurrent requests or shared resources.

Verification should be valued according to the resources it actually uses. If Playwright and the verifiers consume CPU, applying a GPU hourly rate to them without further qualification does not necessarily reflect their cost. For a more faithful estimate, it is advisable to measure and value each type of resource separately. The code example maintains a common rate only to illustrate the structure of the calculation.

The 1/p factor can estimate the average number of attempts only under specific assumptions: independent attempts, constant success probability, and repetition until success is achieved, with no limit on retries. Under those conditions, the combined inference and verification cost per attempt is calculated first, and the expected factor is applied only once. The first-attempt success rate, by itself, does not demonstrate that those assumptions hold. If subsequent attempts change strategy, cost, or probability, or if there is a maximum number of attempts, the model must be adapted.

def calculate_tco(output_tokens, tok_per_sec, gpu_cost_hour, t_verif_sec, success_rate):
    if tok_per_sec <= 0 or gpu_cost_hour < 0 or t_verif_sec < 0:
        raise ValueError("Times and costs must be valid")
    if not 0 < success_rate <= 1:
        raise ValueError("success_rate must be between 0 and 1")

    t_inference = output_tokens / tok_per_sec
    cost_inference = (t_inference / 3600) * gpu_cost_hour
    cost_verification = (t_verif_sec / 3600) * gpu_cost_hour
    iteration_factor = 1 / success_rate

    return (cost_inference + cost_verification) * iteration_factor

Hypothetical Example: 100 Presentations

Suppose, only to illustrate the calculation, an average output of 5,000 tokens generated at 50 tokens per second, a verification of 10 seconds per attempt, and a cost of $2.00 per hour. The example applies the same rate to inference and verification for simplicity; it does not claim that verification consumes GPU or that those values correspond to a real AesCode 8B installation.

Under those assumptions, inference lasts 100 seconds and verification another 10 seconds per attempt. The combined cost is 110/3600 × 2 = $0.061111 per attempt. If, in addition, a success rate of 80%, independent attempts, constant probability, and unlimited repetition until acceptance are assumed, the average factor is 1/0.8 = 1.25. The estimated cost per accepted task is therefore 0.061111 × 1.25 = approximately $0.076389. For 100 tasks, the estimate is $7.64.

The example is not a rate or a measured result. Changing the speed, verification duration, resource cost, success rate, or retry policy changes the result. The relationship between expected cost and success probability is inverse under these assumptions; it is not exponential growth.

How to Obtain Your Own Estimate

An operational estimate must be based on the same hardware, configuration, and workflow planned for the deployment. Before measuring, define what it means for a task to be accepted: for example, which content requirements must be met and which visual defects are grounds for rejection. Without stable criteria, the success rate does not allow consistent comparison of configurations.

Record inference, rendering, and each verification separately. For each task, note the input and output tokens, the duration and resources used in each attempt, the failures detected, and the number of retries. If the workflow limits attempts, allows partial corrections, or requires human review, incorporate those rules into the calculation instead of assuming the same process is repeated until success.

A test set must represent the prompts, reference images, and page types expected in the application. A small test can serve as a first approximation, but it does not turn its success rate into a guarantee for other tasks. Differences in complexity, concurrent load, browser configuration, and hardware can change both time and cost.

Scope of Results and Limits of the Estimate

The project's published evaluation reports aggregate results for 300 infographic samples, with three generations per prompt and no selection between generations. Those metrics describe the benchmark's performance and its evaluation dimensions; they do not constitute a general first-attempt success rate for any application, prompt, or acceptance criterion. They also do not demonstrate that a page passing deterministic checks is ready for delivery without visual review.

The repository describes rendering with Playwright and six deterministic verifiers, in addition to visual evaluation channels. It does not publish the cost or duration of each verification, CPU or GPU consumption per task, or a universal initial success rate. The configuration used in an evaluation also does not by itself allow deducing the memory required or performance on different hardware.

Therefore, the result of the calculation should be read as an estimate conditioned by the chosen measurements and assumptions. Separating GPU and CPU costs, making the retry policy explicit, and using reproducible acceptance criteria helps compare deployments; it does not guarantee that cost or quality will remain constant when hardware, load, or prompts change.

Keep exploring

Corrections and transparency

If you spot incorrect or outdated information, send us a correction with the page and source we should review.