How I Cleared 60 GB of Space From Xcode on My Mac

If your Mac is running out of storage and you build apps for Apple devices, Xcode is probably using up your disk space. Here is how I cleaned up my Mac using a few simple terminal commands.

The Problem: Xcode Saves Everything and Never Deletes It

Xcode keeps a lot of old files on your computer. Over time, it saves temporary build files, simulator data, and files from older phone updates. It does not delete these files by itself, so they slowly fill up your hard drive.

When I checked my ~/Library/Developer folder, Xcode and CoreSimulator were taking up 68 GB of space:

• CoreSimulator: 30 GB
• Xcode Directory: 38 GB (including 26 GB in iOS DeviceSupport and 9.9 GB in DerivedData)

Step 1: Delete Old Simulators You Can No Longer Use

When you update Xcode or delete older iOS versions, the virtual test phones from those old versions stay on your computer. They take up space with old app data that you cannot even run anymore.

You should not delete these folders manually because it can break Xcode. Instead, run this command in your Terminal:

xcrun simctl delete unavailable

Result: This removed all old virtual phones and reduced my CoreSimulator folder from 30 GB down to just 4.5 GB.

Step 2: Clear Out iOS Device Support Files

When you connect a real iPhone or iPad to your Mac to test an app, Xcode copies system files from that device. The problem is that Xcode creates a new 4 GB to 5 GB folder every time your phone gets an update, and it keeps all the old ones.

These files are inside ~/Library/Developer/Xcode/iOS DeviceSupport. You can safely delete everything in this folder. If you connect your phone again later, Xcode will just download what it needs for that phone.

