DEV Community

Solon Framework
Solon Framework

Posted on

No JSON Required: Configuring SolonCode's Model from the Web Settings Panel

#java #ai #opensource #tools

Most coding agents make you earn your first conversation. You install the binary, then you go hunting for a config file, then you find out the config file wants a provider name you have to spell exactly right, a base URL that may or may not need a trailing path segment, and a key you paste into a text editor and hope you didn't leave a trailing space on.

SolonCode skips that. You start it in web mode, the browser opens, and you add your model in a settings panel — paste the endpoint, paste the key, hit test, save. The chat area picks up the new model immediately. There is a settings.json underneath, and you can read it if you're curious, but on the way to your first task you never need to open it.

Here's the whole path, with the screens you'll actually see.

Before you start

Two things:

  • Java 8 or newer. SolonCode runs on Java 8 through Java 26, so whatever JDK your project already builds against is almost certainly fine.
  • One reachable model endpoint. OpenAI, Anthropic, Gemini, Ollama, or anything speaking a compatible format.

Optional, and only if you want the matching features later: Node.js (for some MCP servers, Skills, and browser-type tools), Git (so the web UI can show you diffs and staging), and a language server (for LSP-backed code understanding). None of these block your first run.

Install:

# macOS / Linux / Harmony PC
curl -fsSL https://solon.noear.org/soloncode/setup.sh | bash
Enter fullscreen mode Exit fullscreen mode 
# Windows PowerShell
irm https://solon.noear.org/soloncode/setup.ps1 | iex
Enter fullscreen mode Exit fullscreen mode

Re-running the same command later is how you update. The installer refreshes program files and does its best to preserve what you've already configured — settings.json, AGENTS.md, and friends stay put.

Confirm it landed:

soloncode version
# SolonCode v2026.8.4
Enter fullscreen mode Exit fullscreen mode

Start web mode

Go to the project you actually want to work on. The directory you launch from becomes the workspace, and that matters for scoping later, so cd first rather than launching from your home directory.

cd your-project
soloncode web 0
Enter fullscreen mode Exit fullscreen mode

Three ways to pick a port:

Command Port
soloncode web Default, 4808
soloncode web 0 Random free port
soloncode web 1212 That specific port

web 0 is the one to reach for when you keep several projects open, because you're not going to collide with an instance you forgot about. The browser tab is labeled with the workspace name and path, which is how you tell four open tabs apart.

The terminal prints the address it picked:

SolonCode v2026.8.4 PID-4131 Model:your-model
/path/to/your-project
Web interface: http://localhost:1212/
Enter fullscreen mode Exit fullscreen mode

The browser opens on its own. If it doesn't — remote box, headless environment, an OS that decided not to cooperate — copy the address from that output.

What you land on is the welcome screen: an input box in the middle, the workspace file tree on the right, conversation controls on the left, and the current model shown under the input.

SolonCode welcome screen

First stop: set your language

Click Settings in the left rail, and the first card under General is Display Language. It ships as Follow system default, which means the UI speaks whatever your OS does.

Display language dropdown

Twenty-three locales in that list. Pick yours and the interface re-renders on the spot — no restart, no reload. Menus, section names, buttons, placeholder text, all of it.

Settings panel in English

Two things worth knowing that the dropdown doesn't tell you:

The setting is per-session. Selecting a language applies it immediately, but reloading the page drops you back to Follow system default. If your OS locale already matches what you want, you'll never notice. If it doesn't, expect to re-pick after a reload.

It changes the UI, not the agent. Display Language controls chrome. The language your model answers in comes from the model, and it will happily reply in one language to a prompt written in another. If you want English answers, ask for English answers:

Reply in English. <your actual request>
Enter fullscreen mode Exit fullscreen mode

Or put it in AGENTS.md once and stop repeating yourself.

The rest of General, for when you come back to it: Conversation Strategy, Sandbox Mode, Memory, Retry on Failure, and Appearance.

The settings panel

Nine sections down the side:

General · Agents · Mounts · Skills · Providers · Models · MCP Servers · OpenAPI Servers · LSP Servers

You want Models.

One small thing that will bite you if nobody says it: Esc closes the whole settings panel, not just the form you have open. Use the panel's own Back button when you mean to back out of a form.

Add your first model

Models → + Add Model. This opens as a full page inside the panel, not a popup dialog:

Add model form

  • Name — how it shows up in the model picker. Free text, so name it something you'll recognize at a glance.
  • Scope — two buttons, User (Global) and Workspace (Local). More on this below.
  • URL mode — a dropdown, default Full URL (auto-detect). The alternatives are BaseUrl modes for OpenAI Chat Completions, OpenAI Responses, and Anthropic, plus dedicated Gemini and Ollama entries. Auto-detect covers the common cases; reach for a specific mode when your endpoint isn't a full completions URL.
  • API URL — placeholder shows the shape it wants, e.g. https://api.deepseek.com/v1/chat/completions.
  • API Key — sk-..., with a show/hide toggle.
  • Model — the provider's model identifier.
  • Context length — a dropdown of common sizes.
  • Timeout — 120s by default.
  • Extra options — a JSON field for things like temperature, top_p, or reasoning flags, with a Format JSON button. Empty is a perfectly good answer here.
  • Set as default model — a checkbox.

Filled in against a local Ollama instance:

Add model form, filled

Then the part people skip: press Test Connection before you press Save.

