Joshua Palti Sinaga

Make Your Windows 10 Feel Fresh Again

Wed, 16 Sep 2026 00:00:00 GMT

My Windows 10 computer had started feeling tired. Not dramatically broken, just slow in the annoying way that makes every small ta~sk feel like a negotiation.

I noticed it while working on a project using Oh My Pi and Orca. Oh My Pi kept lagging and eventually crashed. Since blaming the computer is easier than blaming my code, I opened Task Manager to investigate.

One process immediately caught my attention: Service Host: Network Service. It was using around 30-50% of my CPU.

Because this is an internal Windows process, my first thought was, "Great, is this a virus now?" It might have been a problem with another program using the service, or it might have been something else entirely. I did not know yet, but the symptoms kept piling up.

Apps started lagging, running out of memory, or crashing. Even Discord became unreliable while I was sharing my screen with a friend and talking about vibe UI/UX. A crash in the middle of a design discussion is a very effective way to make the design less fun.

That was my sign to clean up Windows. I realized I had not done a proper cleanup in roughly one or two years, so I decided to give the system a deep-cleaning session.

Step 1: Scan for malware

First, I ran antivirus tools. Please do not use cracked antivirus software. It is a little difficult to improve your computer's security by installing a mystery program from a suspicious website.

Free tools are fine if you choose reputable ones. I used Avast Free together with Malwarebytes Free, then ran file scans. They found several suspicious files and quarantined them.

Before permanently deleting quarantined files, review what was found. Antivirus tools can sometimes flag a clean and familiar program by mistake. Do not restore something obviously suspicious, but do make sure you understand what you are removing. Once you're done, you can keep the antivirus programs installed or uninstall them. I prefer uninstalling them afterward.

Step 2: Repair Windows system files

Next, I used Windows' built-in repair tools. These check different parts of the operating system and can fix damaged files.

Open Command Prompt or PowerShell as an administrator, then run these commands one at a time.

Check protected system files with SFC

System File Checker, or SFC, checks protected Windows files and replaces damaged or missing versions with correct copies.

sfc /scannow

Repair the Windows image with DISM

DISM stands for Deployment Image Servicing and Management. It repairs the Windows system image, which is the source Windows uses for system files. It can help when SFC cannot finish the repair on its own.

dism /online /cleanup-image /restorehealth

Check the drive with CHKDSK

CHKDSK checks the file system on your hard drive or SSD. The /f option fixes logical errors, while /r looks for bad sectors and tries to recover readable data.

chkdsk /f /r

This last command can take a long time, especially on a large or older drive. Windows may ask to schedule the scan for the next restart, so save your work first.

Step 3: Remove unnecessary files

For the cleanup itself, I used BleachBit, a free and open-source tool for removing cache files, logs, and other digital leftovers.

I mainly used it to clean cached files and logs. I expected that to free some space, but I did not think it would make such a big difference. It freed around 8 GB from my system drive. Not bad for cleaning up what looked like simple leftovers.

Step 4: Review Windows settings carefully

The Chris Titus Windows Utility should already be familiar to many people in IT, haha. It is a popular tool for fine-tuning Windows from one place. I used it to disable a few Windows 10 features I did not need, including Windows Update, Windows Defender, and some others.

Open the Tweaks tab, choose the Standard preset, and click Run Tweaks. Here are the tweaks I used:

The utility also includes update-related settings:

For my setup, I always disable Windows Update when it keeps consuming too many resources or repeatedly causes new crashes. Turning updates off made the system feel much more stable. Just remember that you will need to manage updates manually later, especially security updates.

The result

After the cleanup, my computer felt much more responsive. Coding became enjoyable again, applications stopped crashing, and Discord went from barely opening to working normally. Don't ask me why Discord suddenly recovered. Maybe it was the cleanup, maybe it was a combination of repairs, or maybe Discord simply decided to forgive me. Let's just call it a small Discord miracle. Either way, I was happy to stop troubleshooting and get back to work.

Here is the result after the cleanup:

