← Practice · October 22, 2026
How an AI agent found an old BIOS, unnecessary background load and DNS delays, corrected its own mistakes and configured a PC while the owner replied from a phone.
12 min readcomputer

Windows 11 optimization often starts with deleting temporary files. That frees up space, but the processor stays busy, websites take a moment to open, and the computer unexpectedly goes to sleep. In our case, a complaint that “the system is sluggish” led us to unnecessary background processes, DNS delays and an old BIOS. We emptied the Recycle Bin, but the engineering work had only just begun.
The work was carried out by the Claude Code AI agent under the supervision of the owner of IKORG studio. The computer’s owner provided access and communicated with the assistant through a messaging app on a phone: reading short reports and replying “yes,” “no” or with item numbers. The agent handled most checks and changes independently. A person flashed the BIOS and performed several actions at the PC.
We’ll go through what we measured, what we fixed and where the assistant itself went wrong. The full story is in our case study on optimizing a computer with AI, while removing large files and unnecessary programs is covered in our article on cleaning up the C drive.
The configuration was perfectly adequate for gaming and everyday work: Windows 11 Pro, a 13th/14th-generation Intel processor, an ASRock B760M motherboard, 32 GB of RAM, an NVIDIA graphics card and Wi-Fi 6E. The owner complained about a lack of space and general sluggishness.
We had to investigate those problems separately. Deleting an unnecessary installer frees up space, but a service that constantly restarts keeps running, network names still resolve slowly, and the processor microcode stays the same. After taking an inventory of files, the assistant checked startup entries, services, scheduled tasks, drivers and Windows logs.
CPU usage at idle was 16–20%. Nothing much was open, yet the computer apparently had a busy working day of its own. The checks identified specific resource consumers. We also found settings that needed attention regardless of how quickly windows opened.
We worked through each issue in order: find the cause, assess the consequences of a change, get approval, make the change and verify it. Removing programs required a separate “yes.” Before editing the registry, we exported the affected branches.
The main finding was a BIOS from 2022. The system still lacked the necessary fix for the degradation issue affecting 13th/14th-generation Intel processors. During the checks and update, we recorded a microcode change from 0x12B to 0x133.
Disk cleanup simply does not reach that kind of risk. There were fewer archives and fewer startup entries, but the firmware remained unchanged. That is why we checked the BIOS separately.
Microcode provides low-level fixes to processor behavior. The BIOS handles hardware initialization and configuration, and its updates may include those fixes. To determine whether a new version is needed, we check it against the specific motherboard and installed processor.
The assistant found the problem and prepared instructions. The decision to flash the BIOS and the flashing itself remained with the person. After the update, we checked the result and returned to memory parameters and other motherboard settings. This part of the work addressed the condition of the hardware; impressive benchmark numbers would have been a separate task.
In this case, we updated the BIOS from version 1.08 to 14.02 using the built-in Instant Flash utility. The owner flashed it directly at the computer, while the assistant helped explain the procedure. This stage required human involvement.
Start by identifying the exact motherboard model and the correct firmware. Then follow the manufacturer’s instructions: prepare the file, open the built-in utility and perform the update. Power must not be interrupted while the firmware is being written.
Matching the manufacturer or motherboard family is not enough: the firmware must be compatible with the specific hardware. The versions listed here describe this computer’s history; they should not be used to choose firmware for your own PC.
After the update, check settings that may have reset. Here, we focused on memory, ReBAR and ASRock’s automatic driver installation. A successful Windows boot is a reason to continue checking: the required settings may not have been preserved.
The owner performed the action at the PC, while the assistant handled finding the problem, explaining the procedure and checking the result.
The RAM was running at 4800 instead of its rated 5200. The computer booted and completed tasks, so the difference could easily have gone unnoticed without a check.
XMP is a memory settings profile stored on the modules. It applies the parameters specified for the kit without requiring you to select each value manually. But even with suitable modules, the profile needs checking: it may be disabled.
The procedure is:
Section names depend on the motherboard and BIOS version, so follow the interface on the specific machine. If problems appear after the change, review the setting. Ticking the box does not finish the job.
On this PC, the memory started running at 5200. We also enabled ReBAR, a mechanism that lets the processor access larger regions of video memory. We did not take separate gaming measurements before and after, so we do not attribute a specific frame rate increase to these changes.
ASRock Auto Driver Installer handles driver installation after Windows is installed, and it is enabled in the BIOS. This means the program can reappear the next time the operating system is installed, even if it was removed before. With some programs, saying goodbye comes with a sequel.
On this computer, two processes belonging to the component were constantly using roughly one and a half CPU cores. The measured load was the reason for intervening. The assistant removed the component and gave the owner instructions for disabling Auto Driver Installer in the BIOS.
To do this, open the motherboard settings, find the corresponding option and disable it. Its location depends on the BIOS version. The firmware setting needs a separate check: uninstalling the program from Windows does not change it.
The diagnosis therefore covered both levels: the CPU load was visible in Windows, the installation source was in the BIOS, and the fix involved both places.
The assistant checked for updates through Windows Update. We updated the Intel Wi-Fi and Bluetooth drivers, along with the NVIDIA graphics driver. The others were already up to date.
Downloading the graphics driver from the official website was problematic, so we used a server to help with the download. The difficulty was obtaining the file; the source remained official.
We removed Driver Booster at the owner’s request. We did not use driver packs: we checked the hardware and the state of the installed drivers, then updated what needed updating.
Driver maintenance and finding the cause of slowdowns are separate tasks. A newer version alone does not explain every delay. Here, slow website opening required investigating DNS, while idle CPU load required checking background programs. Updating drivers was one part of the overall work, with its own specific purpose.
ASRock Launcher, six instances of NVIDIA Broadcast and nine Edge processes were running in the background. Alongside them were a crashing VPN client service and Firefox, which was not being used at the time. Yandex Disk kept one core at 100% for hours.
A process list alone is not enough reason to remove programs. Multiple browser processes can be a normal part of operation. You need to examine the load and find out whether the owner needs the background function.
The assistant reduced unnecessary automatic launches, including Gemini, Logi, AIDA64, IObit tasks and OneDrive for a second account. We removed Yandex Disk from startup: the owner launches it manually when synchronization is needed. The program remained available; only when it starts changed.
After the combined changes, idle CPU usage dropped from 16–20% to 3–5%. That is the overall measured result of the background process changes; these data cannot isolate the contribution of a single service or setting.
The assistant made a mistake with Edge: ending its background processes probably interrupted a WebView2 update. We had to fix the consequences separately. A seemingly unnecessary process turned out to be a possible part of another application’s maintenance.
In this case, we disabled DiagTrack, CEIP tasks and the advertising ID. These names refer to different mechanisms: a diagnostic service, tasks for the Customer Experience Improvement Program and an identifier used to personalize advertising.
They are also managed separately: the advertising ID in Windows privacy settings, the service through service management, and the tasks through Task Scheduler. Before changing anything, it is worth understanding what each item does.
These actions were part of the overall configuration work. We did not measure telemetry load separately, so the final 3–5% applies to the full set of changes.
We also restored some system functions. We enabled SysMain and configured Windows Search with exclusions for cloud folders. We kept search on the computer available.
Disabling everything unfamiliar is a tempting way to shorten the services list, but any benefit needs checking. Here, we based decisions on the owner’s needs and the problems we found.
After we changed the power plan, the owner noticed that the computer seemed to shut down. The event log showed three transitions to sleep. No actual shutdown occurred in those episodes.
The assistant had introduced the cause: it enabled the Balanced plan but missed the sleep timer set to 15 minutes of inactivity. That setting was unsuitable for a PC being worked on remotely. The computer diligently followed its rest schedule—it just had not agreed on it with the owner.
We found the cause in the log and corrected the settings. We kept the Balanced plan itself and changed the timer. This case is a useful reminder to check the associated settings whenever changing a power plan.
If a PC unexpectedly stops responding, first establish what happened: sleep, restart or shutdown. From the outside, these events can look the same. The log helped us identify the specific cause and helped the assistant check the consequences of its action, acknowledge the mistake and correct it.
Game DVR is related to recording gameplay. On this computer, we disabled Xbox background recording. If you do not need it, you can check its settings in the Windows section for gaming and captures.
Focus specifically on background recording: the Game Bar and continuous recording of what is happening are separate functions. Choose the setting based on how the person uses the PC.
We also enabled HAGS—hardware-accelerated GPU scheduling—and optimizations for windowed games. The changes are documented, but we have no separate comparative gaming tests. We cannot promise a specific performance increase from them.
We deliberately skipped popular “gaming” TCP registry tweaks: in this work, we assessed them as myths without sufficient grounds for intervention. We looked for the actual network delay using logs and measurements.
The criterion is simple: what problem does the setting solve, and how can we check the result? A longer list of changes does not add performance by itself.
Ping can be normal while a website still takes a moment to open. Before connecting by name, the computer needs to obtain the website’s address. Here, the delay occurred at exactly that stage: resolving a new name took 0.4–0.6 seconds.
The DNS client log helped us find the causes. We found old entries in hosts: the file contained 553 lines and was slowing down the network. Queries to the router over IPv6, which was not used in this configuration, also added delays.
Measuring ping again was not enough: it checked a different part of the path. We needed a separate measurement of the time taken to process a new name.
We removed the old hosts entries from the name resolution process. We used Yandex and Cloudflare for DNS. We disabled IPv6 on the Wi-Fi adapter because the ISP did not provide global IPv6 connectivity.
After the changes, processing a new name took 17–115 ms instead of 400–600 ms. This was specifically a DNS improvement in this configuration. Page loading time also depends on the connection, the website’s response and downloading its content.
The setting is in the properties of the network adapter in use: you can disable the IPv6 protocol component there and apply the change. In this case, we changed the Wi-Fi properties.
The grounds for doing so were the DNS client logs and the ISP’s lack of global IPv6 connectivity. Before taking this step, find out whether the protocol is used on the network and whether it is related to the delay. One slow-loading website is not enough to make the decision.
IPv6 may be needed on another network, so this change should not become a universal recommendation.
We made several network changes here: working on hosts, choosing DNS servers and disabling IPv6 on the adapter. The final 17–115 ms is their combined result. We did not measure each action’s contribution separately.
The changes served different purposes. Some reduced measured delays or load; others corrected hardware settings or removed a risk. It therefore makes more sense to look at the results separately.
| Change or claim | What the case showed |
|---|---|
| Reduce unnecessary background activity | Idle CPU usage dropped from 16–20% to 3–5% after the combined changes |
| Investigate DNS and hosts | New names were processed in 17–115 ms instead of 400–600 ms |
| Check the BIOS and microcode | A necessary update was identified and installed |
| Enable XMP | Memory went from 4800 to its rated 5200 |
| Fix the sleep timer | Unwanted sleep after 15 minutes was eliminated |
| Free up space and call it a speed increase | Free space and operating speed are different outcomes |
| Apply gaming TCP tweaks | Assessed as myths; no changes were made |
| Promise an FPS increase from HAGS and ReBAR | No basis for this: no separate gaming measurements were taken |
The WebView2 mistake had the most noticeable effect on applications. After the Edge background processes were terminated, the runtime version folder was left empty, and one application stopped opening in its own window. An interrupted update remained a likely explanation, a hypothesis. We restored operation by reinstalling the runtime after first exporting the affected registry entries.
The assistant also made diagnostic mistakes. A registry scanner mistook paths containing spaces for broken references. We checked the results manually and did not delete anything unnecessarily. We initially suspected Punto Switcher was causing the MAX messenger to crash. Tests did not support that assumption, so we restored the program. We found the cause in temporary path handling; after we changed TEMP/TMP, the owner confirmed the fix.
When the VPN was enabled on the PC, remote access dropped, so the owner turned the VPN off while we worked. The assistant also introduced the sleep timer error itself and corrected it using the event log.
The person decided what to remove, flashed the BIOS, restarted the PC and closed programs that were holding files open. The owner also manually removed 360 Total Security: the program had taken over the antivirus role, and Windows Defender was disabled. The assistant removed the leftovers and restored protection.
We left decisions about personal archives to the owner: 37 GB of duplicates were kept pending a decision. In total, the work required about ten replies from a phone over a day and several actions at the computer. The model saw the inventory, program lists and logs, but not the contents of documents. Access remained under the owner’s control.
It depends on the hardware and firmware. Here, the update was needed to address the Intel processor issue. Cleaning up Windows did not solve that problem.
In this case, we confirmed that memory went from 4800 to 5200. We did not separately measure gains in applications or games.
We disabled specific components here, but we did not measure their individual contribution. We assessed the reduction in load after the combined changes to background activity.
Ping and name resolution test different processes. Here, obtaining the address of a new website was delayed, so we investigated the DNS client.
We completed most of the work remotely. Flashing the BIOS, restarting, removing a particular program and some actions involving open files remained with the owner.
At IKORG, we can check a computer beyond routine cleanup: BIOS and memory, drivers, background load, power, sleep and network delays. The work is carried out by the Claude Code AI agent under the studio owner’s supervision. We first establish the system’s condition, then propose changes and agree on actions affecting programs and data.
You do not have to work through Windows logs and study every service yourself. You can receive clear reports in a messaging app on your phone and make decisions with short replies. To find out what is keeping your PC from working properly, contact us.