CodeShrink: Adaptive Visual Compression for Efficient Multimodal Code Understanding Wenxin Tang1 , Jingyu Xiao2 , Zhenyu Liu3 , Zipeng Xie4 , Junliang Liu2 , Wang Luo5 , Yuan Jiang6 , Yintong Huo7 , Michael Lyu2
arXiv:2607.29637v1 [cs.CV] 31 Jul 2026
1
Tsinghua University 2 The Chinese University of Hong Kong 3 Northwestern Polytechnical University 4 Xi’an Jiaotong University 5 Sun Yat-sen University 6 Harbin Institute of Technology 7 Singapore Management University [email protected], [email protected]
Abstract—Rendering source code as images offers a promising way to reduce the input costs of Multimodal Large Language Models (MLLMs). Adjusting image resolution can trade visual token cost against content fidelity. However, resolution scaling alone overlooks two sources of inefficiency: blank regions created by line breaks and indentation, and code regions irrelevant to the current instruction. Moreover, the best compression setting varies across inputs, tasks, and models, limiting fixed-ratio strategies. We propose CodeShrink, an adaptive visual compression framework with three components. Blank-Free Rendering replaces whitespace-dependent layouts with compact layouts and explicit structural markers, removing layout-induced tokens. Adaptive Compression Configuration uses a lightweight agent trained with reinforcement learning to predict a per-input setting that balances token efficiency and readability. Dominant Token Selection jointly analyzes the instruction and code image to prune task-irrelevant visual tokens during inference. We evaluate CodeShrink on code question answering, clone detection, and code completion. CodeShrink reduces visual token use by up to 71.2% while matching or exceeding uncompressed text-only inputs, and consistently outperforms text-based and visual compression baselines across all three tasks. These results show that combining layout compaction, adaptive configuration, and instruction-aware pruning can make multimodal code understanding more efficient. Our code is available at https://github.com/vinsontang1/CodeShrink. Index Terms—Code Intelligence, Token Compression, MLLMs.
I. I NTRODUCTION Large Language Models (LLMs) have become increasingly important in automated software engineering, demonstrating strong capabilities across a wide range of code intelligence tasks, such as code question answering [1], [2], code clone detection [3], and code completion [4] and code generation [5]–[8]. By modeling source code as natural-language-like textual sequences, modern LLMs have demonstrated strong capabilities in reasoning over program semantics, supporting developers in understanding, maintaining, and generating code. However, source code often contains long contexts, repetitive syntax, and structurally sparse formatting, making token consumption a critical bottleneck [9], [10] in code intelligence. As model inference costs and context length scale with the number of input tokens, token compression has become an important direction for scalable code intelligence. To reduce input costs, prior studies such as LLMLingua [11], LongLLMLingua [12], LLMLingua-2 [13], and
LongCodeZip [14] have attempted to compress code contexts directly in the textual token space. However, text-based compression remain constrained by the text modality itself and may introduce explicit semantic loss. In contrast, the image modality offers a key advantage in compressibility [15]: image resolution can be continuously adjusted to scale token costs without altering the underlying content. Motivated by this, recent work such as CodeOCR [1] has explored an alternative paradigm: rendering source code into images and leveraging Multimodal Large Language Models (MLLMs) for visual code understanding, offering a more computationally efficient alternative to text representations. Rendering code as images introduces several key design choices that critically affect both token efficiency and performance. First, code images are inherently sparser than text: rendering source code with original line breaks and indentation often introduces substantial blank regions on the code image, which are encoded as visual tokens alongside code characters yet carry little semantic value. Second, image resolution directly governs visual token cost: while lower resolutions reduce token consumption, they inevitably compress character size, code structure, and syntax highlighting, degrading code readability for MLLMs. Hence, two natural questions arise: (1) Are all visual tokens on the code image equally necessary? (2) How should resolution be determined to balance token efficiency and code readability? To answer these questions, we first identify visual redundancy in code images (Section III-A) by analyzing rendered code images and MLLM attention distributions over visual tokens. Our layout and attention visualizations reveal that redundant visual tokens originate from uninformative regions, such as blank areas caused by line breaks and indentation, and code-character regions weakly related to the downstream tasks. To examine the influence of scale ratios (Section III-B), we further evaluate code intelligence tasks under different scale ratios and compare fixed-ratio strategies with an oracle dynamic selection strategy. The analysis indicates that the optimal trade-off between performance and token scale ratio varies across downstream tasks. These findings demonstrate that effective code-image compression requires not only eliminating visual redundancy, but also adaptively determining the optimal resolution to accommodate varying task demands.
(a)
(b) 85
Code QA Code Clone Detection Code Completion
82.1
80 75 71.2 70
6.6%
63.8
65
9.6%
55.8%
68.8 64.6 62.3
62.0
12.1%
56.6
55
3× 4×
(c)
5× 6×
7× 8×
56.6
52.9 50.1
50 1× 2×
61.6
61.5
60
48.1
46.1
45 DS
1x
2x
(d)
4x
8x
Fig. 1. Preliminary study of code image compression. (a) Original code rendering contains substantial blank regions, shown in gray. (b) Attention visualization shows that task-relevant code regions receive higher attention than other regions. (c) The preferred scale ratio varies across code completion samples. (d) Dynamic selection (DS) surpasses the best fixed scale ratio across all three tasks. Code QA and code clone detection are evaluated by accuracy, and code completion is evaluated by edit similarity (ES).
Based on these findings, we propose CodeShrink, an adaptive visual compression framework for MLLM-based code understanding that eliminates redundancy at three stages: removing formatting-induced blank tokens at the rendering stage, pruning task-irrelevant visual tokens at the inference stage, and adaptively selecting the optimal resolution via a learned compression configuration. First, we propose BlankFree Rendering (BFR), which decouples code structure from whitespace by replacing verbose layouts with compact representations and explicit structural markers, thereby preserving indentation and line-break semantics while eliminating layoutinduced blank visual tokens. Second, we design Dominant Token Selection (DTS), which selects important visual tokens by analyzing the instruction and code image, enabling the MLLM to focus on task-relevant regions. Third, we introduce an Adaptive Compression Configuration (ACC) strategy, which employs reinforcement learning to dynamically select the compression configuration for different tasks. Together, these components advance CodeShrink beyond static resolution adjustment toward task-aware and model-adaptive visual token optimization. We evaluate CodeShrink on multiple code-related tasks, including code question answering, code clone detection, and code completion. Experimental results show that CodeShrink can substantially reduce visual token cost while maintaining or even improving downstream task performance. For instance, on Python code question answering, CodeShrink reaches 82.3% accuracy and surpasses the 81.0% of the uncompressed text-only input under about 40% visual token reduction, and it consistently outperforms both text-based and visual compression baselines. These results demonstrate that, through denser code image representation, dynamic token pruning and resolution selection, CodeShrink achieves substantial token compression with near-lossless task performance. Our contri-
butions are as follows: • We conduct an in-depth analysis of visual token representation in MLLM-based code understanding, identifying two visual redundancy in the typical rendering of code as images. • We propose CodeShrink, an adaptive compression framework that reduces layout redundancy through blank-free rendering, removes task-irrelevant visual tokens through dominant token selection, and learns a dynamic resolution and compression ratio selection strategy to adapt different tasks through reinforcement learning. • We conduct extensive experiments across multiple code understanding tasks, demonstrating that CodeShrink achieves substantial visual token compression while maintaining or even improving task performance. II. BACKGROUND A. Visual-based Code Understanding Visual-based code understanding treats source code as a rendered image rather than a textual token sequence, enabling MLLMs to perform code intelligence tasks directly from visual inputs. Let s denote a source code snippet and q a task instruction. A renderer R maps s to a code image I = R(s). Given I and q, a Multimodal Large Language Model M produces the output y = M (I, q), where y is the taskspecific prediction,for example, in code clone detection y is a binary label indicating whether two snippets are semantically equivalent. Unlike text-based code understanding, where s is tokenized into a textual sequence, the visual paradigm presents the whole snippet as a single rendered image, so the model reads program content directly from pixels, which shifts the textual input into a compressible visual input. B. MLLMs’ Process Pipeline for Code Intelligence Visual code understanding from code images typically have four stages: a renderer, a visual encoder, a modality projector, and an LLM. The renderer R converts code text into an image I under a chosen resolution and code image layout. The visual encoder splits I into patches and encodes them into a sequence of visual tokens. The projector aligns these visual tokens with the LLM embedding space, and the LLM then consumes the visual tokens together with the instruction tokens to generate the output. The computational cost of the MLLM grows with its input sequence length, which can be written as n = nimg + ntext , where nimg is the number of visual tokens from the code image and ntext is the number of instruction tokens. In code understanding tasks, ntext corresponds to a fixed-length task instruction and remains roughly constant across samples, while nimg scales with the length and complexity of the source code, dominating the total input and constituting the primary target for compression. III. P RELIMINARY S TUDY A. Visual Token Redundancy in Code Images In practical code understanding, MLLMs do not need to attend equally to every visual region in a code image. Some
regions in a code image come from formatting rather than program semantics. As shown in Fig. 1(a), when original line breaks and indentation are directly preserved on the code image, large blank regions appear around code blocks. These blank regions contain no code characters, but still occupy image area and are converted into visual tokens by the vision encoder. Under a limited resolution or visual token budget, the renderer often has to reduce the font size to fit the complete code, making code characters harder for the model to recognize under high scale ratios. Beyond explicit blank regions, code-character regions also show uneven importance. To analyze how MLLMs attend to code images, we compute attention scores of visual tokens on a code question answering example. As shown in Fig. 1(b), code regions related to the question receive clearly higher attention scores, while some task-irrelevant code regions have scores close to background regions. This indicates that even within regions containing code characters, some visual tokens contribute little to the current instruction. Observation 1: Existing code images contain visual token redundancy from blank and task-irrelevant code regions. B. Compression Configuration Preferences Vary Across Samples Existing code-as-image methods usually predefine a scale ratio and apply the same setting to all samples. However, different samples may require different trade-offs between visual clarity and token cost. To analyze this variation, we use code completion as an example and identify, for each sample, the highest scale ratio that preserves its task score. As shown in Fig. 1(c), the most cost-effective ratios are distributed across multiple ratio values rather than dominated by a single fixed setting. This suggests that one scale ratio cannot fit all samples. We further compare fixed scale ratios with an oracle dynamic selection strategy. For the dynamic strategy, each sample selects the best-performing result from all candidate ratios. As shown in Fig. 1(d), dynamic selection outperforms the best fixed ratio across multiple tasks. The improvement is especially clear on code question answering and code completion, where the scores increase from 71.3% and 52.9% to 82.1% and 63.8%, respectively. These results indicate that dynamic selection can exceed the performance upper bound of any single fixed ratio. Observation 2: The optimal trade-off between visual clarity and token cost varies across samples and tasks. IV. M ETHODOLOGY Overview. Based on the two observations, we propose CodeShrink (as shown in Fig. 2) to adaptively compress visual tokens for visual-based code understanding. CodeShrink first applies the Blank-Free Rendering (BFR) module (Section IV-A) to generate dense code images by flattening code with explicit structural markers. Then the Dominant Token
Algorithm 1 Blank-Free Rendering Inputs: code snippet s, scale ratio rδ , patch size τ , aspect ratio α Outputs: rendered code image pages I 1: T ← L INEARIZE(s) 2: B ← ⌈ns /rδ ⌉ // Target visual-token budget 3: p ← 1 4: repeat 5: (W, H) ← C ANVAS(B/p, α) 6: f ← max{ f : PAGES(T, W, H, f ) ≤ p } // Binary search 7: p′ ← PAGES(T, W, H, f ) 8: if p′ ≤ p then 9: break 10: else 11: p ← p′ // Raise page count 12: end if 13: until converged 14: H ← τ · ⌈Hused /τ ⌉ // Remove blank patch overhead 15: {L1 , . . . , Lp } ← PARTITION(L AYOUT(T, W, f ), p) 16: I ← D RAW ({Lk }, W, H, f ) 17: return I
Selection (DTS) module (Section IV-B) selects task-relevant visual tokens during inference while pruning tokens with low informational value. Finally, the Adaptive Compression Configuration (ACC) strategy (Section IV-C) learns compression configuration preferences from downstream task feedback and the given model, dynamically optimizing compression configuration for each sample. A. Blank-Free Rendering Code images contain blank regions from formatting like line breaks and indentation. We design Blank-Free Rendering (BFR) to render code at high density within a fixed visualtoken budget, allocating tokens to semantically-meaningful code content. As shown in Algorithm 1, given a code snippet s, we first perform structural linearization (line 1): we strip the whitespace of each line, drop empty lines, and encode the two-dimensional layout into a one-dimensional token stream using <INDENT> and <DEDENT> to represent indentation and de-indentation, together with a visible newline marker to preserve structure. The scale ratio rδ , provided by the agent in Section IV-C, then fixes a visual-token budget B = ⌈ns /rδ ⌉ (line 2), where ns is the number of tokens in s. The core objective of the layout algorithm is to maximize font size for readability while keeping the total visual token count within the budget and ensuring all code content fits within the image. We cast this as f ⋆ = max f : PAGES(T, W, H, f ) ≤ p , (1) and since the required page count PAGES is non-decreasing in the font size, the largest feasible font is found exactly by binary search (line 6), where p denotes the current number of
Background
Text
Encode
𝒓𝜹
Scaling
Code Image
+
Dominant Token Selection Shadow Layers Attention Score
Code
Blank-Free Rendering
Instruction
𝒓𝝆 Deep Layers
…
𝒓𝜹 MLLM Code Image def binary_search(nums: list[int], target: int) -> int:\n left, right = 0, len(nums) - 1\n while left <= right:\n ...
Code Snippet
𝒓𝝆 Adaptive Compression Configuration #2 Compress Preference Optimization #1 SFT Warm Up Update (𝒓𝟏𝜹 , 𝒓𝟏𝝆 )
Code Image Label
…
Rendering
Code Image
(𝒓𝑮𝜹 , 𝒓𝑮𝝆 ) MLLM Outputs 𝑹
𝑨
Fig. 2. The framework of CodeShrink.
pages, initialized to 1 (line 3). The code image shape is determined from the current budget B/p and a target aspect ratio α, subject to the minimum and maximum pixel resolutions accepted by the model (line 5). When the smallest font cannot fit the code within the current page count, we raise the page count to the required value and retry. This fixed-point iteration converges because the page count is monotonically increasing. Finally, we align the code image height up to the patch grid to remove the blank-patch overhead of a trailing partial row (line 14), distribute the code lines evenly across pages, and draw them. In this way, the visual tokens previously occupied by blanks are removed, compacting the code representation. B. Dominant Token Selection After BFR, visual redundancy still remains within both code regions and blank regions. Motivated by the observation in Section III-A, we apply region-aware pruning to foreground code tokens and background blank tokens separately. The key idea is to decide the most important visual tokens relevant to the task information after visual and instruction information have been fused.. As shown in Fig. 2, the compressed image is first split into visual tokens by the MLLM visual encoder. We then use edge and color-gradient cues to partition these tokens into foreground code tokens (green) and background blank tokens (blue). These visual tokens are fed together with the instruction tokens (red) into the shallow MLLM layers, allowing token importance to be estimated under the current instruction. Specifically, the Adaptive Compression Configuration (ACC) module in Section IV-C provides the pruning ratios rρ = (rρf , rρb ) for foreground and background tokens. After
the visual and instruction tokens are fused in the shallow MLLM layers, we use the query vector q of the final instruction token and the key vector ki of each visual token to measure token importance. Averaging over H attention heads, the importance score of visual token i is computed as: ⊤ H (h) (h) q k 1 X . ai = (2) softmax √i H d h=1 We rank tokens by importance within the foreground and background sets separately. The lowest rρf fraction of foreground tokens and the lowest rρb fraction of background tokens are removed, while the retained visual tokens continue through the remaining layers together with the text tokens. Because pruning physically removes visual tokens and their KV-cache entries once during prefill, subsequent layers operate on a shorter sequence and the effective nimg is reduced. Since the importance scores are conditioned on the instruction, the same code image can preserve different tokens for different tasks, guiding the model toward instruction-relevant code regions. C. Adaptive Compression Configuration Both BFR and DTS are controlled by the ratios rδ and rρ , whose optimal values vary across samples and tasks, as established in Section III-B. A single fixed setting is therefore suboptimal. To address this, we introduce a Config Agent that predicts a per-sample compression configuration through reinforcement learning (RL). The Config Agent πθ is a tiny MLLM. Given the 1× rendered image from BFR, it outputs a configuration a = (rδ , rρ ), where the scale ratio rδ sets the rendering budget B = ⌈ns /rδ ⌉
in Section IV-A and rρ = (rρf , rρb ) are the foreground and background pruning ratios in Section IV-B. Since the Config Agent only needs to capture the downstream model’s visual preference, rather than to solve the downstream task itself, we expose only the first page of the rendered image to the Agent. This keeps training efficient and avoids noise from task-specific reasoning. We define the action space as a grid:
The reward couples compression with correctness, allowing the Agent to learn aggressive compression within legibility constraints and remove the need for any hand-tuned ratio. Additionally, to enhance the downstream MLLM’s OCR ability on code images, we few-shot fine-tune it. V. E XPERIMENTS A. Experiment Setup
A = Rδ × Rρf × Rρb ,
(3)
where Rδ , Rρf , and Rρb are the discrete candidate sets of the scale ratio and of the foreground and background pruning ratios. To avoid repeatedly querying the MLLM for the same rollout during training, we evaluate every configuration a ∈ A on the sampled instances in advance, producing a precomputed environment D = Dsf t ∪ Drl , whose entries (I, a, C(a), y(a)) record the compression C(a) and prediction correctness y(a) of each configuration a on an instance I. The disjoint subsets Dsf t and Drl serve the supervised fine-tuning (SFT) and reinforcement learning (RL) stages respectively. For a configuration a with budget split B = Bf + Bb , the retained visualtoken count after pruning is N (a) = (1−rρf )Bf +(1−rρb )Bb , and we measure compression relative to the 1× image as C(a) =
ns , N (a)
(4)
where a larger C(a) indicates fewer retained tokens. We further denote by y(a) ∈ {0, 1} whether the MLLM answers correctly under a. Training proceeds in two stages. The SFT warm-up provides a sensible initialization: for each instance in Dsf t , among the configurations that the MLLM answers correctly, we select the one with the largest compression C(a) as the label, and supervise the Agent to predict it. This anchors the Agent at an aggressive yet still-legible operating point. We then refine the Agent with Group Relative Policy Optimization (GRPO) [16] so that it also learns to avoid configurations that break legibility. The reward retains the compression gain only when the answer stays correct and is normalized to [0, 1], R(a) =
C(a) y(a). maxa′ ∈A C(a′ )
(5)
For each instance in Drl , we draw a group of G configurations {a1 , . . . , aG } and compute the group-relative advantage Âi =
R(ai ) − mean({R(aj )}G j=1 ) . G std({R(aj )}j=1 )
(6)
Denoting the importance ratio by ηi = πθ (ai )/πθold (ai ), the per-sample clipped surrogate is ℓi (θ) = min ηi Âi , clip(ηi , 1 − ϵ, 1 + ϵ) Âi , (7) and the Agent maximizes: " # G 1 X J (θ) = E ℓi (θ) − β DKL (πθ ∥ πref ) . G i=1
(8)
1) Benchmark and Metrics: We evaluate CodeShrink on three representative code understanding tasks. Code Question Answering, which requires the model to answer naturallanguage questions grounded in a given code snippet, is evaluated on the QA dataset proposed by CodeOCR [1], from which we randomly sample 300 instances and report accuracy. Code Clone Detection, which asks the model to judge whether two snippets are semantically equivalent, is built upon GPTCloneBench [3], from which we randomly sample 200 balanced Type-4 instances and report accuracy together with F1 Score. Code Completion, which requires the model to complete an unfinished snippet, is drawn from LongCodeCompletion [4] with 200 randomly sampled instances and is measured by exact match (EM), which counts the proportion of predictions that exactly match the reference, and edit similarity (ES), which measures the character-level closeness between the prediction and the reference based on edit distance. Beyond task performance, we further quantify efficiency through the token reduction rate R = 1 − ncimg /nimg , where ncimg is the number of visual tokens after compression and nimg is that of the original rendering, which is set to match the token count of the plain-text version of the code. 2) Baselines: We compare CodeShrink against four groups of baselines. Reference Baselines establish the performance bounds. Text-Only feeds the full source code as text without compression. NoCtx answers without access to any code. Text-based Token Compression methods compress code in the textual space. LLMLingua [11] is a prompt compression method that uses a budget controller and token-level iterative compression to shorten prompts while preserving the original semantics. LLMLingua-2 [13] is a task-agnostic method that casts compression as a token-level preserve-or-discard classification problem trained on distilled data. LongLLMLingua [12] is a long-context-oriented method that performs question-aware coarse-to-fine compression with document reordering to retain the context most relevant to the question. LongCodeZip [14] is a code-specific method that first ranks function-level chunks by instruction relevance and then selects finer-grained code blocks under an adaptive token budget. Visual Token Compression methods prune visual tokens during inference. FastV [18] removesimage tokens according to attention after a designated LLM layer. VisionZip [17] first selects dominant visual tokens via visual-encoder attention and then merges the remaining ones by similarity. Code-as-Image methods render code into images. CodeOCR [1] renders source code into images and controls visual token cost by adjusting the image resolution.
TABLE I P ERFORMANCE COMPARISON OF DIFFERENT COMPRESSION METHODS ON THE P YTHON BENCHMARK ACROSS CODE CLONE DETECTION , CODE QUESTION ANSWERING , AND CODE COMPLETION . B OLD VALUES INDICATE THE OPTIMAL PERFORMANCE , WHILE UNDERLINED VALUES INDICATE THE SECOND - BEST PERFORMANCE .
Method Text-only NoCtx LLMLingua [11] LongLLMLingua [12] LLMLingua-2 [13] LongCodeZip [14] VisionZip [17] FastV [18] CodeOCR [1] CodeShrink (Ours)
Code Clone Detection (%) Code QA (%) Acc F1 R Acc R Reference Baselines 64.5 46.0 81.0 54.3 Text-based Token Compression 59.0 30.5 25.1 61.3 25.5 57.0 24.6 23.4 61.7 25.9 50.5 3.9 29.7 60.0 35.6 60.5 34.7 20.6 62.7 39.3 Visual Token Compression 50.0 29.9 16.7 65.7 18.7 53.5 13.5 18.4 66.0 22.1 Code-as-Image 61.5 39.4 51.7 68.0 65.9 41.4 82.3 39.7
TABLE II P ERFORMANCE COMPARISON OF DIFFERENT COMPRESSION METHODS ON THE JAVA BENCHMARK ACROSS CODE CLONE DETECTION AND CODE COMPLETION . B OLD VALUES INDICATE THE OPTIMAL PERFORMANCE , WHILE UNDERLINED VALUES INDICATE THE SECOND - BEST PERFORMANCE . Code Clone Detection (%) Code Completion (%) Acc F1 R ES EM R Reference Baselines Text-only 69.0 55.6 58.1 34.0 NoCtx 48.8 14.5 Text-based Token Compression LLMLingua [11] 60.5 36.1 25.3 57.3 25.5 28.1 LongLLMLingua [12] 59.0 33.3 35.8 58.1 27.5 23.2 LLMLingua-2 [13] 58.5 29.1 32.9 57.0 20.5 25.9 LongCodeZip [14] 64.0 45.0 37.6 48.0 17.5 13.7 Visual Token Compression VisionZip [17] 60.5 34.7 19.7 43.3 7.0 23.8 59.0 30.5 22.1 52.3 18.5 28.5 FastV [18] Code-as-Image CodeOCR [1] 63.0 41.3 37.1 10.0 71.0 70.1 71.2 63.8 34.0 32.4 CodeShrink (Ours) Method
3) Implementation Details: To train the Config Agent, we sample 100 instances per task and exhaustively evaluate the action space A = Rδ × Rρf × Rρb , where the scale ratio takes Rδ = {1, 2, . . . , 8}, the foreground pruning ratio takes Rρf = {0, 0.1, 0.3, 0.5}, and the background pruning ratio takes Rρb = {0.5, 0.7, 0.9, 1}, yielding 38,400 configuration entries across the three tasks. These instances are further split into three disjoint parts, of which 50% are used to fine-tune the OCR ability of the MLLM, 25% for the SFT warm-up, and 25% for the RL stage. As for the models, we adopt Qwen3.5-27B [19] as the downstream MLLM and Qwen3.50.8B [19] as the lightweight Config agent, both of which are fine-tuned with LoRA [20] of rank 16 and a learning rate of 1e-4. The SFT warm-up runs for 1 epoch, while the GRPO stage runs for 2 epochs with a group size of G = 8. To ensure a fair comparison across all methods, we adopt greedy decoding with temperature 0 and fix the random seed to 42 for reproducibility. Notably, benefiting from the less training
Code Completion (%) ES EM R 55.1 49.0
27.0 15.0
-
54.1 53.8 50.2 56.7
24.0 22.0 14.0 27.0
20.8 21.2 28.7 30.2
43.9 52.0
13.0 17.0
15.3 18.0
46.4 60.3
16.5 27.5
21.1
samples, fine-tuning the MLLM takes only about 25 minutes on 8 NVIDIA H20 GPUs, while training the Config Agent takes about 40 minutes on a single H20 GPU. 4) Research Questions: We conduct extensive experiments to answer the following research questions: • (RQ1) Overall Performance: Can CodeShrink effectively compress visual tokens while preserving code understanding performance? • (RQ2) Rendering Quality: How does Blank-Free Rendering (BFR) affect code readability across different models compared with vanilla code rendering? • (RQ3) Ablation Study: How does each component of CodeShrink contribute to the overall performance? • (RQ4) ACC Deep Dive: How do different tasks prefer different compression configurations, and how does this motivate Adaptive Compression Configuration (ACC)? • (RQ5) Case Study: Why does CodeShrink work? B. Overall Performance (RQ1) As shown in Table I and Table II, which report the main results on Python and Java, we can make the following observations: (1) CodeShrink attains the best performance while substantially compressing visual tokens, even surpassing the uncompressed Text-only input on most metrics. On Python, it reaches 82.3% accuracy on code question answering, which exceeds the 81.0% of Text-only under about 40% token reduction. We attribute this to the synergy of the three modules, where BFR frees budget through dense rendering, ACC adaptively selects the configuration setting that best matches each sample, and Dominant Token Selection (DTS) prunes instruction-irrelevant tokens at inference time, so that the limited budget is concentrated on task-relevant code and compression yields gains rather than degradation. (2) CodeShrink achieves a consistently better compressionperformance trade-off than both text-based and visual compression baselines. Text-based methods such as the LLM-
TABLE III C ROSS - MODEL COMPARISON BETWEEN VANILLA RENDERING AND OUR BFR RENDERING ACROSS THREE REPRESENTATIVE MLLM S , WHERE FOR EACH PAIR THE GREEN BACKGROUND HIGHLIGHTS THE BETTER RESULT.
Method
Qwen3-VL GPT-5-mini Gemini-3-Flash Qwen3-VL GPT-5-mini Gemini-3-Flash Qwen3-VL GPT-5-mini Gemini-3-Flash Qwen3-VL GPT-5-mini Gemini-3-Flash
Code Clone Detection Code QA (Acc/F1, %) (Acc, %) Vanilla BFR Vanilla BFR Image (1x) 67.0/50.6 68.4/54.6 58.5 63.2 64.0/45.2 62.6/41.9 76.4 71.8 67.8/55.6 68.9/54.2 76.7 77.1 Image (2x) 66.6/51.6 67.2/51.8 49.7 56.6 69.0/56.4 65.7/46.4 75.1 75.0 68.4/57.0 69.0/55.7 76.4 76.5 Image (4x) 59.2/31.8 65.5/47.0 50.6 57.4 68.8/56.8 66.1/49.6 57.9 71.9 67.6/55.4 68.8/53.1 77.2 78.7 Image (8x) 60.8/35.4 65.3/47.9 51.3 58.6 64.0/47.0 65.6/46.5 52.5 69.3 70.2/60.8 71.4/59.4 76.3 77.0
Lingua family drop tokens directly in the textual modality, which tends to break code semantics and structure, as the F1 of LLMLingua2 collapses to merely 3.92% on Python clone detection. Although visual compression instead operates at the image level and thereby avoids such modality damage, conventional methods still rely on task-agnostic fixed pruning and suffer large losses on code, where the EM of VisionZip falls to only 13.0% on Python code completion. As a reference, the CodeOCR that renders code at a fixed 1× resolution lags clearly behind on demanding tasks such as code question answering, where it reaches merely 51.7%, which further confirms the necessity of Adaptive Compression Configuration. Answer to RQ1: CodeShrink delivers substantial visual token compression across all three code understanding tasks while maintaining or even exceeding the uncompressed input, and it consistently outperforms both textbased and visual compression methods. C. Rendering Quality (RQ2) Table III presents the cross-model comparison between vanilla rendering and our Blank-Free Rendering (BFR) rendering, where only the rendering function is replaced while the rest of the pipeline is fixed, across three representative MLLMs, namely Qwen3-VL-235B-A22B-Instruct [21] (Qwen3-VL), GPT-5-mini [22], and Gemini-3-Flash [23] and resolutions ranging from 1× to 8×. Several key observations emerge from this analysis. Following CodeOCR, we randomly sample 200 instances from each dataset and report results averaged over five independent runs. (1) BFR rendering outperforms vanilla rendering on almost all models and
Code Completion (ES/EM, %) Vanilla BFR 36.2/10.5 49.1/21.9 58.3/29.7
54.7/23.8 51.4/19.6 61.6/34.7
33.8/8.2 47.1/17.7 58.3/28.6
51.9/21.2 48.3/16.1 61.0/33.4
37.7/10.7 44.2/14.9 58.5/28.6
49.2/18.3 46.8/12.0 60.5/31.9
41.0/11.9 44.1/13.5 57.8/25.3
47.1/14.5 45.7/12.2 60.4/30.6
resolution levels without any model-specific adaptation. Since BFR operates only at the rendering stage and leaves the model untouched, it brings consistent gains even to the closedsource GPT-5-mini and Gemini-3-Flash that are never trained, which indicates that this rendering optimization is modelagnostic and can be transferred across different MLLMs as a plug-and-play improvement. (2) The gains become especially pronounced on long code tasks and under high compression. On the long code task, which is code completion, BFR rendering leads by a clear margin, where the ES and EM of Qwen3-VL at 1× rise from 36.2% and 10.5% to 54.7% and 23.8% respectively. As compression intensifies, vanilla rendering degrades markedly because of blank redundancy and the shrinking font size, whereas BFR preserves readability under aggressive compression by removing blanks and keeping the font legible, which further widens its advantage, as the code question answering accuracy of GPT-5-mini at 8× jumps from 52.5% to 69.3%. Although GPT-5-mini occasionally favors vanilla rendering at low compression, BFR rendering regains a clear lead once entering the high compression regime. Answer to RQ2: As a model-agnostic and plug-and-play improvement, BFR rendering generally enhances code understanding across different MLLMs and compression levels, with its advantage being most pronounced on long code tasks and under high compression. D. Ablation Study (RQ3) We conduct an ablation study by removing one component at a time. Specifically, w/o BFR replaces Blank-Free Rendering with the vanilla rendering of CodeOCR, w/o DTS disables
TABLE IV A BLATION STUDY OF C ODE S HRINK ON P YTHON AND JAVA , WHERE EACH VARIANT REMOVES A SINGLE COMPONENT WHILE KEEPING THE REST UNCHANGED . w/o BFR, w/o DTS, w/o ACC, AND w/o SFT RESPECTIVELY DISABLE THE BLANK - FREE RENDERING , THE INFERENCE - TIME TOKEN PRUNING , THE C ONFIG AGENT, AND THE DOWNSTREAM FINE - TUNING . R DENOTES THE VISUAL TOKEN REDUCTION RATE . B OLD VALUES INDICATE THE OPTIMAL PERFORMANCE , WHILE UNDERLINED VALUES INDICATE THE SECOND - BEST PERFORMANCE .
1
2
4
8
r (a) Rendering scale ratio r
0.5 0.7 0.9 1.0
71.0 74.0 82.0 81.0 76.0 80.0 78.0 81.0 0.5 0.7 0.9 1.0
rb rb (b) Code Clone Detection (c) Code QA
0.5
55.8 64.2 61.7 59.3
rf
76.0 78.0 84.0 75.0
48.3 51.2 52.4 55.1
0.3
32.0 19.5 26.7 27.4 28.2
0.1
66.0 69.0 70.0 71.0
33.5 32.0 32.5 28.5 31.5
58.9 62.1 53.4 57.2
0.0
53
64.2 62.0 62.1 56.2 60.9
0.5
55
69.0 67.0 73.0 72.0
20.9 14.2 17.9 14.1 18.8
0.3
57
27.0 26.0 26.5 22.5 25.0
60.0 68.0 75.0 66.0
rf
64
63.0 65.0 67.0 63.0
59.9 58.4 58.6 54.8 57.9
0.1
61
59.0 61.0 62.0 60.0
Code Completion (%) ES EM R
0.0
73
0.5
65 0.3
Clone Acc QA Acc Completion ES
ES (%)
ACC (%)
82
rf
CodeShrink w/o BFR w/o DTS w/o ACC w/o SFT
0.1
CodeShrink w/o BFR w/o DTS w/o ACC w/o SFT
Code Clone Detection (%) Code QA (%) Acc F1 R Acc R Python 66.5 63.4 41.0 81.5 39.5 66.0 63.9 17.9 78.5 26.5 67.0 64.1 37.2 79.5 33.8 65.5 62.8 16.6 75.0 19.1 66.0 62.7 33.6 78.5 34.4 Java 70.5 69.4 53.5 69.0 67.5 22.7 69.0 68.2 45.7 64.5 63.2 22.5 68.5 67.9 35.1 -
0.0
Method
54.1 58.7 62.8 58.2 0.5 0.7 0.9 1.0
rb (d) Code Completion
Fig. 3. Task-dependent compression configuration of CodeShrink on the three code understanding tasks. (a) shows the effect of the scale ratio rδ , where the stars mark the best operating point of each task. (b–d) show the effect of the foreground and background pruning ratios rρf and rρb on code clone detection, code QA, and code completion respectively, where the red box marks the best configuration of each task.
visual token pruning, w/o ACC replaces the Config Agent with a fixed compression configuration, and w/o SFT removes downstream MLLM fine-tuning. In Table IV, w/o ACC causes the most pronounced degradation, where accuracy and token reduction drop simultaneously. The QA accuracy on Python falls from 81.5% to 75.0% and the clone detection accuracy on Java falls from 70.5% to 64.5%, while R drops from 53.5% to 22.5%, which confirms that persample adaptive configuration selection is the key to balancing performance and compression. BFR mainly contributes to the density of the code image. Removing it leaves accuracy largely unchanged but causes a sharp drop in R from 53.5% to 22.7% on Java clone detection, because without blank-free rendering the code becomes less dense and the font shrinks, which tends to distort the code under high scale ratios, so the Config Agent favors lower scale ratios to preserve performance. DTS and SFT provide mild but steady complementary gains, as removing DTS slightly lowers compression with almost no change in accuracy, and removing SFT leads to small declines in both accuracy and compression.
Answer to RQ3: Each component of CodeShrink has a positive impact on the results, and combining all components yields the best performance. E. ACC Deep Dive (RQ4) To better understand ACC, we analyze the compression configuration preferences of different code understanding tasks. Specifically, we study the scale ratio rδ of BFR and the foreground/background pruning ratios rρf and rρb of DTS. The analysis is conducted on 100 randomly sampled instances for each task. 1) The scale ratio rδ : To examine its effect, we vary rδ ∈ {1, 2, 4, 8}, where a larger value denotes stronger compression and lower resolution. As shown in Figure 3(a), the optimal scale ratio clearly differs across tasks. Specifically, QA and code completion peak at 1× and then decline steadily as compression increases, because both rely on fine-grained character and contextual details that a lower resolution erodes. In contrast, the accuracy of clone detection rises with compression and reaches its best at 8×, improving from about 63% to
70%, since judging clones only requires structural similarity and thus moderate compression even helps the model focus on the overall structure. 2) The pruning ratios rρf and rρb : Similarly, to analyze pruning, we vary rρf ∈ {0.0, 0.1, 0.3, 0.5} and rρb ∈ {0.5, 0.7, 0.9, 1.0}. As shown in Figure 3(b–d), the optimal foreground pruning ratio is likewise task-dependent. In particular, clone detection prefers a small ratio of 0.1, whereas QA and code completion favor 0.3. This gap arises because the code in clone detection is short, so each foreground token already carries enough information and overly aggressive pruning would discard key content. In contrast, the longer code in QA and completion produces foreground tokens that often contain meaningless fragments such as character tails, so both the foreground and the background can be pruned more aggressively, with a relatively high background ratio rρb consistently benefiting all tasks since the background is dominated by low-information blank regions. 3) Task-dependent optimal configuration: Taken together, the above results reveal that the optimal compression configuration is highly task-dependent. The best scale ratio shifts from 1× for QA and completion to 8× for clone detection, and the best foreground pruning ratio likewise varies from 0.1 to 0.3 across tasks, so no single configuration stays optimal for all of them. As a result, any manually fixed setting is inevitably a compromise that is suboptimal on part of the tasks, and the gap widens further once we note that different samples within the same task may also favor different configurations. This observation directly motivates our design, where instead of committing to one global setting, the Config Agent in our ACC module predicts a tailored configuration for each sample and thereby stays close to the per-task optimum. Answer to RQ4: The optimal compression configuration of CodeShrink is not fixed but varies across tasks and samples, so hand-tuned fixed parameters can hardly remain optimal. Our Config Agent addresses this by adaptively selecting the configuration for each sample, achieving consistently strong performance across tasks. F. Case Study (RQ5) To explain why CodeShrink works, we present visualized cases that illustrate its three core steps: Blank-Free Rendering (BFR), Dominant Token Selection (DTS), and Adaptive Compression Configuration (ACC). 1) Blank-Free Rendering (BFR): As shown in Fig. 5, the vanilla rendering preserves the original whitespace and indentation of the source code, so a large portion of the code image is occupied by blank regions that are still encoded as visual tokens yet carry no semantic content, leading to a blank coverage of 41.9% (marked in gray) while the font size remains only 22px. In contrast, BFR keeps the structural information through compact markers and removes the redundant blanks, reducing the blank coverage to 1.2%. Under the same token budget, this allows the font size to grow to 32px, which
makes individual characters and the overall code structure considerably clearer and easier for the model to recognize. 2) Dominant Token Selection (DTS): As shown in Fig. 6, the tokens retained by DTS align closely with the semantic need of each task rather than being uniformly distributed. For Code QA, where the question concerns the behavior of a specific function, the model concentrates its attention on the conditional branches and traces them step by step until reaching the else branch that determines the answer. For Code Clone Detection, where the goal is to decide whether two snippets are equivalent, the model attends to roughly symmetric regions across the two images, comparing their corresponding structures instead of focusing on either one alone. These patterns indicate that the retained tokens are exactly the ones the task relies on. 3) Adaptive Compression Configuration (ACC): For ease of illustration, here we only show the choices of the scale ratio. As shown in Fig. 4, the Config Agent selects 4× for this sample. A smaller ratio such as 1× or 2× keeps an unnecessarily high resolution and wastes visual tokens, whereas a larger ratio such as 8× shrinks the font to the point where the code becomes illegible to the model. By choosing 4×, the Agent reaches the best balance between legibility and compression, which illustrates how it adapts the configuration to the specific content of each sample. Answer to RQ5: CodeShrink works through three complementary mechanisms: (1) BFR removes blank redundancy to produce dense and legible code images, (2) DTS retains the instruction-relevant tokens for each task, and (3) ACC selects a suitable compression configuration for each sample, so that aggressive compression still preserves the information needed by the task. VI. R ELATED W ORK A. Multimodal Large Language Models for Code The integration of visual modalities into software engineering has attracted increasing attention. Existing work mainly falls into two categories: visual code understanding benchmarks [24]–[27], which evaluate MLLMs’ capabilities on multimodal coding tasks, and UI-to-code generation [28]– [30], which generates source code from UI screenshots or design mockups [31]–[35]. Beyond UI generation, AgileGen [36] incorporates visual artifacts into AI-assisted software development through human-AI collaboration. Unlike these studies, CodeShrink treats source code itself as the visual input and addresses layout-induced token redundancy and adaptive visual compression for efficient code understanding. B. Token Compression (1) Text-based Token Compression. Early efforts to reduce input cost operate directly in the textual token space. LLMLingua [11] identifies and removes non-essential tokens, and is further extended by LongLLMLingua [12] for question-aware long-context compression and LLMLingua-2 [13] through
…
(a) 1x
(a) 2x
(a) 4x
(a) 8x
Fig. 4. Case study of the configuration selection result. The Config Agent selects 4× for this sample, since 1× and 2× waste tokens on an unnecessarily high resolution while 8× makes the code illegible.
32px
22px
(a) The code image rendered by the vanilla method, which has a font size of 22px and a blank coverage (marked in gray) of 41.9%.
(b) The code image rendered by the BFR method, which has a font size of 32px and a blank coverage (marked in gray) of 1.2%.
Fig. 5. Code images rendered by different methods. Clone Detection
Code QA
Code Completion
(a)
(b)
What happens when mem_mode_to_string is called with a value that is not a MemMode enum member?
Complete the missing part of the addArgs function of the given code snippet in the images.
Fig. 6. Case study of the DTS on the three tasks, where the red boxes mark the visual tokens retained by DTS. Code clone detection contains two snippets, and the instruction is shown below.
token-level compression via knowledge distillation. For programming tasks, LongCodeZip [14] proposes a dual-stage code compression framework with adaptive token budgeting. Recent studies further improve code token efficiency by introducing semantics-preserving shorthand representations [37], compressing docstrings while maintaining code generation performance [38], and reducing unnecessary formatting overhead in source code [39]. (2)Visual Token Compression. For MLLMs, visual token compression has emerged as a complementary direction. FastV [18] is the first to identify inefficient visual attention in MLLMs, proposing a training-free method that prunes tokens with the lowest visual-text attention scores after an early transformer layer. VisionZip [17] selects visual tokens based on visual encoder attention and applies a merging strategy to retain residual information. For code-related tasks, EfficientUICoder [40] addresses token redundancy in UI2Code tasks via element-aware compression combined with attention-
based token refinement. CodeOCR [1] explores representing source code as rendered images, showing that MLLMs can effectively understand code under substantial resolution-based compression. However, these methods either target natural images or UI screenshots without addressing code-specific layout redundancy, and rely on fixed scale ratios that do not adapt to task or model preferences. CodeShrink addresses these limitations by eliminating layout-induced blank tokens , pruning task-irrelevant tokens, and learning a adaptive compression configuration. VII. T HREATS TO VALIDITY (1) We evaluate CodeShrink on three representative code understanding tasks using widely adopted benchmarks and standard metrics. While these tasks cover a broad range of scenarios, evaluating CodeShrink on additional software engineering tasks could further demonstrate its applicability. (2) Our experiments are conducted on Python and Java, which represent two widely used programming languages. Extending the evaluation to more programming languages and larger realworld software repositories would provide additional evidence of the generalizability of CodeShrink. VIII. C ONCLUSION In this paper, we investigated visual token redundancy in code images for MLLM-based code understanding, finding that blank regions, task-irrelevant code, and fixed compression configurations lead to inefficient visual token usage. We proposed CodeShrink, an adaptive visual compression framework consisting of Blank-Free Rendering (BFR), which removes layout-induced blank tokens, Dominant Token Selection (DTS), which prunes instruction-irrelevant visual tokens, and Adaptive Compression Configuration (ACC), which predicts per-input compression configurations via reinforcement learning. Experiments on code question answering, clone detection, and code completion show that CodeShrink substantially reduces visual tokens while matching or even surpassing uncompressed text-only inputs, consistently outperforming both text-based and visual compression baselines. R EFERENCES [1] Y. Shi, C. Xie, Z. Sun, Y. Chen, C. Zhang, L. Yun, C. Wan, H. Zhang, D. Lo, and X. Gu, “Codeocr: On the effectiveness of vision language models in code understanding,” arXiv preprint arXiv:2602.01785, 2026.
[2] S. Rando, L. Romani, A. Sampieri, L. Franco, J. Yang, Y. Kyuragi, F. Galasso, and T. Hashimoto, “Longcodebench: Evaluating coding llms at 1m context windows,” arXiv preprint arXiv:2505.07897, 2025. [3] A. I. Alam, P. R. Roy, F. Al-Omari, C. K. Roy, B. Roy, and K. A. Schneider, “Gptclonebench: A comprehensive benchmark of semantic clones and cross-language clones using gpt-3 model and semanticclonebench,” in 2023 IEEE International Conference on Software Maintenance and Evolution (ICSME). IEEE, 2023, pp. 1–13. [4] D. Guo, C. Xu, N. Duan, J. Yin, and J. McAuley, “Longcoder: A longrange pre-trained language model for code completion,” in International Conference on Machine Learning. PMLR, 2023, pp. 12 098–12 107. [5] H. Yu, B. Shen, D. Ran, J. Zhang, Q. Zhang, Y. Ma, G. Liang, Y. Li, Q. Wang, and T. Xie, “Codereval: A benchmark of pragmatic code generation with generative pre-trained models,” in Proceedings of the IEEE/ACM 46th International Conference on Software Engineering, ser. ICSE ’24. New York, NY, USA: Association for Computing Machinery, 2024. [Online]. Available: https://doi.org/10.1145/3597503.3623316 [6] M. Liang, X. Xie, G. Zhang, X. Zheng, P. Di, W. Jiang, H. Chen, C. Wang, and G. Fan, “Repogenix: Dual context-aided repository-level code completion with language models,” in Proceedings of the 39th IEEE/ACM International Conference on Automated Software Engineering, ser. ASE ’24. New York, NY, USA: Association for Computing Machinery, 2024, p. 2466–2467. [Online]. Available: https://doi.org/10.1145/3691620.3695331 [7] D. Liao, S. Pan, X. Sun, X. Ren, Q. Huang, Z. Xing, H. Jin, and Q. Li, “A3 a3-codgen: A repository-level code generation framework for code reuse with local-aware, global-aware, and third-party-libraryaware,” IEEE Transactions on Software Engineering (TSE), vol. 50, no. 12, pp. 3369–3384, 2024. [8] J. Xiao, Z. Zhang, H. Hou, Y. Wan, Y. Jiang, Y. Huo, and M. R. Lyu, “Visualrepair: Dynamic tool calling and region focusing for visual software issue repair,” 2026. [Online]. Available: https: //arxiv.org/abs/2607.14075 [9] Y. Wang, X. Li, T. N. Nguyen, S. Wang, C. Ni, and L. Ding, “Natural is the best: Model-agnostic code simplification for pre-trained large language models,” Proc. ACM Softw. Eng., vol. 1, no. FSE, Jul. 2024. [Online]. Available: https://doi.org/10.1145/3643753 [10] Z. Zhang, H. Zhang, B. Shen, and X. Gu, “Diet code is healthy: simplifying programs for pre-trained models of code,” in Proceedings of the 30th ACM Joint European Software Engineering Conference and Symposium on the Foundations of Software Engineering, ser. ESEC/FSE 2022. New York, NY, USA: Association for Computing Machinery, 2022, p. 1073–1084. [Online]. Available: https://doi.org/10.1145/3540250.3549094 [11] H. Jiang, Q. Wu, C.-Y. Lin, Y. Yang, and L. Qiu, “Llmlingua: Compressing prompts for accelerated inference of large language models,” in Proceedings of the 2023 conference on empirical methods in natural language processing, 2023, pp. 13 358–13 376. [12] H. Jiang, Q. Wu, X. Luo, D. Li, C.-Y. Lin, Y. Yang, and L. Qiu, “Longllmlingua: Accelerating and enhancing llms in long context scenarios via prompt compression,” in Proceedings of the 62nd Annual Meeting of the Association for Computational Linguistics (Volume 1: Long Papers), 2024, pp. 1658–1677. [13] Z. Pan, Q. Wu, H. Jiang, M. Xia, X. Luo, J. Zhang, Q. Lin, V. Rühle, Y. Yang, C.-Y. Lin et al., “Llmlingua-2: Data distillation for efficient and faithful task-agnostic prompt compression,” in Findings of the Association for Computational Linguistics: ACL 2024, 2024, pp. 963– 981. [14] Y. Shi, Y. Qian, H. Zhang, B. Shen, and X. Gu, “Longcodezip: Compress long context for code language models,” in 2025 40th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE Press, 2025, p. 141–153. [Online]. Available: https://doi.org/10.1109/ASE63991.2025.00020 [15] H. Wei, Y. Sun, and Y. Li, “Deepseek-ocr: Contexts optical compression,” arXiv preprint arXiv:2510.18234, 2025. [16] Z. Shao, P. Wang, Q. Zhu, R. Xu, J. Song, X. Bi, H. Zhang, M. Zhang, Y. Li, Y. Wu et al., “Deepseekmath: Pushing the limits of mathematical reasoning in open language models,” arXiv preprint arXiv:2402.03300, 2024. [17] S. Yang, Y. Chen, Z. Tian, C. Wang, J. Li, B. Yu, and J. Jia, “Visionzip: Longer is better but not necessary in vision language models,” in Proceedings of the IEEE/CVF Conference on Computer Vision and Pattern Recognition, 2025, pp. 19 792–19 802.
[18] L. Chen, H. Zhao, T. Liu, S. Bai, J. Lin, C. Zhou, and B. Chang, “An image is worth 1/2 tokens after layer 2: Plug-and-play inference acceleration for large vision-language models,” in European Conference on Computer Vision. Springer, 2024, pp. 19–35. [19] Q. Team, “Qwen3.5-omni technical report,” arXiv preprint arXiv:2604.15804, 2026. [20] E. J. Hu, Y. Shen, P. Wallis, Z. Allen-Zhu, Y. Li, S. Wang, L. Wang, W. Chen et al., “Lora: Low-rank adaptation of large language models.” Iclr, vol. 1, no. 2, p. 3, 2022. [21] Q. Team, “Qwen3 technical report,” 2025. [Online]. Available: https://arxiv.org/abs/2505.09388 [22] OpenAI, “Gpt-5-mini model documentation,” https://platform.openai. com/docs/models/gpt-5-mini, 2025, accessed: 2026-01-30. [23] Google DeepMind, “Gemini 3 flash model card,” https://deepmind. google/models/model-cards/, 2025, accessed: 2026-01-30. [24] W. Tang, J. Xiao, W. Jiang, X. Xiao, Y. Wang, X. Tang, Q. Li, Y. Ma, J. Liu, S. Tang, and M. R. Lyu, “SlideCoder: Layoutaware RAG-enhanced hierarchical slide generation from design,” in Proceedings of the 2025 Conference on Empirical Methods in Natural Language Processing (EMNLP), C. Christodoulopoulos, T. Chakraborty, C. Rose, and V. Peng, Eds. Suzhou, China: Association for Computational Linguistics, Nov. 2025, pp. 9015–9039. [Online]. Available: https://aclanthology.org/2025.emnlp-main.458/ [25] K. Li, Y. Tian, Q. Hu, Z. Luo, Z. Huang, and J. Ma, “Mmcode: Benchmarking multimodal large language models for code generation with visually rich programming problems,” in Findings of the Association for Computational Linguistics: EMNLP 2024, 2024, pp. 736–783. [26] F. Zhang, L. Wu, H. Bai, G. Lin, X. Li, X. Yu, Y. Wang, B. Chen, and J. Keung, “Humaneval-v: Systematic evaluation of visual reasoning in large multimodal models for code generation,” ACM Trans. Softw. Eng. Methodol (TOSEM)., May 2026, just Accepted. [Online]. Available: https://doi.org/10.1145/3813804 [27] W. Tang, J. Xiao, Y. Gong, F. Ran, T. Xia, J. Liu, M. H. Lam, W. Wang, and M. R. Lyu, “Efficientpostergen: Semantic-aware efficient poster generation via token compression and accurate violation detection,” arXiv preprint arXiv:2603.00155, 2026. [28] T. H. Dang, J. Xiao, and Y. Huo, “Envisioning future interactive web development: Editing webpage with natural language,” 2025 2nd IEEE/ACM International Conference on AI-powered Software (AIware), pp. 61–66, 2025. [Online]. Available: https://api.semanticscholar.org/ CorpusID:282592059 [29] J. Xiao, J. Qin, S. Li, M. H. Lam, Y. Wan, J.-t. Huang, Y. Huo, and M. R. Lyu, “Comuicoder: Component-based reusable ui code generation for complex websites via semantic segmentation and element-wise feedback,” arXiv preprint arXiv:2602.19276, 2026. [30] C. T. Le, T. O. Y. Siang, J. Xiao, Y. Wan, and Y. Huo, “Uibenchkit: A unified toolkit for design-to-code model evaluation,” arXiv preprint arXiv:2605.13141, 2026. [31] Y. Wan, T. Liang, J. Xu, J. Xiao, Y. Huo, and M. R. Lyu, “From runnable to shippable: Multi-agent test-driven development for generating full-stack web applications from requirements,” arXiv preprint arXiv:2605.17242, 2026. [32] Y. Wan, Y. Dong, J. Xiao, Y. Huo, W. Wang, and M. R. Lyu, “Mrweb: An exploration of generating multi-page resource-aware web code from ui designs,” arXiv preprint arXiv:2412.15310, 2024. [33] J. Xiao, Y. Wan, Y. Huo, Z. Wang, X. Xu, W. Wang, Z. Xu, Y. Wang, and M. R. Lyu, “Interaction2code: Benchmarking mllm-based interactive webpage code generation from interactive prototyping,” in 2025 40th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE Press, 2025, p. 241–253. [Online]. Available: https://doi.org/10.1109/ASE63991.2025.00028 [34] M. Yuan, J. Chen, Z. Xing, A. Quigley, Y. Luo, T. Luo, G. Mohammadi, Q. Lu, and L. Zhu, “Designrepair: Dual-stream design guideline-aware frontend repair with large language models,” in Proceedings of the IEEE/ACM 47th International Conference on Software Engineering, ser. ICSE ’25. IEEE Press, 2025, p. 2483–2494. [Online]. Available: https://doi.org/10.1109/ICSE55347.2025.00109 [35] J. Xiao, M. Wang, M. H. Lam, Y. Wan, J. Liu, Y. Huo, and M. R. Lyu, “Designbench: A comprehensive benchmark for mllm-based front-end code generation,” arXiv preprint arXiv:2506.06251, 2025. [36] S. Zhang, Z. Xing, R. Guo, F. Xu, L. Chen, Z. Zhang, X. Zhang, Z. Feng, and Z. Zhuang, “Empowering agile-based generative software development through human-ai teamwork,” ACM Transactions on
Software Engineering and Methodology (TOSEM)., Jan. 2025. [Online]. Available: https://doi.org/10.1145/3702987 [37] Z. Sun, C. Yang, X. Du, Z. Yang, L. Li, and D. Lo, “Token sugar: Making source code sweeter for llms through token-efficient shorthand,” in 2025 40th IEEE/ACM International Conference on Automated Software Engineering (ASE). IEEE, 2025, pp. 2440–2451. [38] G. Yang, Y. Zhou, W. Cheng, X. Zhang, X. Chen, T. Y. Zhuo, K. Liu, X. Zhou, D. Lo, and T. Chen, “Less is more: Docstring compression in code generation,” ACM Transactions on Software Engineering and Methodology (TOSEM), vol. 35, no. 2, pp. 1–31, 2026. [39] D. Pan, Z. Sun, C. Zhang, D. Lo, and X. Du, “The hidden cost of readability: How code formatting silently consumes your llm budget,” arXiv preprint arXiv:2508.13666, 2025. [40] J. Xiao, Z. Zhang, Y. Wan, Y. Huo, Y. Liu, and M. R. Lyu, “Efficientuicoder: A bidirectional token compression framework for efficient mllm-based ui code generation,” Proceedings of the ACM on Software Engineering, vol. 3, no. FSE, pp. 2396–2418, 2026.