CPU usage and the other resource numbers look much more normal, even with several applications running.

This is not a guaranteed cure for every Windows problem, but it gave my aging installation a fresh start. If you have another Windows cleanup trick that works for you, feel free to share it.

Setting Up Claude Code with a Custom Provider

Sat, 08 Aug 2026 00:00:00 GMT

Claude Code is a handy coding agent that runs right in your terminal. By default it uses Anthropic models through Anthropic's own API, but you can point it at a custom provider like 9router for more model options, often at a lower cost. I covered 9router in detail in this guide, and the whole setup here is just a few lines in one JSON file.

Quick setup

In a hurry? Replace the credentials below and copy this prompt to your coding agent in the terminal:

Configure Claude Code custom provider in `settings.json`.

Detect the OS and use:
* Windows: `%USERPROFILE%\.claude\settings.json`
* Linux/WSL/macOS: `~/.claude/settings.json`

Create or update the file, preserving existing settings. Add/replace `env` with:

{
  "ANTHROPIC_API_KEY": "<API_KEY>",
  "ANTHROPIC_BASE_URL": "<BASE_URL>",
  "ANTHROPIC_DEFAULT_OPUS_MODEL": "<MODEL>",
  "ANTHROPIC_DEFAULT_SONNET_MODEL": "<MODEL>",
  "ANTHROPIC_DEFAULT_HAIKU_MODEL": "<MODEL>"
}

Ask for missing API key, base URL, or model. Keep valid JSON and do not expose the full API key.

Step 1: Install Claude Code

If you do not have Claude Code yet, install it first.

macOS and Linux: open your terminal and run:

curl -fsSL https://claude.ai/install.sh | bash

Windows (PowerShell): run:

irm https://claude.ai/install.ps1 | iex

Alternative on macOS with Homebrew:

brew install --cask claude-code

Step 2: Configure the Custom Provider

Claude Code reads its settings from a settings.json file. The location depends on your OS:

Windows: C:\Users\<YourUsername>\.claude\settings.json (resolves from %USERPROFILE%\.claude\settings.json)
Linux / WSL: ~/.claude/settings.json (resolves to /home/<username>/.claude/settings.json)
macOS: ~/.claude/settings.json (resolves to /Users/<username>/.claude/settings.json)

Open the file and add your custom provider configuration inside the env block. For example, with 9router it looks like this:

{
  "env": {
    "ANTHROPIC_API_KEY": "YOUR_CUSTOM_PROVIDER_API_KEY",
    "ANTHROPIC_BASE_URL": "http://localhost:20218/v1",
    "ANTHROPIC_DEFAULT_OPUS_MODEL": "provider-name/model-name",
    "ANTHROPIC_DEFAULT_SONNET_MODEL": "provider-name/model-name",
    "ANTHROPIC_DEFAULT_HAIKU_MODEL": "provider-name/model-name"
  }
}

The env block sets environment variables for Claude Code. ANTHROPIC_BASE_URL points to your provider's endpoint, and the model variables pick which model each Claude Code tier uses.

Fun fact: the hardest part of this step is usually remembering where you put the comma 🫪

Step 3: Verify the Configuration

Save the file and start Claude Code from your terminal:

claude

You will be asked to confirm that you want to use your custom API key. Select yes:

Then check the header: it should show your selected custom model. Try sending a message to confirm everything responds correctly.

And you are good to go. Claude Code now runs with your custom provider.

Setting Up 9router in Pi.dev

Sat, 02 May 2026 00:00:00 GMT

A clean agentic developer workflow is much nicer when model routing stays in one place. Pi.dev already works well from the terminal, and 9router can add a local routing layer for choosing which models power each session.

9router has become popular because it makes model switching feel simple. It can sit between your tools and different LLM providers, expose an OpenAI-compatible endpoint, and keep routing rules in one local dashboard. That is helpful when testing many models, comparing responses, or keeping a coding agent setup flexible without changing every app config.

