Build a Local AI Workspace with Ollama

Build a local AI workspace with Ollama, VS Code assistants, and browser chat.

Introduction

30 Second Summary

Every prompt you send to an online AI assistant can leave your computer for someone else's servers. That makes control harder when the prompt contains a private file or an unfinished idea.

In this project, you will build a local AI workspace powered by Ollama on your Ubuntu workstation. Your prompts stay on the workstation across terminal requests, Visual Studio Code assistants, and a browser chat.

What You'll Build

Picture your terminal, coding assistants, and browser chat all answering from models running on the workstation beside you.

By the end of this project, you'll have:

  • A local API response from http://localhost:11434/v1/ containing text generated by qwen3:8b. You can inspect its processor placement from the terminal.
  • Local chat plus editing through Continue. Inline suggestions come from qwen2.5-coder:1.5b. Cline can answer focused coding questions through the same local server.
  • A DeepSeek Harness browser chat that answers through your local model. Its cloud inference plus web search stay disabled.
  • Secret Mission: Create an executable shell script that lists your local models, sends a test request, and reports runtime placement.

Are there any prerequisites?

You'll need the provided Ubuntu 24.04 workstation, sudo access, an internet connection, and a working NVIDIA driver.

Visual Studio Code, Continue, and Cline should already be installed. The project costs $0, although its model files use local disk space.

Before We Start

Before any hands-on work begins, take a moment to commit to the local AI workspace you are about to build. Your goal is to keep AI prompts and code on your Ubuntu workstation under your control.

Install the Local AI Runtime

Your Continue extension needs a local model server before it can answer from this workstation. The same requirement applies to Cline.

Ollama provides that server for local inference. DeepSeek Harness also relies on Node.js plus the npm package manager.

In this step, get ready to:
  • Prepare curl for installer downloads.
  • Install Node.js 24 LTS with its included npm package manager.
  • Bring the Ollama service online with systemd and confirm NVIDIA visibility.
Prepare curl and Node.js

The Ollama installer arrives through an HTTPS download. Installing curl first gives the terminal a reliable way to retrieve it.

The sudo command may request your Ubuntu password. The terminal keeps the password hidden while you type.

  • Ensure curl is installed by running this command:
sudo apt install -y curl

What does this command do?

Ubuntu checks its package repositories for curl. It installs the package when needed.

The -y flag accepts the package confirmation automatically. This keeps the installation moving after any password request.

  • Confirm the final package output reports that curl was installed or was already current.

Did the curl installation fail?

Check that the workstation still has an internet connection. Package downloads cannot finish while Ubuntu is offline.

If Ubuntu rejects your password or reports a package problem, help me diagnose the curl installation.

DeepSeek Harness runs on Node.js 24 LTS. A version check separates a ready runtime from an older installation or a missing command.

  • Check the installed Node.js version by running this command:
node -v

What does this check prove?

The command asks the current Node.js executable to print its version. A result from the v24 branch meets this project's runtime requirement.

  • Choose the tab that matches the terminal result.

✔️ I see version 24 or higher

Your Node.js runtime already meets the requirement. The final verification checks that npm is available too.

ⓧ I see an older version

The installed runtime is below the required Node.js 24 LTS branch. The NodeSource setup flow updates the package source before Ubuntu installs the newer runtime.

  • Add the NodeSource 24.x package source by running these commands:
curl -fsSL https://deb.nodesource.com/setup_24.x -o nodesource_setup.sh
sudo -E bash nodesource_setup.sh
sudo apt install -y nodejs

What do these commands do?

  • The first command downloads the NodeSource setup script into nodesource_setup.sh.
  • The second command configures Ubuntu to use the Node.js 24.x package source.
  • The final command installs Node.js from that source. Its package includes npm.
  • Verify the upgraded runtime by running these commands:
node -v
npm -v

What should you see?

The first line shows a Node.js version from the v24 branch. The second line shows the installed npm version.

Still seeing an older Node.js version?

A previous package source may still be taking priority. Review the installer output for a failed repository setup or package download.

If the old version remains, help me finish the Node.js 24 upgrade.

ⓧ Command not found

Node.js is not installed yet. The NodeSource setup flow adds the required package source before Ubuntu installs the runtime.

  • Install Node.js 24 LTS by running these commands:
