Odysseus Separates the Agent Harness From the Model It Runs

Alejandro AO describes Odysseus as a self-hosted AI workspace that can connect to different language models rather than depending on one provider. It combines chat and agents with tools, document and research features, email, notes, a calendar, memory, and reusable skills. Its interface can connect to models through APIs or to local models, and it can also use tools exposed through MCP servers.

That distinction matters: Odysseus is not itself the model. It is the application that coordinates the model, its tools, and the information passed between them. Alejandro says installing it takes some technical work: the setup involves cloning the GitHub repository and running a Docker container on your machine. Once it is running, the user can add a cloud provider or connect a local model.

The interface offers a broad set of features, though Alejandro’s demo also shows how much depends on the setup. He finds that the application searches the web after he asks the model simply to introduce itself, returning results about Adele’s song “Hello” and Hello! magazine. He also spots a model-recommendation problem: Odysseus’s Cookbook lists an embedding model as the top choice for his hardware, even though it is not a model for powering a chat application. He likes the feature’s premise—scanning a machine and recommending models—but the result illustrates why recommendations still need scrutiny.

PewDiePie’s project pairs this workspace with Ajax, described on its website as a fine-tuned Qwen 3.5 9B model trained for Odysseus. The stated aim is an always-on agent for tasks such as web search, browsing, email, and calendar management, with the work done privately. Alejandro treats the project as two related engineering problems: building an application that can use tools, and getting a comparatively small model to use those tools reliably.

An agent harness is the software around a language model that supplies context, exposes tools, and manages repeated calls. The model receives a user request along with information such as a system prompt, tool definitions, relevant memories or files, and the conversation transcript. It can answer directly, or decide that it needs a tool—for example, to search the web or read a file.

When the model requests a tool, the harness runs it and sends the result back to the model. The model then decides whether it needs another tool or can answer the user. That cycle continues until it produces a final response. A tool can be a program or function that performs an operation; Alejandro’s description is broad: if something can be done in code, it can in principle be made available as a tool.

The harness determines much of what the model sees and how the loop proceeds. The tool definitions tell the model which actions are available and what inputs they require. Memory can supply relevant information from earlier interactions, while files can provide material for the current task. The transcript records what has happened so far: user messages, assistant messages, tool calls, and tool results. In the diagram Alejandro uses, that accumulated transcript is sent back with each step, so it grows as the agent works. The available context has a size limit.

Different applications manage context and memory differently. Memories may be extracted from previous conversations or supplied from other sources, and an agent need not include every memory in every call; it can select what is relevant to the current interaction. System prompts also vary by application. Alejandro points viewers to Anthropic’s published Claude system prompts as an example of prompts that can be read publicly.

The harness is the wrapper that coordinates the calls.

The model is only one part of the system. The harness also controls how the user makes a request, which tools are available, and how their results return to the model. In Odysseus, some tools can also be used directly through their own interfaces. Alejandro demonstrates a calendar interface where a person can create an event manually. He sees value in that arrangement: an agent may act on an application, while the user can still interact with the application’s interface themselves. He connects this pattern to MCP servers, which let agents work with existing applications such as Notion or Airtable.

“Running locally” can refer to different parts of the system. Odysseus can run in a Docker container on your computer, making the application itself local. But if it sends requests to a cloud model, the model is still running elsewhere and the data has to leave the machine.

Alejandro’s demo makes the distinction concrete. He uses Odysseus with Mistral Large through OpenRouter, which he believes routed the request to Mistral’s API. In that setup, the local application sends data over the internet to an inference provider and receives the model’s response. The same exchange happens during each iteration of the agent loop, including when tools have returned results and the model is called again.

With a local model, the model’s computation runs on the user’s hardware, so, as Alejandro describes it, the data stays there. He identifies privacy as one reason people choose local models, even if a cloud provider has protections in place: the data still leaves the computer. Local models can also work offline, avoid per-token bills, allow more control and customization, and be fast for small, self-contained tasks. But local does not mean costless: the user supplies the hardware and pays for the electricity.

Model choice depends on that hardware. Alejandro directs viewers to Hugging Face to find open models and filter by task and size, and cautions that the model a machine can handle depends on its capabilities. He uses his own Apple M4 Max with 36 GB of memory to demonstrate hardware-compatibility information on model pages. For a Qwen 3.8 27B model, the page recommends Q4 quantization for his machine; a smaller Qwen 3.5 0.8B model can run in BF16, which he describes as the unquantized version.

Quantization is part of the practical trade-off: model pages can list different versions with different sizes, and the best fit depends on the machine. Alejandro also shows llama.cpp as one way to run downloaded models, with a Mac app that recommends models for the computer. Once a model is running, it can be connected to Odysseus or another agent application. The harness’s basic loop stays the same; the local model takes the place of the cloud model.

Ajax is described as a fine-tuned Qwen 3.5 9B model. Alejandro’s explanation for why fine-tuning might be useful is that an agent that works well with a powerful cloud model may become unreliable when switched to a smaller local one. In his account, the larger model—whom he refers to as “Astra” in describing the existing setup—handled tool selection reliably, while Qwen 3.5 9B might miss tool calls or choose incorrectly. He says he does not know whether PewDiePie tried another remedy: simplifying or refining the tool definitions to make them easier for a smaller model to follow.

Fine-tuning offers another route: train the open model on examples of the target behavior. For an agent, those examples are traces—full interaction histories showing the user request, the assistant’s messages, tool calls, tool results, and final answer. The most useful traces, Alejandro argues, are from the same harness or have been converted to match its format. A model trained on examples of the relevant tool-use pattern may become better suited to that particular setup.

The first step is collecting traces. One option is to use public datasets on Hugging Face, where users can search for agent traces and tool-calling examples. Another is to run a stronger model in the intended harness and record its successful runs. If those traces will be shared publicly, Alejandro warns users to remove credentials first; datasets can also be kept private.

The second step is cleaning and formatting the data. Public traces may not match the target harness, so they may need to be converted before training. The third is fine-tuning the model. The fourth is evaluating it inside the harness, using held-out tasks. Alejandro’s whiteboard proposes measuring whether the model makes valid tool calls, chooses the right tool and arguments, and completes the task. If performance is not good enough, the loop returns to the data: fix it and train again.

The training data need not come from the same kind of model in every case. Alejandro speculates that PewDiePie may have wanted to use successful traces from a stronger model in his existing agent. But he says that, according to what viewers learned from PewDiePie’s video, attempts to extract OpenAI reasoning traces led to two bans. Alejandro’s account is that OpenAI does not provide the full generation, including reasoning tokens, through its API or subscription, and that such traces matter for this kind of training. He suggests that open-weight models whose reasoning is visible, naming DeepSeek and GLM, could be used instead. This is presented as a possible alternative, not as a confirmed account of what Ajax’s training used.

There are therefore two broad data routes in Alejandro’s explanation: start with available agent-trace datasets and adapt them, or collect traces by running a capable model in the target harness. Either way, the goal is not simply to make a small model generally smarter. It is to improve its behavior in a particular agent setup, then check whether it actually calls the right tools and finishes tasks more successfully.