This guide walks through connecting 9router to Pi.dev with the better-custom package. After setup, Pi.dev can use models from a local 9router provider without needing a separate config for every model.

This walkthrough follows the flow from my Instagram Post, with a bit more context for each screen.

What this setup does

The goal is simple: connect Pi.dev to a local 9router endpoint using an OpenAI-compatible provider.

For this setup, you need:

Pi.dev
9router
the better-custom Pi package
a local 9router API endpoint
a 9router API key

Once everything is connected, Pi.dev can see the models exposed by 9router and use them like any other provider.

Step 1: Find the better-custom package

Open the Pi.dev website and go to the Packages section.

Search for better-custom. This package adds custom provider support to Pi.dev, which is useful for connecting OpenAI-compatible endpoints like the local endpoint from 9router.

Step 2: Install the package

After finding the package, install it from the terminal:

pi install npm:better-custom

This adds the extension to Pi.dev so it can be opened from inside the terminal UI.

Step 3: Start 9router and copy the endpoint

Open another terminal tab and start 9router.

Select the Web UI option so the local 9router dashboard can be opened in the browser.

In the 9router dashboard, copy the API endpoint. For a local setup, this usually points to a localhost address.

Keep this endpoint nearby. Pi.dev will ask for it in the next step.

Step 4: Add 9router as a provider in Pi.dev

Start Pi.dev from the terminal:

pi

Inside Pi.dev, open the better-custom extension and choose the option to add a new provider.

For provider type, select OpenAI-compatible.

After that, Pi.dev asks for the API endpoint. Paste the endpoint from the 9router dashboard, then continue to the next prompt.

This part creates the main connection: Pi.dev sends OpenAI-style requests, and 9router handles routing those requests to the models behind it.

Step 5: Add the API key

After the endpoint is set, Pi.dev asks for an API key.

Go back to the 9router Web UI and generate a new API key.

Then paste the API key into Pi.dev.

Name the provider 9router-local so it is easy to recognize later. This small naming detail helps when testing multiple providers or switching models during a session.

Step 6: Select models and test it

For the last step, choose which models Pi.dev should use through 9router.

In the model selection screen, look for the provider name created earlier: 9router-local. Under that provider, select the models that should be available in Pi.dev. You do not need to expose every model at once. Keep only the models that make sense for your coding workflow.

After saving the provider and model selection, run the models command in Pi.dev to make sure the new 9router models show up. Then pick one model from 9router-local and send a quick greeting to confirm it responds correctly.

That is the whole setup. Simple, but satisfying.

Why this setup is useful

This setup keeps model routing flexible without making the terminal workflow messy.

You can stay inside Pi.dev, switch between models exposed by 9router, and keep a local routing layer in control. It is especially useful when testing different models with the same prompt or changing providers during a coding session.

Not a huge setup, not a dramatic life-changing thing. Just one of those small workflow improvements that makes the whole day feel a little smoother.

pi.dev, OpenCode, and Codex Desktop Clock Benchmark

Fri, 01 May 2026 00:00:00 GMT

Testing Prompt to the Agent

"Create a single-page web application using HTML5, CSS3, and Vanilla JavaScript that simulates an analog wall clock within a minimalist 3D-styled room. The room should be constructed using CSS perspective and gradients to provide a sense of depth, including both walls and floor elements. The wall clock must be circular with a modern skeuomorphic design, featuring subtle shadows and realistic material textures. Use Arabic numerals (1-12) styled with the 'Inter' font from Google Fonts for a professional and clean aesthetic.

Include an interactive light switch in the room that dynamically adjusts the ambient lighting and shadows when toggled. Implement an automatic theme system where the room transitions into a dark mode if the local time is between 6:00 PM and 6:00 AM, and switches back to light mode otherwise. For the clock animation, ensure the second hand moves in a continuous, smooth sweep using requestAnimationFrame rather than jumping stiffly every second.

Add a separate control panel containing sliders for manually adjusting the hours, minutes, and seconds. Once a user interacts with these sliders, the clock should enter a manual mode where time continues to progress forward from the user-defined point. Provide a synchronization button that allows the user to instantly reset the clock to match the current system time.