curl -fsSL https://deb.nodesource.com/setup_24.x -o nodesource_setup.sh
sudo -E bash nodesource_setup.sh
sudo apt install -y nodejs

What do these commands do?

  • The first command downloads the NodeSource setup script into nodesource_setup.sh.
  • The second command configures Ubuntu to use the Node.js 24.x package source.
  • The final command installs Node.js from that source. Its package includes npm.
  • Verify the new runtime by running these commands:
node -v
npm -v

What should you see?

The first line shows a Node.js version from the v24 branch. The second line shows the installed npm version.

Node.js installation failed?

Check the NodeSource setup output for a network or package repository problem. The Node.js package cannot install until that setup completes.

If the failure continues, help me diagnose the NodeSource installation.

Install Ollama

Ollama turns the workstation into a local model server. Its Linux installer also sets up the service that later accepts requests from your terminal clients.

The installer downloads files from Ollama. It may request your Ubuntu password while configuring the system service.

  • Install Ollama by running the official Linux command:
curl -fsSL https://ollama.com/install.sh | sh

What does this command do?

The command downloads Ollama's Linux installation script over HTTPS. It passes that script to the shell for installation.

The installation prepares Ollama to run as a system service. That service becomes the local endpoint used later in the project.

  • Confirm the Ollama command is available by running this check:
ollama -v

What should you see?

Ollama prints its installed version. Version output confirms that the terminal can find the new executable.

Good progress. Your workstation now has the runtime that serves every local model in this project.

Ollama command unavailable?

Review the installer output for a failed download or permission problem. A successful installation must finish before the terminal can find Ollama.

If the command is still unavailable, help me diagnose the Ollama Linux installation.

Verify the runtime and hardware

Version checks prove the commands are installed. The service check proves Ollama is ready to receive requests.

  • Predict whether all three version commands will succeed before you run them.
  • Verify the installed runtime versions by running these commands:
node -v
npm -v
ollama -v

What do these checks prove?

  • The Node.js check confirms that the v24 runtime is active.
  • The npm check confirms that the package manager came with Node.js.
  • The Ollama check confirms that its command remains available in this terminal.

You should see a Node.js version from the v24 branch. You should also see version output from npm plus Ollama.

A systemd service keeps Ollama available without requiring a separate server command in every terminal. Its status reveals whether the server process is active.

  • Predict whether the Ollama service is already active.
  • Check the Ollama service by running this command:
sudo systemctl status ollama

What does this status prove?

The status command asks systemd for the current Ollama service state. An active service is ready to accept local API requests.

  • Confirm that the service status is active.
  • Press q to leave the status view.

Ollama service inactive?

The installation may have completed before the service started. Start the documented Ollama service manually.

  • Start the Ollama service by running this command:
sudo systemctl start ollama

This asks systemd to start the installed Ollama service. Run the earlier status check again to confirm it is active.

If the service still fails, help me diagnose the Ollama systemd service.

The final check confirms that the existing NVIDIA driver exposes the workstation's GPU. This matters because local model placement depends on the hardware Ollama can see.

  • Predict whether Ubuntu will list the NVIDIA Quadro T2000.
  • Verify NVIDIA visibility by running this command:
nvidia-smi

What does this hardware check prove?

The command asks the NVIDIA driver for the detected GPU details. Seeing the Quadro T2000 confirms that Ubuntu can communicate with the card.

That completes the foundation. Node.js is ready, Ollama is serving locally, and the Quadro T2000 is visible to Ubuntu.

Quadro T2000 missing?

Check whether the command shows a driver problem or no detected device. This result points to the existing NVIDIA driver rather than the Ollama installation.

If the GPU is absent, help me diagnose NVIDIA visibility.

Your local AI runtime is ready. Next, you will download a model and prove that Ollama can answer through its local API.

Get a Local Model Response

Your local runtime is ready. The Ollama service is active on your workstation.

Now you need proof that a local model can generate a response. A direct call to the OpenAI-compatible API tests the server without adding an editor extension or graphical client.

In this step, get ready to:
  • Run qwen3:8b locally to generate a one-line response.
  • Send a prompt through the OpenAI-compatible http://localhost:11434/v1/responses endpoint.
  • Inspect where Ollama places the running model.
Download and test qwen3:8b

The qwen3:8b package is 5.2 GB. It uses Q4_K_M quantization to package the model for local inference.

