1 Introduction↩︎

Large Language Models (LLMs) have recently shown strong performance in software engineering tasks, particularly code generation and code completion [1]–[5]. These capabilities are enabled by pretraining on massive public code corpora [6], which also exposes models to outdated coding patterns, including deprecated APIs frequently appearing in historical repositories [7]. As a result, Code LLMs may continue to generate obsolete API calls that no longer align with modern codebases, reducing code reliability.

This issue stems not only from knowledge cutoff, but also from outdated patterns embedded in the model’s parametric memory [8], which can bias Code LLMs toward deprecated APIs even when valid alternatives exist. In rapidly evolving libraries, such behavior may introduce compatibility issues and increase maintenance effort [9], [10]. Although fine-tuning can update model knowledge, it is often inefficient for localized API-level modifications since it globally updates model parameters. The key challenge is therefore to selectively remove outdated API knowledge while preserving the model’s general code generation capability [11].

Existing efforts to mitigate outdated API usage follow two main directions. Inference-time strategies, e.g., prompt augmentation and output-level API replacement [7], attempt to steer model outputs toward updated APIs without modifying the internal knowledge. However, these approaches assume that each input context can be accurately mapped to a specific replacement API, which may not be realistic in real-world scenarios. More direct model-level approaches, including model editing [12], [13] and machine unlearning [14]–[16], modify the model’s parametric memory to suppress undesirable knowledge. However, their application to deprecated API mitigation remains limited. Lin et al. [13] propose a dynamic editing approach that updates the model whenever a deprecated API is generated. This strategy operates locally and may not generalize well to unseen contexts. Recent approaches [15], [16] mainly focus on suppressing undesirable knowledge, without explicitly guiding the model toward correct API replacements required for evolving libraries.

In this paper, we propose CURE, a Contrastive Unlearning approach for deprecated API REplacement. The key idea is to shift unlearning from a purely suppressive process to a replacement-oriented mechanism. Specifically, CURE builds upon a parametric machine unlearning method, such as PROD [15] or SimNPO [17], to reduce the likelihood of generating deprecated APIs. On top of this, we introduce a contrastive objective that explicitly promotes correct API alternatives, enabling the model not only to forget outdated APIs but also to adopt valid replacements. We evaluate CURE on a recent deprecated API benchmark across four representative Code LLMs: DeepSeek-Coder-1.3B [18], StarCoder2-3B [19], CodeLlama-7B [20] and CodeGen-2B [21]. Experimental results show that CURE not only reduces deprecated API generation, but also improves correct API replacement compared to standard unlearning methods. Evaluation on HumanEval [22] further indicates that CURE preserves general code generation capability without noticeable degradation.

The main contributions of this work are as follows:

• We propose CURE, a contrastive unlearning framework for mitigating deprecated API usage in Code LLMs through replacement-oriented learning.

• We introduce a contrastive objective that explicitly aligns deprecated APIs with their corresponding updated alternatives under the same code context.

• Experiments on a recent deprecated API benchmark and HumanEval [22] show that CURE consistently reduces deprecated API generation, improves correct API replacement, and preserves general code generation capability compared to standard unlearning methods.

• We release our replication package to support future research [23].

2 Related work↩︎

Modern software systems evolve continuously, causing APIs to be frequently revised and deprecated in favor of improved alternatives [24]. This is particularly challenging for Code LLMs, whose static training corpora often encode outdated API knowledge, leading to deprecated API generation. Wang et al. [25] report that 37.4% of API predictions produced by GPT-3.5 involve deprecated APIs. Existing solutions mainly follow two directions: inference-level methods such as REPLACEAPI and INSERTPROMPT [25], modifying outputs without updating model, and model-level approaches including model editing [13] and reinforcement learning [26], which directly adapt knowledge within the model.

Closely related to these efforts, machine unlearning has recently emerged as a promising direction for removing undesirable knowledge from LLMs [27]. Existing approaches can be broadly categorized into exact and approximate unlearning [16], [28]. While exact methods retrain models from scratch to ensure complete data removal, approximate methods provide a more practical alternative through gradient-based parameter updates, including GA [28], DPO-based unlearning [29], NPO [30], and SimNPO [17]. More recently, PROD [15] introduces token-level suppression for precise code unlearning, while CODEEraser [16] selectively removes sensitive memorized code segments. Despite these advances, applying unlearning techniques to mitigate deprecated API usage in Code LLMs remains largely underexplored.

3 Proposed Method↩︎