When writing the code, do not include any comments or error-checking and validation logic unless strictly necessary for core functionality. Use highly descriptive and meaningful variable names to ensure the code remains readable and self-explanatory. Maintain a clean, modular, and well-organized code structure, providing the HTML, CSS, and JavaScript as a complete, ready-to-run output."

3 Agents, 1 Model, 1 Prompt

I tested how GPT 5.5 Thinking High behaves across different AI coding agent harnesses using the exact same high-detail UI/UX request.

The challenge was simple in idea, but pretty demanding in execution: build a complete 3D Wall Clock web app with HTML5, CSS3, and vanilla JavaScript. It needed a 3D-styled room, skeuomorphic clock design, smooth second-hand animation, automatic theme switching, an interactive light switch, manual time controls, and a sync button.

Repository for the benchmark project: github.com/jo0707/llm-clock-benchmark

The three tools I compared:

pi.dev
OpenCode
Codex Desktop

Same model. Same prompt. Same goal.

But the results? Surprisingly different.

Result Summary

Rank	Platform	Duration	Highlight
🥇	pi.dev	2:20	Winner for speed
🥈	OpenCode	2:50	Winner for UI/design
🥉	Codex Desktop	3:53	Encountered a lamp-switch bug

The biggest surprise for me was pi.dev. It finished in only 2 minutes and 20 seconds, while still producing a result that was in the same overall range as the others.

That is fast. Like, “wait, did it already finish?” fast. 😄

Test 1: pi.dev — Winner for Speed

pi.dev completed the task in 2:20.

This was the result that surprised me the most. The prompt was not tiny. It asked for visual depth, room perspective, clock animation, theme logic, lighting controls, manual sliders, and clean code structure.

Yet pi.dev moved through it very quickly. The result was not just fast for the sake of being fast either. It still reached the expected direction and delivered a usable implementation.

The best way I can describe it: pi.dev felt like it skipped the warm-up lap and immediately started sprinting.

For workflows where speed matters, like quick prototyping, repeated UI experiments, or rapid iteration, this kind of response time feels really nice.

Test 2: OpenCode — Winner for UI/Design

OpenCode finished in 2:50.

This was still very quick, only 30 seconds slower than pi.dev. But what stood out here was the extra design personality.

OpenCode went the extra mile with the “Quiet Room Timepiece” branding, which made the result feel more polished and intentional. It was not only trying to satisfy the prompt mechanically; it added a little product-like feeling to the final page.

So while pi.dev won the stopwatch, OpenCode gave me the strongest UI/design impression in this run.

If your workflow cares more about visual direction, naming, and presentation polish, OpenCode might feel very comfortable.

Test 3: Codex Desktop — Slower, and a Bug Appeared

Codex Desktop completed the task in 3:53.

The generated page was still useful, but this run had two drawbacks:

It was the slowest result in this comparison.
The lamp/light switch feature had a bug and could not be switched properly.

That second point matters because the interactive light switch was one of the explicit requirements in the prompt. So even though Codex Desktop produced a working-looking page overall, it missed an important interaction detail.

Compared with pi.dev, Codex Desktop took 1 minute and 33 seconds longer, and still needed extra fixing afterward.

What I Learned

This small test made the differences between agent harnesses feel very real.

Using the same model does not automatically mean the same experience. The surrounding coding agent interface, execution flow, editing behavior, and tool handling can change how fast and polished the final result feels.

My quick takeaway:

Choose pi.dev if you want speed and fast execution.
Choose OpenCode if you care more about UI/design flavor and polished presentation.
Choose Codex Desktop if it fits your workflow, but be ready to inspect interactive features more carefully.

Final Thoughts

This is not a scientific benchmark, and I would not treat it like a universal ranking forever. Different prompts, machines, versions, and project contexts can absolutely change the result.

But for this specific 3D Wall Clock challenge:

