{"id":"b5543f9d-5ac3-4615-92cf-c240a8d0eca5","arxiv_id":"2509.12159","paper_version":2,"verdict":"CONDITIONAL","confidence":"MODERATE","novelty_score":6.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":3,"one_line_summary":"EfficientUICoder compresses UI image tokens by 55-60% and suppresses duplicate HTML/CSS/text output, cutting LLM FLOPs by ~45% and inference time by ~49% on Llava-1.6-34b without quality loss on two benchmarks.","lead":"The paper introduces EfficientUICoder, a framework that cuts image and code tokens for multimodal UI-to-code generation by about half while keeping output quality. It matters because it attacks the main cost of MLLM-based web development: long input images and long repetitive HTML output.","discovery_kind":"new_method","skeptic_critique":{"model":"deepseek-v4-flash","headline":"Table 2 for Llava-1.6-34b/WebCode2M shows EfficientUICoder below Vanilla on all six automatic quality metrics, contradicting the 'without compromising quality' claim absent significance testing.","rationale":"The reader's conditional verdict targets detector/attention assumptions and test-set hyperparameter tuning. I agree those are secondary risks. But I find a more immediate, internal inconsistency: the quality-preservation claim is contradicted by the paper's own headline-quality table for the largest model/dataset pair. The central claim is about simultaneous compression and quality preservation; if quality is actually lower on WebCode2M-34b, the contribution reduces to 'faster but worse,' which is not what the abstract promises. The paper's claim that human evaluation corroborates the automatic metrics is also not credible for this configuration, since all six automatic metrics move against EUC while human preference (Fig. 7b) favors it. Either the automatic metrics are invalid (undermining the paper's validation) or the human subset is not representative. Both possibilities require a specific statistical check. This is more load-bearing than the UIED detector concern because it does not depend on the quality of an external detector; it arises from the reported results themselves. I did not identify fraud or fabrication; the issue is missing statistical evidence and a too-strong summary of mixed results. The efficiency claim (Table 3) is plausible and not attacked here. Therefore I keep the reader's CONDITIONAL verdict rather than moving to ACCEPT or REJECT; the condition is the significance test and full-set human evaluation.","tokens_in":21518,"tokens_out":8159,"duration_ms":85568,"concrete_test":"Recompute the six automatic metrics for Llava-v1.6-34b on the full WebCode2M test set per sample, and run paired significance tests (e.g., Wilcoxon signed-rank or bootstrap 95% CIs) for EfficientUICoder vs Vanilla. If the six metrics are significantly worse (p<0.05) on any configuration, the 'without compromising quality' claim fails for that configuration. Additionally, run the human pairwise evaluation on the same full 100-page WebCode2M test set (not the 50-page subset) and report per-page votes; if the human result does not reproduce on the full set or does not match the automatic metrics, the Section 6.1 corroboration claim is unsupported.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim is that 55-60% image-token compression preserves webpage quality (Abstract; Section 6 RQ1). The paper's own Table 2 contradicts this for the 34B WebCode2M configuration: EfficientUICoder is numerically lower than Vanilla on every reported quality metric—Block 0.4382 vs 0.4688, Text 0.7533 vs 0.8207, Position 0.5907 vs 0.6441, Color 0.5313 vs 0.5546, CLIP 0.7270 vs 0.7554, BLEU 0.2634 vs 0.2689. Similar drops appear for Block in the other three configurations (Design2Code-7b: 0.3374 vs 0.3675; Design2Code-34b: 0.5318 vs 0.5516; WebCode2M-7b: 0.2718 vs 0.2843) and for BLEU on Design2Code-34b (0.2547 vs 0.2914). The paper states that 'human evaluation results corroborate our automatic metrics, confirming the validity of our automated metrics' (Section 6.1), yet for this configuration the two evidence sources diverge sharply. No error bars, confidence intervals, or significance tests are provided anywhere, so 'maintaining or improving generation performance' (RQ1 answer) is not established; at face value, the method trades quality for speed on part of the evaluation. This is load-bearing because the 'without compromising' portion of the headline claim is the necessary condition for calling the framework a free efficiency win. The efficiency improvements (Table 3) can still hold even if quality drops; the claim that they are achieved 'without compromising webpage quality' cannot be evaluated from the reported numbers.","agreement_with_reader":"partial"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes EfficientUICoder, a token-compression framework for MLLM-based UI-to-code generation. It combines three modules: Element and Layout-aware Token Compression (ELTC), which detects UI elements, builds a UI element graph, and applies a minimum spanning tree; Region-aware Token Refinement (RTR), which uses CLIP attention scores to refine the selected token set; and Adaptive Duplicate Token Suppression (ADTS), which tracks HTML/CSS/text repetition frequencies and applies an exponential penalty during decoding. The authors report experiments on Design2Code and WebCode2M using Llava-v1.6-7b/34b, claiming 55%–60% image-token compression, large reductions in FLOPs, prefill time, and inference time, and maintained or improved output quality. The manuscript also includes ablation, parameter, and human evaluation studies.","tokens_in":21943,"tokens_out":4917,"duration_ms":52702,"significance":"If the claims are substantiated, the paper addresses a real practical bottleneck in UI2Code: the high computational cost of long image-token sequences and repetitive output tokens. The direction is novel relative to prior visual-token compression methods (FastV, Pdrop, VisionZip), which ignore UI structure and do not address output redundancy. The paper is extensive: it includes two datasets, two model scales, automatic and human evaluation, an ablation study, parameter analyses, and a public code repository. The main contribution, however, rests on the assertion that large token compression can be achieved 'without compromising webpage quality'. That assertion is not consistently supported by the paper's own tables, and several key mechanism details are underspecified. The significance is therefore conditional on substantial revision.","major_comments":[{"comment":"The central claim of 'without compromising webpage quality' is contradicted by the paper's own results. For Llava-v1.6-34b/WebCode2M, EfficientUICoder is numerically lower than Vanilla on every automatic quality metric: Block 0.4382 vs 0.4688, Text 0.7533 vs 0.8207, Position 0.5907 vs 0.6441, Color 0.5313 vs 0.5546, CLIP 0.7270 vs 0.7554, BLEU 0.2634 vs 0.2689. Additional drops appear in Block match for the other three configurations and in BLEU for Design2Code-34b. No confidence intervals, error bars, or significance tests are reported anywhere. The statement in §6.1 that human evaluation 'corroborate[s] our automatic metrics' does not resolve this discrepancy, because the human study compares methods against Vanilla and may not align with the automatic metrics for this configuration. The efficiency gains in Table 3 can still hold with a quality drop; the 'free lunch' claim, however, ca","section":"§6.1, Table 2"},{"comment":"The mapping from the UI element tree / MST to the actual visual-token mask is never specified. Section 4.1 defines a graph and an MST over element bounding boxes, but it does not state which image patches are retained: all patches inside bounding boxes? Patches whose centers fall inside a box? How are tokens between or on the boundaries of boxes handled? How are overlapping boxes (after the merge step) reconciled with the token grid? The MST's edges are used only to define a tree, but there is no algorithmic rule connecting tree nodes/edges to token indices. Consequently, the ELTC module—the first and most novel stage—is not fully derivable or reproducible from the text. Section 4.2 describes refining the 'selected' and 'unselected' sets, but again relies on the unspecified output of ELTC. Please provide a precise, step-by-step algorithm for token selection, including any threshold or pa","section":"§4.1–4.2"},{"comment":"The compression-ratio definition is inconsistent with the reported numbers and with the abstract's '55%-60% compression' claim. Equation for R in §5.3.2 defines R = C_compressed / C_original. Under that definition, a value of 60.36% (Design2Code) or 55.86% (WebCode2M) means the method retains 60.36% and 55.86% of the original tokens, i.e., removes 39.64% and 44.14%, not 'compressing 55%-60% of tokens' as stated in §6.1 and the abstract. If the intended meaning is that 55%–60% of tokens are removed, then the formula and the reported percentages must be corrected. This is a headline-number inconsistency and must be fixed before the paper can be assessed fairly.","section":"§5.3.2 and §6.1"},{"comment":"The hyperparameters (s=3, λ=1/2, r=5–10%) are tuned on 100 webpages from Design2Code and 50 from WebCode2M, and the final performance tables (§6.1) report results on the full datasets. The paper does not state that the tuning samples are excluded from the final test sets, nor does it describe any held-out split or cross-validation for Design2Code/WebCode2M. Because parameter selection directly maximizes the same evaluation metrics on subsets of the same datasets, the reported numbers may be optimistically biased. Please clarify whether the tuning samples overlap with the final test sets and, if so, provide a separate held-out evaluation or internal cross-validation.","section":"§6.4 and §5.2"},{"comment":"The ADTS penalty procedure is underspecified. Equation (9) states that 'when duplicates occur, we will impose the following penalties on the subsequent s tokens’ logits' and writes z_i = z_i * λ^c for all i in {1,...,s}. In an autoregressive decoder, only the current step's logits can be modified; future tokens have not yet been generated. Does the method (a) at each step, penalize the logits of any token that has appeared in a tracked repeated structure, with intensity λ^c, for the next s decoding steps, or (b) re-score already generated tokens? The description in Algorithm 1 and the paragraph are too vague to reimplement. Please specify exactly which logits are modified at each decoding step, which tokens are eligible for penalty (e.g., all occurrences of the repeated string? only tokens that continue the repeated pattern?), and how c is maintained per structure.","section":"§4.3.2, Eq. (9)"}],"minor_comments":[{"comment":"Typos: 'elememt' and 'construted' appear in the same paragraph. Please proofread.","section":"§4.1.2"},{"comment":"Figure captions contain 'datatset' (Figures 8 and 9) and a mismatched caption: Figure 10 is titled 'Inference time under different λ and r' but the axes show decay factor λ and suppression step s, not r.","section":"Figures 8–10"},{"comment":"The Threat to Validity section refers to 'human evaluation (Section 2)', but human evaluation is described in Section 6.1, not Section 2. The reference should be corrected.","section":"§7"},{"comment":"The human evaluation reports only win/tie/lose percentages. It does not report the number of comparisons per annotator, pairwise inter-annotator agreement (e.g., Fleiss' kappa), or confidence intervals. These are standard for preference studies and would strengthen the claim that human results 'corroborate' the automatic metrics.","section":"§6.1, Human Evaluation"},{"comment":"The metric group is titled 'High-level Similarity', but BLEU is a code-text n-gram overlap measure, not a visual similarity. Consider renaming the group to 'Overall Similarity' or splitting the metrics.","section":"§5.3.1"}],"recommendation":"major_revision","confidential_remarks":"The paper is within the scope of a software-engineering or MLLM-systems venue and the code release is a strength. The biggest risk is that the headline 'without compromising quality' is not supported by Table 2; if the authors cannot add a rigorous statistical treatment, they should reframe the contribution as an efficiency/quality trade-off. I also recommend the editor ensure the authors provide the missing ELTC token-mask derivation and correct the compression-ratio definition, as both are load-bearing for the central claim. The hyperparameter-tuning overlap with the final test sets should be addressed explicitly."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"The paper is a genuine systems contribution with a real efficiency win, but the headline quality claim doesn't hold up in the tables as they stand. I'd send it to referees, not desk-reject it, because the core idea is sound and the code is out.\n\nWhat's new: the combination of UI-aware visual token selection with decode-side repetition suppression is not in FastV, Pdrop, or VisionZip, and the UI2Code generation papers don't address inference cost. The reported savings are large and internally consistent: roughly 45% FLOPs, 49% inference time, 41% generated tokens on the 34B models. The ablation shows each of the three components contributes; the code is public, so these numbers are checkable.\n\nWhere it gets soft. First, the claim that compression doesn't compromise quality is not established. In Table 2, for Llava-34b/WebCode2M, EfficientUICoder is below Vanilla on every automatic metric (Block 0.438 vs 0.469, Text 0.753 vs 0.821, Position 0.591 vs 0.644, Color 0.531 vs 0.555, CLIP 0.727 vs 0.755, BLEU 0.263 vs 0.269). Block also drops on the other three configurations, and BLEU drops on Design2Code-34b. There are no error bars or significance tests, so I can't tell whether those gaps are noise or a real trade-off. The human evaluation is on 50 pages per dataset, and it's not broken down per configuration, so it doesn't resolve the contradiction for that row. Second, the method section builds a UI element tree via MST, but never says how the tree maps to the token mask. That's a load-bearing operational detail. Third, the hyperparameters (s, lambda, r) are tuned on subsets of the same datasets used for final evaluation (100 Design2Code, 50 WebCode2M samples). That makes the final numbers optimistic, even if the effect is small. Fourth, there's no comparison against UI2Code generation systems like DCGen or LayoutCoder; the baselines are all token-compression methods, which supports the efficiency claim but doesn't really test 'state-of-the-art' quality.\n\nBottom line: the efficiency gains are real and worth knowing about, but the 'without compromising quality' phrase needs to be qualified or the experiments need to be redone with a held-out tuning split, repeated runs, and per-configuration human results. I'd accept this for peer review with a request for major revision. If I were working on efficient UI2Code, I'd cite it for the efficiency numbers and read the code, but I wouldn't repeat the quality claim without checking it myself.","headline":"Real efficiency gains, but the 'without compromising quality' claim is not supported by the reported tables.","tokens_in":22429,"tokens_out":3154,"would_cite":true,"duration_ms":33532,"reading_group":"yes","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"EfficientUICoder claims UI-to-code generation can drop roughly 60% of visual tokens and cut compute and latency by nearly half without hurting webpage fidelity.","keywords":["UI-to-code generation","multimodal large language model","token compression","visual token pruning","repetition suppression","HTML/CSS generation","efficient inference","layout-aware selection"],"falsifier":"Construct a set of UI screenshots where a small but essential element (a form field, icon, or link) is missed by element detection or receives near-zero attention. Run EfficientUICoder and the uncompressed model on them; if the compressed outputs systematically omit that element while the uncompressed outputs include it, the central quality-preservation claim fails. A second check: perturb detected bounding boxes slightly and measure block-match on the full benchmark—if quality collapses, the method's safety margin is critically thin.","tokens_in":21428,"feed_emoji":"⚡","tokens_out":5484,"duration_ms":65420,"temperature":0.7,"pith_summary":"EfficientUICoder tries to establish that the dominant cost of turning a webpage screenshot into HTML/CSS—very long image-token and code-token sequences—is largely redundant, and that this redundancy can be removed from both ends of a multimodal model. On the input side, it detects UI elements and builds a minimum-spanning-tree layout representation so only tokens that belong to meaningful elements and their spatial relations survive; on the output side, it tracks repeated HTML/CSS/text structures during decoding and applies an exponential penalty to suppress them. On two UI-to-code benchmarks with open 7B and 34B multimodal models, the reported effect is a 55–60% input-token compression, a 41% drop in generated tokens, and roughly 45–49% reductions in FLOPs, prefill time, and inference time, with rendered quality at or above the uncompressed baseline. If correct, this makes screenshot-to-code generation substantially cheaper, faster, and less prone to looping failures.","feed_headline":"Screenshot-to-code runs 45% faster with token compression","feed_subtitle":"Drops 55–60% of image tokens and suppresses repeated HTML/CSS while keeping webpage quality.","key_machinery":"The load-bearing objects are (1) a UI element tree: detected bounding boxes become graph nodes, edge weights are shortest spatial distances between boxes, and a minimum spanning tree yields the least-token representation that preserves element and layout relationships; (2) attention scores from the vision encoder's class token, used to rank token importance for refinement; (3) structure-frequency counters fed by CSS/HTML parsers that apply an exponential logit penalty to the next s tokens when repetitions are detected. The element tree performs coarse semantic selection, attention performs fine-grained pruning, and the penalty suppresses repetition loops at decode time.","core_discovery":"The central discovery is that UI images and MLLM-generated HTML/CSS both contain removable redundancy, attackable on opposite sides of the model. Encoding-side element detection builds a UI element graph weighted by spatial distance, then a minimum spanning tree selects tokens that cover UI elements and layout; attention scores then trim low-value tokens inside selected regions and recover high-attention background tokens. Decoding-side HTML/CSS parsers count repeated selector-property pairs, tag/content quadruples, and repeated text, and apply an exponential logit penalty. The reported effect is 55–60% input compression, roughly 41% fewer output tokens, and about 45–49% lower FLOPs, prefill","pith_inferences":["Beyond the paper's tests, the element-tree selection strategy may transfer to other structured visual generation tasks—slides, posters, or form designs from images—where layout hierarchy matters more than pixel-level detail.","A testable extension would apply the repetition-suppression idea to general code generation outside UI, where boilerplate inflates token budgets; the parser-based counters would need a language-specific grammar.","The reported gains depend on open models that expose visual-encoder and decoding hook points; closed API models may not permit the same input-token surgery, so deployment benefits in proprietary settings remain an open question.","One implicit consequence: on long, dense webpages the benefits may be larger than the reported averages, since both attention scatter and repetition loops worsen with sequence length."],"forward_implications":["UI2Code workloads on large multimodal models could run at roughly half the compute and latency while producing webpages of comparable or better quality.","Suppressing repetitive HTML/CSS/text does more than save tokens: it prevents models from getting trapped in generation loops that produce invalid or oversized webpages.","Attention-based visual token pruning alone is insufficient for UI tasks; combining element/layout structure with attention refinement preserves critical UI elements that pure attention methods miss.","Input-side visual compression and output-side code suppression address independent redundancies, so combining them yields efficiency gains larger than either approach alone."],"fun_headline_variants":["UI code generation cuts tokens 55-60% and speeds up 45%","Token compression speeds UI codegen 45% with 55-60% fewer tokens","EfficientUICoder halves compute for screenshot-to-code with 55-60% token drop","UI codegen 45% faster via bidirectional token compression","Screenshot-to-code slashes compute 45% using token redundancy"],"cache_read_input_tokens":2304,"weakest_assumption_plain":"The load-bearing premise is that the element detector's boxes and the vision encoder's attention scores jointly capture every UI detail, and that the grid-searched parameter settings transfer to the full test sets; if either fails, compressed inputs can omit critical elements and the 'without compromising quality' claim breaks.","fun_headline_variants_meta":{"raw":{"variants":["UI code generation cuts tokens 55-60% and speeds up 45%","Token compression speeds UI codegen 45% with 55-60% fewer tokens","EfficientUICoder halves compute for screenshot-to-code with 55-60% token drop","UI codegen 45% faster via bidirectional token compression","Screenshot-to-code slashes compute 45% using token redundancy"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000665,"raw_usage":{"total_tokens":2887,"prompt_tokens":772,"completion_tokens":2115,"prompt_tokens_details":{"cached_tokens":256},"prompt_cache_hit_tokens":256,"prompt_cache_miss_tokens":516,"completion_tokens_details":{"reasoning_tokens":2028}},"tokens_in":516,"tokens_out":2115,"duration_ms":13946,"temperature":1.0,"reasoning_tokens":2028,"cache_read_input_tokens":256,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-04T16:37:40.798407+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Construct a set of UI screenshots where a small but essential element (a form field, icon, or link) is missed by element detection or receives near-zero attention. Run EfficientUICoder and the uncompressed model on them; if the compressed outputs systematically omit that element while the uncompressed outputs include it, the central quality-preservation claim fails. A second check: perturb detected bounding boxes slightly and measure block-match on the full benchmark—if quality collapses, the method's safety margin is critically thin.","supporting_citations":[],"review_version":1}