In this section, we first formulate the unlearning problem for mitigating deprecated APIs, then present our proposed approach CURE, built upon a gradient-based parametric unlearning method by incorporating a contrastive objective to promote correct replacements by contrasting deprecated and valid API usages under the same context.

3.1 Problem Formulation↩︎

We formulate unlearning as a post-training procedure that aims to reduce the model’s tendency to generate deprecated APIs by modifying its parametric memory. Let \(\pi_{\theta}\) denote a language model parameterized by \(\theta\). We denote \(\mathcal{D}_{f} = \{x_i, y^{-}_i\}_{i=1}^{N}\) as the forgetting set, which consists of code samples associated with deprecated APIs. Each pair \((x_i, y_i^-)\) includes a prompt \(x_i\) and its corresponding undesirable completion \(y_i^-\), where \(y_i^-\) contains deprecated API usage. In this work, \(x_i\) serves as a probing snippet under the code completion setting, where the model is required to generate the continuation. The objective of unlearning is to update the model parameters from \(\theta\) to \(\theta^*\) such that the updated model \(\pi_{\theta^*}\) reduces the likelihood of generating undesirable outputs \(y_i^-\) given \(x_i\). This can be formulated as the following optimization problem: \[\theta^* = \text{arg}\min_{\theta} \sum\limits_{i=1}\limits^{N} \mathcal{L}_{unl}(\pi_{\theta}(x_i), y_i^{-}) \label{eq:unlearning-loss}\tag{1}\] where \(\mathcal{L}_{unl}\) denotes an unlearning loss that penalizes the model for generating undesirable outputs.

3.2 Unlearning Instantiations↩︎

The formulation in Equation 1 defines a general unlearning objective. In practice, different methods instantiate the unlearning loss \(\mathcal{L}_{unl}\) in different ways. In this work, we consider two representative gradient-based parametric unlearning approaches, SimNPO [17] and PROD [15], which have been shown effective in modifying model behavior at the sequence and token levels, respectively.

\(\triangleright\) Simple Negative Preference Optimization. SimNPO [17] is a sequence-level unlearning method that suppresses undesirable outputs through preference-based optimization. Given a forgetting sample \((x, y^-)\), where \(y^-\) includes deprecated API usage, SimNPO suppresses the conditional likelihood of the undesirable sequence while applying length normalization to avoid biasing the optimization toward longer responses. \[\mathcal{L}_{unl}^{\texttt{SimNPO}} = -\frac{2}{\beta} \log \sigma \left( -\frac{\beta}{|y^-|} \log \pi_{\theta}(y^-|x) \right) \label{eq:simnpo-loss}\tag{2}\] where \(\pi_{\theta}\) denotes the current model, \(|y^-|\) represents the length of the undesirable response, \(\beta\) is a scaling factor controlling the optimization strength, and \(\sigma(\cdot)\) denotes the sigmoid function. Intuitively, Eq. 2 incorporates length normalization via \(\frac{1}{|y^-|}\) to mitigate the tendency of longer responses to dominate the optimization through accumulated log-probabilities.

\(\triangleright\) Probabilistic Redistribution for Output Distribution. PROD [15] is a token-level method that suppresses undesirable snippet generations by directly modifying the target token distribution during training. Given a forgetting sample \((x, y^-)\), PROD minimizes the divergence between the current model distribution \(\pi_{\theta}\) and a modified target distribution \(p_{T}\). \[\mathcal{L}^{\texttt{PROD}}_{unl} = -\sum_{t=1}^{L} \sum_{w \in \mathcal{V}} p_T(w|x, y^-_{<t}) \log \pi_\theta(w|x, y^-_{<t}) \label{eq:prod-loss}\tag{3}\] where \(L\) denotes the sequence length, \(\mathcal{V}\) is the vocabulary space, \(p_T(\cdot)\) denotes the redistributed target distribution at decoding step \(t\), and \(\pi_\theta(\cdot)\) represents the probability assigned by the current model to token \(w\) given the context \(x\) and previously generated tokens \(y_{<t}\). Intuitively, the objective function suppresses the probabilities of deprecated API tokens while redistributing probability mass over the remaining vocabulary, thereby discouraging obsolete API usage in generated code.

3.3 Contrastive Unlearning for API Replacements↩︎