rm -rf ~/Library/Developer/Xcode/iOS\ DeviceSupport/*

Result: Freed 26 GB of space instantly.

Step 3: Delete Temporary Build Files (DerivedData)

The DerivedData folder holds temporary files that Xcode creates when it builds your projects. As you work on different projects over time, this folder grows very large.

You can delete all files in this folder without losing any of your project code. The only difference is that Xcode will take a minute to rebuild these files the next time you open a project.

rm -rf ~/Library/Developer/Xcode/DerivedData/*

Result: Freed almost 10 GB of space.

The Final Result: 62 GB Saved

After running these simple commands, I checked my folder sizes again:

• CoreSimulator: Went down from 30 GB to 4.5 GB
• Xcode Directory: Went down from 38 GB to 1.6 GB

In total, I got back 62 GB of free space in under five minutes. If your Mac is short on space, try these three steps first.

Read More

Debugging Nanobot with Zhipu AI and Building WebUI

01. Install Nanobot

Make sure Nanobot is installed in your virtual environment.

(venv) pip install nanobot

• Activate your virtual environment
• Run pip install nanobot
• Verify installation with nanobot status

02. Enable WebUI

Nanobot provides a web interface you can launch.

nanobot webui

• From your project directory, run nanobot webui
• This starts a local server (default port 8080)
• You’ll see a message like Running on http://localhost:8080

03. Access in Browser

Open the WebUI in your browser.

• Navigate to http://localhost:8080
• You should see the Nanobot WebUI dashboard
• Use it to manage agents, models, and workflows

04. Configure Defaults

Set provider and model in config for WebUI use.

~/.nanobot/config.json

• Add provider: zhipu
• Add model: glm-5.1
• Restart nanobot webui to apply changes

05. Optional: Change Port

If port 8080 is already in use, specify another.

nanobot webui --port 3000

• Then open http://localhost:3000

Runtime Details

To check which provider and model Nanobot is using, run:

nanobot status

Example output:

🐈 nanobot Status
Model: GLM-5.1
Zhipu AI: ✓
OpenAI: not set
Anthropic: not set
...
    

Nanobot does not have a --debug option. Instead, check logs in ~/.nanobot/workspace/logs for runtime details.

Summary

Install Nanobot, run nanobot webui, and open the localhost URL in your browser. From there you’ll have a graphical interface to manage your agents and models.

Q: How do I configure Nanobot to use Zhipu AI?

A: In ~/.nanobot/config.json or nanobot.yaml, I set both provider and model:

defaults:
  provider: zhipu
  model: glm-5.1
  

Without provider: zhipu, Nanobot may default to another backend like OpenAI.

Q: What does “out of quota” mean?

A: This error comes directly from Zhipu’s API. It means your account has run out of credits or has unpaid billing. The fix is to log into Zhipu’s dashboard, check quota, and top up your plan.

Q: Can I use the Coding Plan API with Nanobot?

A: Yes. The Coding Plan is just a billing tier. Nanobot calls the same endpoint, so glm-5.1 works fine. The only difference is quota and billing limits.

Q: Why does it work locally but not on my remote server?

A: The problem was environment variables. On the remote server, I had to export my API key:

export ZHIPU_API_KEY=your_key_here
  

Then confirm it’s set:

echo $ZHIPU_API_KEY
  

I also tested connectivity with curl:

curl -H "Authorization: Bearer $ZHIPU_API_KEY" \
     -H "Content-Type: application/json" \
     -d '{"model":"glm-5.1","messages":[{"role":"user","content":"Hello"}]}' \
     https://open.bigmodel.cn/api/paas/v4/chat/completions
  

Q: How do I know which API, model, and provider Nanobot is using?

A: Run:

nanobot status
  

Example output:

🐈 nanobot Status
Model: GLM-5.1
Zhipu AI: ✓
OpenAI: not set
Anthropic: not set
...
  

This confirms Nanobot is using Zhipu AI with GLM‑5.1.

Q: Can I see runtime details with debug?

A: Nanobot doesn’t have a --debug flag. Instead:

• Check logs in ~/.nanobot/workspace/logs.
• Use nanobot status for active provider/model.
• Run curl manually to see raw API responses.

Q: How do I build the WebUI from source?

A: Here’s the full process I followed:

1. Clone the repo:

   git clone https://github.com/HKUDS/nanobot.git
   cd nanobot

2. Create a virtual environment:

   python3 -m venv venv
   source venv/bin/activate

3. Install backend dependencies:

   pip install -r requirements.txt

4. Build the frontend:

   cd webui
   npm install
   npm run build

5. Run the WebUI:

   nanobot webui

   or

   uvicorn nanobot.webui:app --reload --port 8080

6. Open http://localhost:8080 in your browser.

Read More

Installing Nanobot on WSL Ubuntu

Recently, I decided to install Nanobot on my WSL Ubuntu environment.

Step 1: Preparing the Environment

I started by updating my system and installing the necessary packages:

sudo apt update
sudo apt install python3-full python3-venv git

Step 2: Cloning Nanobot

Next, I cloned the Nanobot repository from GitHub:

git clone https://github.com/HKUDS/nanobot.git
cd nanobot

Step 3: Creating a Virtual Environment

When I tried to install Nanobot directly with pip install -e ., I hit the following error:

error: externally-managed-environment
× This environment is externally managed
╰─> To install Python packages system-wide, try apt install...

This happened because Ubuntu now protects the system Python environment (PEP 668). The solution was to create a virtual environment:

python3 -m venv .venv
source .venv/bin/activate

Step 4: Installing Nanobot

Inside the virtual environment, I upgraded pip and installed Nanobot:

pip install --upgrade pip
pip install -e .

Step 5: Configuring Nanobot

I needed to configure Nanobot with my API key. I copied my existing config file from Windows into WSL:

mkdir -p ~/.nanobot
cp /mnt/c/Users/oktay/.nanobot/config.json ~/.nanobot/

Alternatively, I could have created a symlink to always share the same config:

ln -s /mnt/c/Users/oktay/.nanobot/config.json ~/.nanobot/config.json

Step 6: Facing the API Key Error

When I ran nanobot agent, I got:

Error: No API key configured for provider 'None'.

The fix was to ensure my ~/.nanobot/config.json contained the correct key:

{
  "api_key": "YOUR_OPENAI_API_KEY",
  "model": "gpt-4o-mini",
  "webui": true
}

Step 7: Running Nanobot

Finally, I launched Nanobot inside the virtual environment:

cd ~/nanobot
source .venv/bin/activate
nanobot agent

With the correct configuration, Nanobot started successfully, and the WebUI became available at http://127.0.0.1:8765.

Conclusion

Installing Nanobot on WSL Ubuntu was straightforward once I understood the new Python environment restrictions. The key lessons were:

• Always use a virtual environment to avoid conflicts with system Python.
• Keep your config file in ~/.nanobot/config.json with the correct API key.
• Symlinking the config file from Windows ensures both environments stay in sync.

Now Nanobot runs smoothly on my WSL setup, ready for experiments and development.

Read More