The models and technology we build on, placed on a dated radar.
Each model and tool we work with sits in a dated ring, from our defaults and current trials to the practices we refuse for new work.
We build on Anthropic Claude, OpenAI GPT and Google Gemini through their APIs, and open-weight models such as Llama, Mistral and Qwen on hardware you control, chosen per job and named in your proposal. For business work, the best LLM depends on whether the data may leave, the price of a mistake and the monthly cost at your volume.
Each ring is a dated opinion.
Every entry sits in one of four rings, which record what we reach for when starting new work, as of 23 September 2026. It is our view of our own work, with no standing as a benchmark, a vendor ranking or advice for anyone else's system.
- Use. Our default for the job named.
- Trial. Used on bounded jobs, with the evaluation set deciding.
- Watch. Worth knowing, and not yet a default for new work.
- Hold. No new work starts this way, and the table gives the reason.
The format comes from the Technology Radar that Thoughtworks publishes twice a year, whose rings are Adopt, Trial, Assess and Caution. Ours is smaller and covers only our own stack.
Three questions decide which kind of model fits.
We ask the three in a fixed order: whether the data may leave your tenancy, the price of a mistake, and the monthly bill at your real volume. The first often settles the rest: recorded calls, patient files and confidential contracts point straight to open weights on your own hardware.
The large hosted models earn their premium on contract reasoning, while a small self-hosted model wins on price when the job is sorting thousands of short messages. A worked comparison, with a cost worksheet, is in private LLM vs API.
The choice goes into the proposal with a note on what happens if it proves wrong, and the system is designed so the model can be changed later.
Where each model and tool sits today.
The radar has four quadrants: the models, the retrieval and speech models around them, the platform underneath and the practices we hold to. One system can carry two models, each on the job it suits.
- Use
- Trial
- Watch
- Hold
| Entry | Quadrant | Ring | What we use it for | Why |
|---|---|---|---|---|
| Anthropic Claude | Models | Use | Long reasoning, code, documents | Hosted API. Our first choice when a mistake in multi-step reasoning would be expensive and the data may leave your tenancy. |
| OpenAI GPT | Models | Use | General reasoning, breadth, tooling | Hosted API. Strong general performance with a broad set of tools around it, chosen where those strengths fit the job. |
| Google Gemini | Models | Trial | Long context, multimodal | Hosted API. Tried where a very large context window or native multimodal input earns its place. |
| Meta Llama | Models | Trial | Self-hosted general work | Open weights. Runs on your hardware with nothing leaving the building. Check the licence terms against your use. |
| Mistral | Models | Trial | Efficient self-hosted inference | Open weights. Good cost per token on high-volume classification and extraction. |
| Qwen | Models | Trial | Multilingual work, including Arabic | Open weights. Often the better self-hosted answer where Arabic matters. Qwen3's open models are released under Apache 2.0. |
| Arabic-first open models (Falcon-H1 Arabic, Jais 2) | Models | Watch | Arabic documents and dialect | Built in the UAE and scored on native Arabic benchmarks. We have not built on them yet, and they join the evaluation set of the next Arabic-heavy job. |
| Whisper-class speech models, self-hosted | Retrieval & speech | Use | Transcription | Call audio is sensitive and its volume steady, so speech models almost always run on your side. Our own meeting transcription does, with a voice-activity model and a guard against the invented repeats that long silences can produce. |
| Local inference with llama.cpp | Retrieval & speech | Use | Small models on your own hardware | Our own meeting summaries are written by a model running on our server, so transcripts do not leave it. |
| Embedding and reranking models | Retrieval & speech | Trial | Retrieval | Mostly open weights, self-hosted. They decide which passages the model reads, and so what it can answer from. |
| ERPNext | Platform | Use | Books, CRM and operations | Open-source ERP. Our own books run on it, and an accounting-shaped build starts here. |
| PostgreSQL / MariaDB | Platform | Use | The system of record | Boring and transactional, and older than most of the things that claim to replace it. |
| Node.js | Platform | Use | Application layer | Small dependency trees, server-rendered where a single-page app would only add weight. |
| Stripe | Platform | Use | Payments | Payments settle into the client's own account, and we sit outside the payment path. |
| Isolated Linux containers | Platform | Use | Hosting | One client, one boundary, with no shared database, no shared runtime and no route between tenants. |
| Borg with off-site storage | Platform | Use | Backups | Append-only, encrypted backups, proven by restoring them and opening the files. |
| Model Context Protocol (MCP) | Practices | Watch | Connecting models to tools | An open standard for exposing tools to models. Useful, though every tool it exposes still needs the same narrow scope and the same gate. |
| A model in the money path | Practices | Hold | Not for new work | Money and state stay in deterministic code. A model may draft, and it never books, charges or refunds. |
| Raw database access for an agent | Practices | Hold | Not for new work | Agents get narrow, typed tools. A raw connection turns every mistake into a possible write. |
| Training a shared model on client data | Practices | Hold | Not for new work | Client data is never used to train a model that other clients or the public can reach. |
| Third-party scripts on pages we publish | Practices | Hold | Not for new work | This site makes no third-party requests, so it loads no trackers, no external fonts and no scripts from anyone else. |
We name what your system is built from.
SolaryxDev is an independent studio. Naming a model or tool we work with states a fact about our engineering and claims no partnership, affiliation, sponsorship or endorsement. Anthropic, OpenAI, Google, Meta, Mistral AI, Alibaba and Stripe do not partner with, sponsor or endorse SolaryxDev, and all product names and trademarks mentioned here belong to their respective owners.
We name them for the reason a builder tells you what is in the wall: you are entitled to know what your system is made of, in writing.
A new edition follows each change in our stack.
Each edition is dated, and an entry that moves ring is noted in the next one. The model named in your proposal stays fixed until you agree to a change.
Frequently asked questions
Which models and technology does SolaryxDev use, and how does it choose them?
We build on Anthropic Claude, OpenAI GPT and Google Gemini through their APIs, and open-weight models such as Llama, Mistral and Qwen on hardware you control, chosen per job and named in your proposal. For business work, the best LLM depends on whether the data may leave, the price of a mistake and the monthly cost at your volume.
Are you a partner or reseller of any model provider?
No. We choose what fits the job and name the model we used, with no affiliation, endorsement or sponsorship from any provider.
Does our data train these models?
No. Any hosted API runs on no-training terms, and only once you have approved it in writing. Data that must stay in your building goes to open-weight models on your own hardware.
Claude, GPT or Gemini: which is best for business work?
The job decides, measured on your own evaluation set. On this radar Claude and GPT are our defaults for long reasoning and general work, and Gemini is on trial where very long context or multimodal input matters.
What are open-weight models?
Models whose trained weights are published for anyone to run on their own hardware, such as Llama, Mistral and Qwen. Each comes with its own licence, which may fall short of open source, so its terms go into the proposal.