A model that's added but unreachable looks identical to a model that works, right up until your first task dies mid-run and you're reading logs to figure out whether the problem was your key, your URL, or your proxy. The test button is right next to Save. Ten seconds there removes a whole category of confusion.

After you save, the model list in the chat area refreshes to match — no restart. If you've accumulated a long list, the picker supports search filtering, so you type a fragment instead of scrolling.

Global or workspace

The scope buttons in the form decide which file your model lands in:

Scope File Use it for
User (Global) ~/.soloncode/settings.json Your everyday model, shared across every project
Workspace (Local) .soloncode/settings.json in the project Models specific to this project

SolonCode reads the user-level file first, then the workspace file, and workspace config overrides or supplements what it found.

Workspace scope has a second-order effect worth thinking about for a second. That file sits inside the project directory, which means it can be committed. Sharing endpoint and model choices with your team that way is genuinely useful. Sharing an API key that way is not. Decide which of those you're doing before you git add.

Providers, when one key serves many models

If you're adding a second and third model against the same endpoint, the Providers section is the better place to work. It manages vendor config — API address, keys — as one entry, with add, modify, and enable/disable per provider.

The reason to care is maintenance rather than setup. When a key rotates, you want one place to change it, not four model entries that each remember their own copy. Same story when you're moving an endpoint. Set the provider up once; point models at it.

First conversation

Don't lead with a code change. Lead with a question, because the answer tells you whether the model is actually seeing your repo:

Reply in English. What kind of project is this directory?
Check the build file and source layout before answering.
Enter fullscreen mode Exit fullscreen mode

First conversation

Watch the tool trace above the answer: ls, a glob for pom.xml, a read of that file, then a recursive listing of src. It looked before it spoke. And what it reported back was that the skeleton exists — parent POM, one web dependency, standard Maven layout — but there's no source, no app.yml, no tests, so nothing is actually written yet.

That's the signal you're checking for. An agent that had described a working application there would be an agent you couldn't trust on a real repo. Note the footer too: token count, elapsed time, and running context usage, so you can see what a turn cost you.

Once you're connected, give it a foundation to work from:

Generate .soloncode/CODE.md for this project, including build commands,
test commands, and notes on what to be careful about when modifying code.
Enter fullscreen mode Exit fullscreen mode

If that file already exists, SolonCode prefers what's in it. That's the point — it's the engineering contract for the repo, and having it written down means you stop re-explaining your build every session.

Now a small task, scoped tightly:

Check whether the install instructions in README are out of date.
Docs only, no code changes. Tell me what you changed when you're done.
Enter fullscreen mode Exit fullscreen mode

Small and reviewable on the first pass. You're not testing whether the agent can do impressive things yet; you're testing whether you can read and trust its output.

For anything bigger, four things belong in the prompt:

Goal: fix the NPE in the user login endpoint.
Scope: only the user module.
Constraint: do not change the response structure.
Verification: run the related unit tests; if none exist, say so.
Enter fullscreen mode Exit fullscreen mode

Goal, scope, constraint, verification. The last one matters more than it looks — asking for verification is what turns "I made a change" into "I made a change and here's the evidence."

What else the panel covers

Model config is one section out of nine. The rest are there when a specific need shows up: permissions and tool allow/deny lists, mount pools that expose external directories as Skills or Agents resources, a Skills marketplace with install support, MCP servers over stdio/SSE/streamable with connection checks and per-tool disabling, OpenAPI servers imported from a JSON/YAML spec, and LSP servers for code intelligence.

None of that is required today, and the pattern is the same each time: open the section, fill in the entry, test, save.

Saving generally writes through to the running engine, so most changes don't need a restart. When you're running several instances against the same config, there's a Reload config from disk button at the top of the panel to bring them in sync.

Two things to set before you expose it

Web auth. General settings has username and password fields for a login page, and they're empty by default — which is fine for localhost, and not fine the moment you bind to an address other machines can reach. If you're running SolonCode on a dev box or a shared server, turn this on before anything else. An unauthenticated agent UI is a remote shell with a nicer font.

Keys out of Git. Global config lives in your home directory, nowhere near your repo. Workspace config lives in .soloncode/settings.json, inside the project. Check what your .gitignore does with it. The scan-for-leaked-keys conversation is much less pleasant than the two minutes this takes.

Things you'll appreciate later

Web-mode features that don't matter on day one and become daily habits by week two:

  • Mermaid rendering — ask for an architecture diagram and read it as a diagram
  • Memory management — inspect, edit, and delete long-term memory from the UI, with scope switching
  • File preview — images, video, and Markdown, including fullscreen
  • Conversation management — pin, fork (copy), and delete threads
  • Voice input — hold to talk, release to send
  • Skins — default, eyecare, contrast, plus custom skins you upload as a zip

And the keyboard, since you'll live here:

Key Action
Ctrl + Enter Send
↑ / ↓ Cycle input history
/ then Tab Command completion
@ then Tab Subagent completion

When you don't want a UI at all

For scripts, CI, or a one-shot job, skip the interactive console entirely:

soloncode run "Summarize the current project structure"
Enter fullscreen mode Exit fullscreen mode

Same engine, same config, no browser. The settings you just made in the web panel apply here too — which is the actual reason the panel is worth using first. You configure once, visually, with a connection test to confirm it, and every other entry point inherits it.

Sources

Top comments (0)