🥇 pi.dev: 2m 20s — winner for speed
🥈 OpenCode: 2m 50s — winner for UI/design
🥉 Codex Desktop: 3m 53s — encountered bugs

The most surprising moment was still pi.dev finishing so quickly while producing a comparable final result. That kind of speed can make an AI coding tool feel less like a waiting game and more like a real pair-programming partner.

Which one fits your workflow better? 🛠️

Improve IoT Development Speed by Switching Arduino IDE to PlatformIO IDE

Sun, 07 Sep 2025 00:00:00 GMT

Improve IoT Development Speed by Switching Arduino IDE to PlatformIO IDE

Yesterday, my team and I were tasked with creating an embedded system project to solve a real-world problem. We came up with the idea to build a system that can detect early signs of a landslide and warn people in nearby areas to evacuate.

Our system uses ESP32 as the main microcontroller, Firebase for real-time data storage, Telegram to send alert notifications, Next.js for the web dashboard, and Python for backend data logging.

1. Arduino IDE & PlatformIO IDE

According to the official Arduino documentation, the Arduino IDE is a development environment that includes a code editor, a message area, a text console, a toolbar with common function buttons, and a menu bar. It connects to Arduino hardware to upload programs and communicate with them. Although it is designed for Arduino boards, the IDE also supports other board types and manufacturers.

As an alternative, PlatformIO is a professional, cross-platform, multi-architecture development tool for embedded systems engineers and software developers who build applications for embedded products. PlatformIO is integrated into Visual Studio Code, allowing developers to work within a powerful modern code editor while developing embedded system projects. This results in a smoother and more efficient experience, especially for larger projects.

2. The Problem

In the early stages of development, we used the Arduino IDE for building the IoT system. It worked well at first, with no major issues.

However, once we added the Firebase library (mobizt/Firebase ESP32 Client) and the Telegram library (witnessmenow/UniversalTelegramBot) to our ESP32 project, things changed. The compile time in the Arduino IDE shot up to around 4 minutes for every code change.

That means if we make just 10 small adjustments, we spend about 40+ minutes just waiting for compilation! without even knowing if the build will succeed.

On top of that, the Arduino IDE doesn’t utilize all CPU cores for compiling. On my machine, which has 12 cores, it only uses 2. That’s frustrating, right? Next, we will see the problem in more detailed explanation.

3. Measuring Compile Performance

We will use this sample code to measure each IDE compile time and resource usage: Source Code (GitHub Gist)

Platform: Arduino IDE

Version: 2.3.4
Board: DOIT ESP32 DEVKIT V1

Here's the result:

The final result: Arduino IDE required 4 minutes and 17 seconds to compile, while using only about 20% of the available CPU, indicating poor resource utilization.

Platform: PlatformIO IDE

Version: 3.3.4
Board: DOIT ESP32 DEVKIT V1

Initializing the project:

Installing libraries:

Compile Result:

The final result: PlatformIO IDE required 57 seconds to compile, and using 100% of the available CPU, indicating maximum resource utilization and better compile time.

4. Conclusion

Feature	Arduino IDE	PlatformIO IDE	Change
Total Compile Time	4 minutes 17 seconds	57 seconds	3 minutes 20 seconds reduction
CPU Utilization	~20%	100%	+80%

With this result, we drastically improve compile time and maximizing resource usage by switching from Arduino IDE and PlatformIO IDE. Also, here is benefits by switching from Arduino IDE to PlatformIO IDE:

Code Suggestion, we can get code suggestion and even AI completions, just like when working on another projects in Visual Studio Code.
Customizable Theme, it's Visual Studio Code! you can use any theme you want
Easier Configuration, We can have separate configuration for each project and it is fairly easy to add libraries to the project.
Integration With Other Extension, You can still use all other available Visual Studio Code extensions to enhance your development workflow while using PlatformIO.

That’s why I highly recommend switching to PlatformIO. It offers a much better developer experience and makes embedded development faster and more enjoyable.

Cheers! 🥂