Local Models, Codex Drafts, Claude Review: What Our OVH Server Actually Runs

New to this? Start with Sovereign AI Made Simple.

Our OVH server earns its place by keeping work moving between models. A small local model sorts a request. Search finds the earlier decision. Codex prepares a draft in its own branch. Claude reads the changes, checks the evidence and prepares a release for a person to approve.

That is our batch workflow. It does not mean every application automatically chooses models in that order. Our interactive prompt hub has a separate routing policy. Keeping that distinction clear prevents a diagram from becoming a claim about software we have not configured.

We counted the work rather than estimating a productivity multiplier. The progress log contains 169 paired job intervals in the observation window, with a peak of eight overlapping jobs. That measures launched work, including unsuccessful runs. It does not mean eight large models were generating locally.

The short answers, all from our records for October 11 to 18:

• Jobs running at once: a measured peak of eight agent jobs, on a server reporting 48 logical CPUs.
• Local model work at once: up to four requests in parallel per loaded model, with at most three models loaded, by our Ollama settings. The memory indexer shares four embedding workers.
• Work finished: 169 paired jobs (83 Codex, 47 Claude, 39 unlabelled) and 25 new posts integrated on this site in under seven days.
• How much more than before: we did not measure a baseline week, so we will not put a multiplier on it.

Download the routing and concurrency playbook (.md). It includes job and review templates, memory rules, desktop guidance and the tested log calculator.

What runs locally today

Our October 18 inventory contains nine model names. Some names share underlying weights. Installation, gateway availability and selection by an application are separate facts.

The live identifiers include hermes3-projects:8b, tev1:4b and nimble:latest. Their roles come from the caller and operating records, rather than guesses based on their names. Hermes 3 is also distinct from the separate Hermes Agent software discussed in our agent memory article.

The typed router starts with tev1. Low mode confidence can send the decision to Nimble. An error can fall back to the tiny Qwen model and then ordinary rules. This decides how to handle a request. It does not authorize a production change.

The project gateway validates exact supporting source quotations. A separate desktop entry point requests citations without that same validation. Entry points use the project variant or ordinary Hermes, so we do not assume every project question uses the customized variant. Quotation checks cannot prove that an interpretation is correct.

The October 16 Qwen screening found useful bounded outputs and unsupported claims in longer summaries. Both new Qwen aliases eventually passed gateway checks, after earlier attempts rolled back. The prompt hub's default model selection was left unchanged. An available coding model is an option to evaluate, not a reason to replace the working router.

Qdrant holds the searchable memory vectors. It is a database, not another language model. Our older project-answer work used SQLite text search; that history should not be rewritten as an earlier Qdrant deployment. The server build guide explains the layers.

Give each tier a clear job

We keep repetitive preparation close to the files. Ordinary code checks hashes, dates and allowed values. A local model can extract fields or propose a category when simple rules are insufficient. The embedding model makes searchable representations of approved documents. Search returns pointers to evidence that the next worker must read.

Codex, using our ChatGPT subscription sign-in, handles the longer production queue: research, drafts, code changes, scripted builds and renders. Each assignment gets its own checkout or worktree, branch, brief and result record. Its local tools run on our server; the hosted model still receives the context supplied to it. Local storage alone does not make the whole workflow private inference.

The review tier gets the diff, result record, source list and failed checks. Claude, or another capable review model, verifies the claims, repairs problems and merges compatible changes. A person approves the production release. We keep subscription access separate from separately billed APIs behind LiteLLM. Supported CLI sign-in does not turn subscription usage into API credit. Codex scripting documentation describes the non-interactive interface.

The prompt hub serves a different need. Its recorded interactive engine order is Claude, Codex, then local fallback. Our choice to send a batch of drafting briefs directly to Codex does not change that configuration.

Review can ask the expensive model to generate less material. It can inspect an existing patch instead of writing the first implementation, collecting every source and rebuilding the package itself. Attention can also focus on the remaining decisions when mechanical checks have already removed routine defects.

That is an operating reason, not a measured token saving. Review may still require reading the original evidence or replacing a weak draft. We have no controlled generation-versus-review baseline, invoice comparison or reviewer attention timer.

This week's handoffs make the pattern concrete

On October 18, the Social Desk work and the kickstart desktop layer started together. One prepared guides and a generalized starter kit. The other added an opt-in layer to existing setup scripts and regenerated their article examples. Separate files and branches let them proceed independently before integration.