The first run downloads the full package. Expect this download to take several minutes while the progress indicator moves toward completion.

  • Download the model and start its interactive chat by running this command:
ollama run qwen3:8b

What does this command do?

  • The command downloads qwen3:8b when it is missing from your workstation.
  • Ollama loads the model for inference after the download finishes.
  • The terminal becomes an interactive chat where each line becomes a model prompt.

You'll see an interactive prompt when the model is ready.

  • Enter Reply with one short sentence confirming local inference is working. at the chat prompt.

You'll see a generated sentence from the model running on your workstation.

  • Leave the interactive chat by typing /bye.

That is your first local model response. Your Ollama server can now load qwen3:8b and generate text.

Model download not completing?

  • Check your internet connection if the progress indicator stops moving.
  • Confirm that your workstation still has enough free disk space for the 5.2 GB package.
  • Retry the command after restoring the interrupted connection.

Help me diagnose an Ollama model download that does not complete.

Call the OpenAI-compatible API

The local endpoint at http://localhost:11434 does not require authentication. This request therefore needs no Authorization header.

Before you send the request, do you think the local endpoint will return generated text without an API key?

  • Send a prompt to the local Responses endpoint by running this command:
curl -X POST http://localhost:11434/v1/responses \
  -H "Content-Type: application/json" \
  -d '{
    "model": "qwen3:8b",
    "input": "Write a short poem about the color blue"
  }'

What does this request prove?

  • The request targets the local http://localhost:11434/v1/responses endpoint.
  • The Content-Type: application/json header identifies the request body as JSON.
  • The model field routes the prompt to qwen3:8b.
  • The input field contains the prompt sent to the model.
  • The missing Authorization header proves that the loopback-only local API does not need an API key.

You'll see a JSON response containing text generated by qwen3:8b. The successful response proves that the OpenAI-compatible route can reach your local model.

No generated response?

  • Confirm that the Ollama service from the previous step still shows as active.
  • Repeat the model download command if the response mentions that the requested model is missing.
  • Check each quotation mark in the request if the terminal reports malformed request data.

Help me debug my local Ollama Responses API request.

Inspect model placement

Local inference can use the GPU or the CPU. Ollama can also split a model across both processors when memory requires it.

Before you inspect the runtime, where do you expect Ollama to place this 5.2 GB model?

  • Inspect the running model by running this command:
ollama ps

How do I read the result?

  • Find the row for qwen3:8b to confirm that the API request loaded the model.
  • Read the PROCESSOR information to identify its runtime placement.
  • A split placement means Ollama is sharing the model between the GPU and CPU.

You'll see qwen3:8b in the running-model table. Its processor information shows whether the model is using the GPU, CPU, or both.

Model missing from the table?

Repeat the previous API request to load qwen3:8b. Run the placement check again immediately after the response finishes.

Help me understand why qwen3:8b is missing from ollama ps.

You have proved that your workstation can download a model, answer through a local API, and reveal where inference runs. Next up, you'll route the same local model into your coding workspace.

Configure Continue Chat and Edits

Your local qwen3:8b model already answers through Ollama's API. Continue now needs a local configuration for coding conversations.

The same configuration can route edits to your local model. Autocomplete requires a dedicated role, so this step intentionally leaves that gap visible.

In this step, get ready to:
  • Open Continue's local configuration in Visual Studio Code.
  • Assign qwen3:8b to the chat, edit, and apply roles.
  • Compare the working chat role with the unassigned autocomplete role.
Open Continue's local configuration

Continue stores its local model settings in ~/.continue/config.yaml. Saving this file automatically refreshes the extension.

  • Press the Super key to open Ubuntu's application search.
  • Type Visual Studio Code into the search field.
  • Press Enter to open Visual Studio Code.
  • Select Continue from the left sidebar.
  • Click the gear beside Local Config.

You'll see ~/.continue/config.yaml open in an editor tab. This is the file that controls Continue's local model routes.

Assign Qwen3 to chat and edits

A model role tells Continue which jobs a model can perform. This configuration gives qwen3:8b the three conversational and editing roles needed in this step.

  • Select all existing text in ~/.continue/config.yaml.
  • Replace the selected text by pasting this configuration:
name: Sovereign Local AI
version: 0.0.1
schema: v1