While the methods in Section 3.2 effectively suppress deprecated API usage, they do not explicitly guide the model toward correct replacements. To overcome this limitation, we propose a contrastive unlearning formulation that jointly suppress outdated APIs and promotes valid alternatives under the same context. For each forgetting sample \((x, y^-)\), we construct a corresponding positive sample \(y^+\) by applying API-level transformations based on updated documentation or curated mappings between deprecated APIs and their recommended replacements. This ensures that \((x, y^+)\) represents a desirable completion that preserves the original intent while using up-to-date APIs. Given a triplet \((x, y^-,y^+)\), we extend the unlearning objective by introducing a contrastive loss that enforces a relative preference for \(y^+\) over \(y^-\) as follows. \[\begin{align} \mathcal{L}_{ctr} &= -\log \sigma \Big( \frac{1}{|y^+|}\sum_t \log P(y^+_t \mid x, y^+_{<t}) \\ &\qquad\quad\quad - \frac{1}{|y^-|}\sum_t \log P(y^-_t \mid x, y^-_{<t}) \Big) \end{align} \label{eq:contrastive-loss}\tag{4}\] The overall objective is defined as in Equation 5 . \[\mathcal{L}_{\texttt{CURE}} = \mathcal{L}_{unl} + \lambda \mathcal{L}_{ctr} \label{eq:overall-loss}\tag{5}\] where \(\lambda\) controls the trade-off between suppressing deprecated APIs and promoting correct replacements, \(\mathcal{L}_{unl}\) is instantiated using either the SimNPO or PROD loss (Equations 2 , 3 ).

4 Experiment Settings↩︎

4.1 Research Questions↩︎

\(\triangleright\) RQ\(_1\): To what extent does CURE reduce the generation of deprecated APIs compared to baseline models?  We evaluate deprecated API suppression on both the forgetting and a disjoint test set to assess the effectiveness of the unlearning process and the model’s ability to generalize to unseen data.

\(\triangleright\) RQ\(_2\): How effectively does CURE promote correct API replacements compared to suppression-based unlearning approaches?  This RQ evaluate whether the model correctly adopts updated APIs to replace deprecated ones in code samples from both forgetting set and unseen test set.

\(\triangleright\) RQ\(_3\): How does CURE impact general code generation performance on standard benchmarks?  We evaluate the impact of CURE on the model’s general code generation capability using a widely-used benchmark, i.e., HumanEval [22], examining whether unlearning deprecated APIs degrades overall functional correctness and generation quality.

4.2 Dataset Construction↩︎

Following prior work, we adopt the deprecated API evaluation benchmark introduced by Wang et al. [7], which covers 8 Python libraries with 145 deprecated-to-updated API mappings. The benchmark consists of two datasets: (i) an outdated set containing 9,087 real-world code samples using deprecated APIs, and (ii) an up-to-date set containing 18,340 samples using the corresponding updated APIs. To avoid context leakage, we remove up-to-date samples sharing similar code contexts with those in the outdated set. The remaining 16,423 samples therefore reflect new and unseen contexts in which developers already adopt up-to-date APIs.

4.2.1 Forgetting Dataset↩︎

Unlike traditional machine unlearning settings, where the forget set is typically sampled from the original training corpus, we do not have access to the pretraining data of Code LLMs. Therefore, we construct the forget set \(\mathcal{D}_f\) directly from the outdated set of the benchmark proposed by Wang et al. [7], which contains real-world deprecated API usages collected from public GitHub repositories. This design enables the model to unlearn deprecated API usage patterns across diverse real-world contexts. In addition, we randomly sample a limited number of hard negative cases from the up-to-date set where the pre-unlearning model still generates deprecated APIs despite new API contexts. These samples are incorporated into the forget set to expose the model to challenging contexts where deprecated API usage persists despite the absence of outdated contextual cues.

4.2.2 Contrastive Dataset↩︎

To promote correct API replacement, we construct a contrastive dataset \(\mathcal{D}_{\text{ctr}}\) consisting of negative samples that contain deprecated API usages generated by the model. For outdated-context samples, the corresponding positive samples are generated using Gemini-2.5-Pro, rewriting the code with the correct replacement API while preserving the original intent and context. In addition, for the selected up-to-date contexts described earlier where the model still generates deprecated APIs, we directly use the corresponding ground-truth up-to-date code as positive examples.

4.2.3 Testing Dataset↩︎

The testing set consists of unseen code contexts used to evaluate the generalization capability of the model after unlearning. Specifically, we construct this set from the up-to-date dataset of the benchmark proposed by Wang et al. [7] after removing all samples involved in (\(\mathcal{D}_{f}\)). This setup enables us to assess whether the model can generalize replacement-oriented behavior to unseen contexts and correctly generate up-to-date API usages beyond the samples used during unlearning.