Git records the Social Desk draft at 04:06:53 UTC and the reviewed release commit at 04:13:42. That is a gap of 6 minutes 49 seconds between commits. It is not a stopwatch measurement of review labor. The result record also identified Windows execution that the Linux drafting job had not tested. A review needs to preserve that limitation or close it with evidence.

The GPU comparison and continuity updates used the same arrangement earlier that morning. The reviewer corrected presentation and rebuilt an archive left inconsistent with its edited guides. The continuity material retained an important qualification: interrupted disposable sessions recovered in tests, but the new path through a real reboot remained unproven.

The October 16 a16z article work shows why review is more than approval. Drafts became an overview, an integration guide and trade companions. Review restored necessary compound-word hyphens and checked where a proposed integration had been described too confidently. Parallel branches still required careful merges. Their repeated copies of existing content were not six independent replacements of the same files.

Memory should reduce repeated investigation

Our memory index separates operating notes, handoffs and audit material into three Qdrant collections. It uses a pinned copy of nomic-embed-text so an ordinary model update does not silently change the vector space underneath existing documents. Qdrant requires compatible vector dimensions and distance settings within a vector configuration. Collection documentation.

The implementation splits text into 1,600-character chunks with 200 characters of overlap. Source references survive chunking. A content hash identifies changed files. Checkpoints save progress after each file, replacement removes old points, and deletion removes stale entries. Nightly refreshes and startup recovery keep the index useful without rebuilding everything.

Those are our chosen settings, not universal optimums. A table, correction or exception can cross a chunk boundary. Search finds candidates; it does not certify completeness. We combine semantic search with exact text search and read the underlying records before writing.

The current indexer shares four embedding workers across its source jobs. Three collections do not each get an independent four-request allowance. That shared bound matters when background indexing and interactive requests use the same model server.

The Ubuntu desktop is our workbench

The webtop gives us a full Ubuntu desktop reachable from another computer or a phone. We can open files, edit a page, inspect a browser and work in terminal sessions beside the repositories, models and memory index. The desktop launcher can connect to a host-side coding session; the desktop container and the host are distinct execution places.

For data work, we can keep CSV, JSON, catalogs, ledgers and index rebuilds on the server instead of copying each batch to a laptop. A terminal next to the data can run the refactor, inspect a small sample and record validation. This is a practical use of the workbench, not a measured speedup over a laptop.

One documented edit improved terminal preferences, launchers and the mobile clipboard interface. Tests moved synthetic text into a temporary terminal and back to the phone-layout preview. That is evidence of a usable editing path. It does not establish that physical phone clipboard prompts work on every device. The records do not prove a catalog refactor was driven through the graphical desktop, so we do not claim one.

Persistent terminal sessions help when the viewing connection drops. Reboot recovery needs additional checkpoints and testing. Keeping the workspace together also gives us one place to organize backups, although a backup on the same disk is not off-site recovery.

Signed-in Linux Chrome can handle approved account work while keeping the Windows PC free. The owner signs in. A browser controller checks that it selected Linux, and only one controller drives that browser at a time. Platform terms and confirmation requirements still apply. Desktop browsers, builds and local models share the same memory and CPU budget.

Optimize the queue before buying more capacity

The October 12 configuration record sets OLLAMA_NUM_PARALLEL=4 and OLLAMA_MAX_LOADED_MODELS=3. These are serving limits, not a promise that three arbitrary models fit with four requests each. Longer contexts and parallel slots increase memory requirements. Ollama's FAQ explains both controls.

A recorded warmer keeps tev1 ready for frequent decisions. Nimble is loaded on demand. Request-level keep-alive settings can avoid repeated cold loads, but keeping every optional model resident would compete with the desktop and other services. Our larger Qwen models should not all become permanent residents merely because their weights fit on disk.

Quantization helps the weights fit. Context, request slots and runtime overhead still count. In the published October 13 short Qwen 2.5 test, aggregate output rose from 39.15 tokens per second at one request to 103.98 at four. Each condition had two warm batches, a 2,048-token context, 24 requested threads and a 64-token output cap. Individual batches took longer at four requests. These are short synthetic throughput results, not long-answer capacity or task accuracy. Full test and limits.

Research jobs also need dependable retrieval. Our rule tries direct access and checks the alternate route for every planned page, with a passive browser read if those attempts cannot supply readable content. It records the original access problem and which route supplied readable content. We never treat a challenge page as the article, or interact with a CAPTCHA. Pace by origin across all jobs, and report every planned page's coverage.

Gates handle what code can check: syntax, missing links, generated-example drift, privacy, prohibited punctuation and output format. They reduce preventable review work. They cannot certify facts or judgment.