models:
  - name: Qwen3 8B Local
    provider: ollama
    model: qwen3:8b
    roles:
      - chat
      - edit
      - apply
    defaultCompletionOptions:
      contextLength: 8192

What Does This Configuration Do?

  • The top-level YAML fields name the configuration and select schema v1.
  • The provider: ollama setting routes requests through the local Ollama provider.
  • The model: qwen3:8b setting selects the model you already downloaded.
  • The roles list allows chat, edit, and apply work.
  • The contextLength: 8192 setting limits the context used by Continue to reduce local memory pressure.
  • Save ~/.continue/config.yaml with Ctrl+S.
  • Return to Continue in the left sidebar.

Continue refreshes the saved configuration automatically. You'll see Qwen3 8B Local available as your configured model.

That is the routing layer in place. Continue can now hand conversations and edits to your local Ollama model.

Local Model Missing?

  • Compare the indentation in ~/.continue/config.yaml with the complete file below.
  • Confirm the model identifier is exactly qwen3:8b.
  • Confirm the Ollama service from earlier remains active.

Still blocked? Help me diagnose why Continue cannot load my local Ollama configuration.

✔️ Awesome, I've got everything!

Great. Double-check that ~/.continue/config.yaml is saved before testing the model.

ⓧ I'd like to double check the full code

name: Sovereign Local AI
version: 0.0.1
schema: v1

models:
  - name: Qwen3 8B Local
    provider: ollama
    model: qwen3:8b
    roles:
      - chat
      - edit
      - apply
    defaultCompletionOptions:
      contextLength: 8192
Verify chat and expose the role gap

A successful chat response proves that Continue can reach the local model. The configured role list also reveals which local capability is still missing.

  • Return to Continue in the left sidebar.
  • Select Qwen3 8B Local as the active model.
  • Ask Continue to return LOCAL CONTINUE READY.

Before you send the message, do you think Continue can reach the same local model that answered your terminal request?

  • Press Enter to send the chat message.

You'll see LOCAL CONTINUE READY in Continue's reply.

That is a strong checkpoint: your Continue chat now reaches the local qwen3:8b model.

Before you inspect the roles, do you think a working chat model also gives Continue a dedicated local autocomplete model?

  • Switch back to the ~/.continue/config.yaml tab from earlier.
  • Inspect the roles list beneath Qwen3 8B Local.

You'll see chat, edit, and apply. You will not see an autocomplete role.

This is the intended gap. Continue has a working local conversation model while local autocomplete remains unassigned.

Your first local assistant route is working. Next, you'll give autocomplete its own model before connecting Cline to Ollama.

Add Autocomplete and Connect Cline

Your local qwen3:8b model already answers through Continue. That successful chat proves the main local route works.

Inline suggestions need a smaller fill-in-the-middle model built for completion. Cline needs its own Ollama connection inside Visual Studio Code with a 32K coding context.

In this step, get ready to:
  • Download the specialized qwen2.5-coder:1.5b autocomplete model.
  • Assign the new model to Continue's autocomplete role.
  • Connect Cline to the local qwen3:8b model.
Download the autocomplete model

Continue recommends a dedicated coding model for autocomplete because this role predicts code inside an unfinished file. The qwen2.5-coder:1.5b package is 986 MB.

This download is the slow part. The terminal displays progress while Ollama fetches the model.

  • Download the model and start its interactive chat by running this command:
ollama run qwen2.5-coder:1.5b

Why use a separate model?

Autocomplete predicts the missing code around your cursor. Models trained for fill-in-the-middle completion handle that pattern more efficiently than a general chat model.

The smaller package also reduces local memory pressure. This keeps inline suggestions responsive while qwen3:8b handles longer conversations.

  • Enter a brief coding question at the interactive prompt.
  • Confirm that the model returns a coding response.
  • Leave the interactive chat by pressing Ctrl+C.

Good progress. That response confirms the autocomplete model is downloaded and ready for Continue.

Model not responding?

Check that the Ollama service from the earlier step is still active. A stopped service prevents the model chat from starting.

If the download stops partway through, rerun the same command after confirming your internet connection is available.

Help me diagnose the local model download.

Assign the model to autocomplete