In this work, we evaluate four Code LLMs: DeepSeek-Coder-1.3B, StarCoder2-3B, CodeLlama-7B and CodeGen-2B. For each model, we construct the corresponding datasets \(\mathcal{D}_f\), \(\mathcal{D}_{\text{ctr}}\) and \(\mathcal{D}_{\text{test}}\). Table 1 presents the statistics of the constructed datasets in terms of the number of samples.

4.3 Evaluation Metrics↩︎

We evaluate unlearning effectiveness using three metrics: Deprecated API Usage Rate (DUR), Replacement API Usage Rate (RUR), and Mismatch API Usage Rate (MUR) [31], which respectively measure the proportion of outputs containing the target deprecated API, the corresponding replacement API, or neither of them. In particular, MUR captures cases where the model successfully avoids the deprecated API but fails to generate the intended valid replacement, instead producing a different API that does not correspond to the intended valid replacement. API usage is identified through alias-based regular-expression matching with word-boundary constraints to reduce false positives [7].

For RQ\(_3\), we evaluate the model’s general generation capability using Pass@k on the HumanEval benchmark [22]. Pass@k measures the probability that at least one out of \(k\) generated samples correctly solves a given task. Following prior work [32]–[34], we report results with \(k = 1,3,5\).

4.4 Implementation↩︎

All experiments were conducted on a single NVIDIA A100 GPU with 80GB VRAM. Input prompts were truncated to a maximum context length of 2,048 tokens, while generation outputs were limited to 128 tokens, which is sufficient for API transformation tasks without producing unnecessarily verbose code. We set \(\beta = 0.1\) for the SimNPO loss and \(\lambda = 1\) to control the contribution of the contrastive objective.

5 Results and Discussion↩︎

5.1 RQ\(_1\): To what extent does CURE reduce the generation of deprecated APIs compared to baseline models?↩︎

Note: The best-performing unlearning approach in each column is shown in bold, while the second-best result is underlined.

We measure three metrics DUR, RUR and MUR of all studied models on both \(\mathcal{D}_f\) and \(\mathcal{D}_{\text{test}}\) under three settings: (i) pre-unlearning, (ii) after applying traditional unlearning (i.e., PROD and SimNPO), and (iii) after applying the proposed contrastive unlearning (i.e., \(\texttt{CURE}_{\texttt{PROD}}\) and \(\texttt{CURE}_{\texttt{SimNPO}}\)). Evaluation on \(\mathcal{D}_f\) allows us to directly assess whether the unlearning process successfully suppresses deprecated API usage on the targeted forgetting samples, while evaluation on \(\mathcal{D}_{\text{test}}\) examines whether the learned behavior generalizes to up-to-date code contexts. As shown in Figs. 1 and 2, the proportion of deprecated API usages (orange bars) consistently decreases across all unlearning methods on both \(\mathcal{D}_f\) and \(\mathcal{D}_{\text{test}}\) compared to the original pre-unlearning models, confirming the effectiveness of parametric unlearning in mitigating outdated API behaviors.

On \(\mathcal{D}_f\), the models exhibit high DUR, ranging from 22.7% to 63.0%. Both PROD and SimNPO substantially suppress deprecated API usage, with PROD consistently outperforming SimNPO, e.g., PROD achieves up to a 96.8% relative DUR reduction, whereas SimNPO gets at most 73.1% on CodeGen-2B, suggesting that token-level probability redistribution is more effective than sequence-level suppression. Furthermore, incorporating the proposed contrastive objective further improves deprecated API suppression across most settings. For example, compared to PROD, \(\texttt{CURE}_{\texttt{PROD}}\) reduces DUR from 11.7% to 4.2% on StarCoder2-3B. Similar improvements are observed for \(\texttt{CURE}_{\texttt{SimNPO}}\), indicating that explicitly contrasting deprecated APIs with valid alternatives enhances forgetting effectiveness. On \(\mathcal{D}_{\text{test}}\), the original models already show relatively low DUR prior to unlearning, ranging from 4.9% to 10.8%, indicating that deprecated APIs are less frequently activated in up-to-date contexts. Nevertheless, all unlearning methods consistently maintain lower DUR than the original models, demonstrating that the suppression effect generalizes beyond the forgetting samples.

5.2 RQ\(_2\): How effectively does CURE promote correct API replacements compared to suppression-based unlearning approaches?↩︎