Our launchers record queued, start and exit events and can wait for dependencies. Their exit-line test does not itself establish success. A failed prerequisite, stale exit from an earlier run or unfinished background service needs an explicit completion check before dependent work starts. Readers should improve those checks before copying the pattern.

How much actually ran at once?

Our October 18 resource snapshot reported 48 logical CPUs, 94 GiB total memory, 34 GiB available and 999 processes. Load averages were 2.24, 2.82 and 2.86. That is a brief observation at 04:21:52 UTC, not a capacity benchmark or permission to launch hundreds of workers.

The progress-log calculation paired starts with exits, kept resumed jobs as one interval and ignored unmatched starts. It sorted exits before starts at equal timestamps. The measured peak was eight overlapping paired jobs, reached October 12 at 02:43:15 UTC. Hosted-agent intervals include time waiting on remote models, tools and people.

The window runs from October 11 at 13:14:57 to October 18 at 04:20:40 UTC, so its first and last days are partial. Jobs cover multiple kinds of work and sites. The post column concerns this site's main branch, counts additions once and excludes detected renames. It measures integration for publishing, not independently verified deployment times for all 25 posts.

Of 169 paired intervals, 83 explicitly identify Codex and 47 identify Claude. Another 39 lack launcher labels. We leave them unassigned. Median elapsed duration was 12 minutes 54 seconds; the longest was 2 hours 25 minutes 52 seconds. Another interval included an owner sign-in wait. Failed and terminated exits remain in the count.

Git contains 49 commits with Codex co-author credit and 59 with Claude credit in the same window; 16 have neither matching trailer. Credits describe recorded contributions, not independent jobs or labor hours. The table shows output, but cannot tell us how much more we achieved than a comparable manual week. We did not measure that baseline.

Start with a small, inspectable system

We would begin with one local model, one embedding model and one queued drafting job. Give each job an acceptance test, an owned branch and a result record. Add a review step before adding more workers. Use the desktop for inspection and edits while ordinary scripts handle repeatable transformations.

For our shared server, routine parallel work stays below about half the logical CPU count with more than 20 GiB available. Optional inference probes require stricter admission: load below 8, at least 25 GiB available and no build or deployment running. Those are our operating guardrails, not vendor specifications. We ran no new inference probes for this article because equivalent records existed.

Ollama slots, available memory and CPU constrain local inference. Hosted plans add their own session or weekly allowances. More local threads do not increase those allowances. Check the current Codex usage rules and Claude limits, rather than treating today's plan as unlimited capacity.

For a small service business, The $20 Dollar Agency is the book on building a repeatable offer. The operating habit here is equally practical: make the next piece of work small enough to check.

Download the playbook and measure your own queue before increasing it.

Fact-check notes and sources

• Our model inventory and limited model-metadata reads were made October 18, 2026, at 04:23:37 UTC. Roles were checked against the October 16 benchmark and final gateway acceptance records, current caller code and warmer configuration. Earlier rollback records were also read. No inference was run for the inventory.
• Our October 12 parallelism acceptance record and current memory-index implementation supplied serving settings, shared workers and chunking. The last completed index status was dated October 18 at 03:40:26 UTC. These are our operating observations, not vendor defaults.
• Our October 13 tuning record measured the short generation batches at 21:42 to 21:44 UTC. The published local-model test preserves its conditions. Desktop editing evidence comes from the October 13 clipboard acceptance record, observed at 22:25 to 22:28 UTC.
• Our progress-log snapshot at October 18, 04:20:40 UTC supplied all 549 lines to the downloadable calculator. Git analysis used the same window and the fetched main revision. October 16 article handoffs and October 18 Social Desk, kickstart, GPU and continuity handoffs supplied the examples. Commit gaps describe chronology only.
• Official documentation read October 18, 2026, at 04:20:27 to 04:20:32 UTC: Ollama configuration, Qdrant collections, Codex non-interactive mode, Codex pricing and usage, and Claude usage and length limits. Five pages planned, five measured directly and checked through the alternate-route service, zero unmeasured. No access block occurred.

Related reading

• The work around the model
• Build your own AI prompt hub
• Small quantized models and measured concurrency
• CPU server versus GPU hosting costs
• Safe updates and session recovery

This post is informational, not technical consulting advice. Mentions of OVHcloud, Ubuntu, Google Chrome, Ollama, Hermes 3, Hermes Agent, Qwen, tev1, Nimble, nomic-embed-text, Qdrant, SQLite, LiteLLM, OpenAI, ChatGPT, Codex, Anthropic, Claude and a16z are nominative fair use. No affiliation is implied.