Continue chooses models by role. Your existing entry keeps qwen3:8b responsible for chat, edits, and applying changes.

  • Return to ~/.continue/config.yaml in Visual Studio Code.
  • Place your cursor after the existing contextLength: 8192 line.
  • Paste this model entry below the existing Qwen3 block:
  - name: Qwen2.5 Coder 1.5B Autocomplete
    provider: ollama
    model: qwen2.5-coder:1.5b
    roles:
      - autocomplete

What does this model entry do?

  • The model name distinguishes the autocomplete model in Continue.
  • The ollama provider sends requests to your local Ollama server.
  • The model identifier matches the package you just downloaded.
  • The autocomplete role reserves this model for inline code suggestions.
  • Save ~/.continue/config.yaml.
  • Wait for Continue's automatic configuration refresh to finish.
  • Create an untitled code buffer in Visual Studio Code.
  • Select JavaScript as the buffer's language mode from the status bar.
  • Begin writing a small function that receives a name.
  • Pause after the opening brace to trigger an inline suggestion.

You'll see a local inline suggestion appear as faint text beside your cursor. You've closed the missing role gap in Continue.

No inline suggestion?

Check that the new model entry aligns with the existing item under models. Incorrect YAML indentation can prevent Continue from loading the entry.

Confirm that the model identifier is exactly qwen2.5-coder:1.5b. Also confirm that the Ollama service is active.

Help me fix Continue autocomplete.

✔️ Awesome, I've got everything!

Great. Double-check that you saved the configuration after adding the autocomplete model.

ⓧ I'd like to double check the full code

  • Compare your complete ~/.continue/config.yaml file with this reference:
name: Sovereign Local AI
version: 0.0.1
schema: v1

models:
  - name: Qwen3 8B Local
    provider: ollama
    model: qwen3:8b
    roles:
      - chat
      - edit
      - apply
    defaultCompletionOptions:
      contextLength: 8192

  - name: Qwen2.5 Coder 1.5B Autocomplete
    provider: ollama
    model: qwen2.5-coder:1.5b
    roles:
      - autocomplete
Connect Cline to Ollama

Cline maintains its own provider settings, so it does not reuse Continue's configuration. A 32K context gives focused coding tasks more room.

A larger context also uses more memory. Use Cline for focused tasks that fit this workstation's local resources.

  • Switch to Cline from the Visual Studio Code sidebar.
  • Open Cline's model provider settings.
  • Select Ollama as the provider.
  • Enter http://localhost:11434 in the Base URL field.
  • Select qwen3:8b from the model list.
  • Set the coding context to 32K.
  • Enable Use Compact Prompt.

Before you send the task, do you expect Cline to answer from the same local model without a cloud credential?

  • Send Cline this focused task: Explain how to return the largest number from a JavaScript array.

You'll see a focused coding response in Cline. Its selected provider, localhost Base URL, and model show that the request used your local qwen3:8b server.

That's both coding assistants connected. Continue now specializes by role while Cline handles focused tasks through the same local runtime.

Cline not returning a response?

Confirm that the Base URL is http://localhost:11434. Also check that qwen3:8b remains selected.

If Cline keeps waiting, confirm that the Ollama service is active. Keep the task focused so the local model does not receive unnecessary context.

Help me debug Cline's local Ollama connection.

Your editor now routes chat, edits, autocomplete, and focused agent tasks to local models. Next, you'll extend the same sovereign setup to a graphical browser chat.

Launch a Sovereign Harness Chat

Your Continue assistant now handles local chat plus autocomplete. Cline now answers focused tasks through the same local server.

DeepSeek Harness can route browser chat to your Ollama server. A sovereign setup also disables remote inference plus web search.

In this step, get ready to:
  • Lock Ollama into local-only mode.
  • Launch DeepSeek Harness in a local browser interface.
  • Prove that Harness uses qwen3:8b locally.
Disable Ollama cloud features

OLLAMA_NO_CLOUD=1 disables remote inference plus web search. A systemd drop-in keeps that setting attached to Ollama service restarts.

Restarting the service briefly pauses local clients. Your downloaded model files remain on disk.

  • Return to the Terminal from earlier.
  • Open the Ollama service override by running this command:
sudo systemctl edit ollama.service

What does this command do?

This command opens a systemd drop-in editor for the existing Ollama service. The drop-in adds your local-only environment setting without replacing the installed service definition.

  • Replace the editable content with this configuration:
[Service]
Environment="OLLAMA_NO_CLOUD=1"