On \(\mathcal{D}_f\), suppression-oriented unlearning methods, including PROD and SimNPO, consistently reduce deprecated API usage (DUR). However, though these methods partially improve replacement API usage (RUR), they also increase mismatch generations (MUR). For example, on StarCoder2-3B, PROD reduces DUR from 57.4% to 11.7% and increases RUR from 7.2% to 18.6%, but simultaneously raises MUR from 35.4% to 69.7%. Similar trends are observed across other models and unlearning methods, suggesting that suppression-oriented unlearning mainly teaches the model to avoid deprecated APIs, but remains less effective at guiding the model toward semantically correct replacement APIs. In contrast, incorporating the contrastive unlearning objective improves RUR while reducing MUR across all evaluated models. For instance, compared to PROD, \(\texttt{CURE}_{\texttt{PROD}}\) improves RUR from 18.6% to 51.6% on StarCoder2-3B, and 11.9% to 37.6% on CodeGen-2B. Similar improvements are also observed when comparing SimNPO with \(\texttt{CURE}_{\texttt{SimNPO}}\), indicating that contrastive unlearning not only reduces deprecated APIs, but also better guides the model toward generating correct replacement APIs under the same context.

On \(\mathcal{D}_{\text{test}}\), the original models already exhibit low deprecated API usage, suggesting that Code LLMs can partially adapt to new contexts and naturally prefer more up-to-date APIs. Nevertheless, all unlearning methods reduce deprecated API generation while improving correct replacement API usage. Incorporating the proposed contrastive objective consistently yields larger RUR and lower mismatch generations compared to suppression-based methods. For example, on StarCoder2-3B, PROD achieves a relative RUR improvement of 30.4% over the original model, while \(\texttt{CURE}_{\texttt{PROD}}\) further increases it to 40.3%. Similarly, on CodeLlama-7B, SimNPO achieves a 55.8% relative RUR improvement, whereas \(\texttt{CURE}_{\texttt{SimNPO}}\) reaches 70.5%.

5.3 RQ\(_3\): How does CURE impact general code generation performance on standard benchmarks?↩︎

We evaluate the impact of unlearning on HumanEval [22]. Table 2 reports the \(Pass@1\), \(Pass@3\), and \(Pass@5\) results across four studied models under pre- and post-unlearning settings. Overall, all unlearning approaches introduce only minor degradation on HumanEval. For example, on DeepSeek-Coder-1.3B, PROD and SimNPO retain 95.2% and 94.5% of the original performance on average, while \(\texttt{CURE}_{\texttt{PROD}}\) and \(\texttt{CURE}_{\texttt{SimNPO}}\) achieve even stronger preservation rates of 101.1% and 97.1%, respectively. This trend remains consistent across the other models, where the best and second-best results are predominantly achieved by the CURE variants.

6 Threats to Validity↩︎

Construct Validity. Our evaluation relies on alias-aware regular-expression matching to identify deprecated and replacement API usages. Though complex generation patterns or implicit API wrappers may introduce minor matching inaccuracies, we mitigate this threat by leveraging benchmark-provided API alias mappings together with word-boundary constraints. Moreover, positive samples in the contrastive dataset are partially generated using Gemini-2.5-Pro, which may introduce generation bias or imperfect transformations. To mitigate this threat, we constrain the generation process to preserve the original code intent and only replace the target APIs while keeping surrounding contexts unchanged.

Internal Validity. A potential threat arises from augmenting the forget set with hard negative cases sampled from up-to-date contexts where the baseline model still generates deprecated APIs. It is possible to argue that such samples implicitly expose the model to modern API usages rather than purely removing outdated knowledge. To reduce this threat, we only incorporate a limited number of randomly sampled hard negatives and use them as robustness-oriented failure cases instead of direct replacement supervision.

7 Conclusion↩︎

In this paper, we presented CURE, a contrastive unlearning approach for mitigating deprecated API usage in Code LLMs. Unlike conventional unlearning methods that primarily suppress undesirable knowledge, CURE explicitly promotes valid API replacements through a contrastive objective that distinguishes deprecated APIs from their correct alternatives. Initial experimental results show that CURE effectively reduces deprecated API generation while improving replacement adoption across multiple Code LLMs. Moreover, evaluation on HumanEval indicates that the proposed approach preserves general code generation capability with only minor degradation. These early findings suggest that combining suppression and replacement-aware learning is a promising direction for adapting Code LLMs to evolving software ecosystems.

Acknowledgment↩︎

This paper has been partially supported by the MOSAICO project (Management, Orchestration and Supervision of AI-agent COmmunities for reliable AI in software engineering) that has received funding from the European Union under the Horizon Research and Innovation Action (Grant Agreement No. 101189664).

References↩︎