What does this configuration do?

  • The first line places the environment setting inside the service configuration.
  • OLLAMA_NO_CLOUD=1 tells Ollama to reject cloud inference plus web search.
  • Save the override in Nano by pressing Ctrl+O.
  • Confirm the file name by pressing Enter.
  • Exit Nano by pressing Ctrl+X.

Did a different editor open?

Use the save control shown by your editor. Exit the editor only after the two configuration lines are saved.

Need help with the editor?

Help me save and exit the editor opened by systemctl.

✔️ Awesome, I've got everything!

The local-only drop-in now has the two required lines. The next commands apply it to the running service.

ⓧ I'd like to double check the full code

Compare your complete override with this file:

[Service]
Environment="OLLAMA_NO_CLOUD=1"

What should match?

Your override should contain these two lines in this order. Matching quotes around the environment setting keep the systemd value intact.

  • Apply the saved drop-in by running these commands:
sudo systemctl daemon-reload
sudo systemctl restart ollama

What do these commands do?

  • The first command makes systemd read the new drop-in.
  • The second command restarts Ollama with local-only mode enabled.

Before you check, predict whether the restarted Ollama service is ready for local clients.

  • Check the restarted service by running this command:
sudo systemctl status ollama

What should you see?

The status should show that the Ollama service is active. This confirms that systemd accepted the drop-in plus restarted the server.

  • Return to the terminal prompt by pressing q.

Is the Ollama service inactive?

Reopen the override to check its two lines. Pay close attention to the quotes around the environment setting.

Help me diagnose the Ollama service restart.

Launch DeepSeek Harness

DeepSeek Harness is a browser-based coding agent in developer preview. Ollama provides a launcher that starts the integration plus installs its package when needed.

The first launch can take a few minutes while Ollama installs @deepseek-ai/dsh. Quiet terminal time during that installation is expected.

  • Start the DeepSeek Harness integration by running this command:
ollama launch dsh

What does this command do?

  • Ollama installs @deepseek-ai/dsh when the package is missing.
  • The launcher starts DeepSeek Harness as a local Web UI.
  • Keep this terminal running while you use the browser chat.

Your browser should open the local DeepSeek Harness Web UI. The running terminal keeps that interface available.

Did the browser stay closed?

Check the launcher output for a local URL. Open that displayed URL in your browser.

Confirm that your internet connection remains available if the package installation is still running.

Help me troubleshoot the Harness launch.

Connect the local model and verify it

A custom provider maps the Harness model picker to your loopback Ollama endpoint. The OpenAI Chat Completions protocol carries each chat request through that route.

  • Switch back to the DeepSeek Harness browser tab.
  • Click Settings.
  • Select Models.
  • Choose Add model provider.
  • Switch the provider card to Custom model API.
  • Enter ollama in the Provider ID field.
  • Enter http://127.0.0.1:11434/v1 in the Base URL field.
  • Choose OpenAI Chat Completions as the API protocol.

The provider now points at your loopback endpoint. The remaining fields define authentication plus the model catalog.

  • Leave the API key field blank.
  • Add qwen3:8b as the Model ID.
  • Use the confirmation control at the bottom of the card to create the provider.
  • Select qwen3:8b from the model picker.

Why is the API key blank?

The local Ollama API does not require authentication. A blank field keeps this localhost connection free from invented credentials.

Before you send the first message, predict whether the selected local model can answer through the new provider.

  • Enter Reply with LOCAL HARNESS READY. in the chat composer.
  • Submit the message using the send control beside the composer.

You should receive a response containing LOCAL HARNESS READY. This proves that the custom provider can complete a chat turn.

  • Keep the Harness process running in its terminal.
  • Press the Windows key on your Ubuntu keyboard to open search.
  • Type Terminal into the search field.
  • Press Enter to open a second Terminal window.

Before you check, predict whether the running-model table contains only local model names.

  • Inspect the model used by Harness by running this command:
ollama ps

What should you see?

  • qwen3:8b should appear as a running local model.
  • The PROCESSOR information should show its current GPU placement or CPU placement.
  • No selected model should have a :cloud suffix.

You have completed the sovereignty check. Your browser chat now reaches a local model while Ollama cloud inference plus web search remain disabled.

Secret mission

Build a Local API Smoke Test

Turn your manual Ollama checks into one reusable diagnostic. The script lists local models, requests a response from qwen3:8b, and reports its processor placement.

Clean Up Your Resources

Clean Up Your Resources

This local workspace costs $0 to keep. Its model files use disk space while active models use memory plus GPU or CPU time.

Resources you used:

  • The qwen3:8b and qwen2.5-coder:1.5b model files stored by Ollama.
  • The local model settings in Continue at ~/.continue/config.yaml plus the local provider selection in Cline.
  • The local custom provider settings in DeepSeek Harness.
  • The local-only systemd override at /etc/systemd/system/ollama.service.d/override.conf plus the optional ~/local-ai-check.sh script.

Keep everything running

No action needed. Choose this if you plan to keep using the workspace for local chat or coding tasks.

  • Keep both model files so future sessions can start without downloading them again.
  • Keep ~/.continue/config.yaml so Continue retains its separate chat plus autocomplete roles.
  • Keep the Cline provider settings so focused tasks continue to use the local qwen3:8b model.
  • Keep OLLAMA_NO_CLOUD=1 in place so Ollama remote inference plus web search remain disabled.
  • Press Ctrl+C in the DeepSeek Harness terminal whenever you finish using the browser chat.

Pause - I'll come back to this later

Shut down the active browser chat plus loaded models to release local memory. Your model files plus configurations stay ready for the next session.

  • Press Ctrl+C in the terminal running DeepSeek Harness.
  • Inspect the models currently using local resources by running this command:
ollama ps

What Does This Show?

  • The table lists each model that is still loaded.
  • The processor information shows whether each model is using the GPU or CPU.
  • Use the documented stop command from the official Ollama CLI reference for each model shown in the table.
  • Confirm that the loaded models have stopped by running this command again:
ollama ps

You should no longer see the stopped models in the table. Their downloaded files remain available for your next session.

Delete - I don't want to use this again

Deleting these local resources is permanent. Rebuilding the workspace requires downloading the models plus recreating its local configurations.

  • Select Settings in DeepSeek Harness.
  • Select Models.
  • Remove the custom provider with Provider ID ollama.
  • Clear the local Ollama provider selection from Cline's provider settings.
  • Press Ctrl+C in the terminal running DeepSeek Harness.
  • Remove qwen3:8b with the model-removal command from the official Ollama CLI reference.
  • Remove qwen2.5-coder:1.5b with the same documented model-removal command.
  • Remove the optional diagnostic script plus the project-specific Continue configuration by running:
rm -f ~/local-ai-check.sh ~/.continue/config.yaml

What Does This Cleanup Remove?

  • The first path removes the reusable local API smoke test.
  • The second path removes the Continue model-role configuration created for this workspace.
  • Your Continue plus Cline extensions remain installed in Visual Studio Code.

Only Re-enable Cloud Features Intentionally

Removing the systemd override removes the OLLAMA_NO_CLOUD=1 protection. Continue only if you intentionally want Ollama cloud inference plus web search to become available again.

  • Expect Ubuntu to request your password when sudo runs.
  • Remove the local-only override plus refresh the Ollama service by running:
sudo rm -f /etc/systemd/system/ollama.service.d/override.conf
sudo systemctl daemon-reload
sudo systemctl restart ollama

What Does This Service Cleanup Do?

  • The first command removes the project-specific systemd override.
  • The second command makes systemd reread the service configuration.
  • The third command restarts Ollama without the local-only setting.
  • Check that neither downloaded model remains active by running:
ollama ps

You should see neither qwen3:8b nor qwen2.5-coder:1.5b in the running-model table. Your Ubuntu workstation plus its existing Visual Studio Code extensions remain available.

Nice Work!

Nice Work!

You did it! Your Ubuntu workstation now runs a sovereign AI workspace powered by Ollama.

What you learned:

  • Served qwen3:8b through a local OpenAI-compatible API. Inspected GPU or CPU placement with ollama ps.
  • Split Continue model roles so qwen3:8b handles chat plus edits. Assigned qwen2.5-coder:1.5b to local autocomplete.
  • Configured Cline for focused local code tasks through qwen3:8b. Connected DeepSeek Harness to a localhost provider. Protected data sovereignty by keeping remote inference disabled. Kept web search disabled.
  • Secret Mission: Built an executable smoke-test script at ~/local-ai-check.sh. It lists local models. It requests a response. It reports runtime placement.

Ready to quiz yourself?