Weiming Intelligence
Work together, and leave your demonstrations and trade-offs behind. From personal knowledge to a model that is genuinely yours.
Personal model training is a planned capability; confirmed knowledge can support your work today.
Product mechanism
You give LinX intent and corrections. LinX works with models, agents and tools, and saves the material, process, results and your trade-offs into the Pod. Pod knowledge supports LinX directly; authorised material is trained and evaluated into a POM, which then takes part in LinX judgements. Xpod carries both the Pod and the POM.
Carried by Xpod
The data, runtime and asset foundation; it does not change who governs model releases.
works this way today personal model training and application, planned
Illustrative product mechanism; personal model training is a planned capability
The Pod does not only collect AI output. It also keeps the reasons behind your choices, their sources, and the situation you were in. What gets saved is bounded by your choices and authorisation.
Three short tasks with different purposes, each with its own input and a readable output. All of them are target interface examples, not run records; long-term personal models and autonomous execution are not among them.
Input: a few meeting notes and a progress list.
You paste the material in or attach it; nothing goes and collects your email.
Input: one document with a traceable source.
The sources come from the document you supplied; example sources are not retrieval results, and the product page states the actual scope.
Input: a draft, a recipient and a tone.
It returns a revision; it does not send anything for you.
The three short examples only show the range. The first one is carried through in full below.
Illustrative example
An independent bookshop, a team of two, nobody to maintain anything long term. Every example here is a design fixture, not a user case.
One choice, and the reason for it
That call becomes a proposed piece of knowledge awaiting confirmation. Until you confirm it, it joins no later task and trains no model.
Type: target interface example (Upcoming interface preview), based on the bookshop fixture in the R5 target spec. Neither the screenshot nor the text is a run record.
Records and knowledge, runtime adaptation, and a personal model each have their own success facts, and none of them substitutes for another. Personal model training: planned.
Original records, feedback, judgement cards, sources, conditions, exceptions and revisions. What you can truthfully say is “the record is saved” or “the knowledge is confirmed” — at that point no model has been trained.
Using knowledge, methods and tools you approved inside a task. What you can truthfully say is “this task used this version of the knowledge”, never that parameters have learned.
An executable model artefact produced by training or adapting on authorised material, plus its evaluation record. Only once training produces an artefact is it a candidate model; whether it gets enabled is a separate decision.
The same piece of experience goes the whole way: confirm it, decide whether it may be trained on, then test it in a new situation.
The “maintenance cost” card keeps the original words, the source discussion, the conditions it applies under, the exceptions, and every revision.
Confirming knowledge is not training consent: you select the training material separately, and state the purpose separately.
The new situation is scheduling weekly volunteers — it does not copy the answer from the sign-up question.
Both sides are compared under identical knowledge and tool conditions, and the answers are shown anonymously. There are no measured scores here, and finishing training is never a reason to enable.
Carry your context into the task, and turn what you accepted, changed or rejected into reusable experience.
Material, experience, knowledge and task facts stay somewhere you control, with location, authorisation and portability all answerable.
Connect your own application to the data, starting from deployment, identity and read/write access.
Xpod decides how your data and model assets are carried; LinX decides how you and the AI get the work done.
You do not have to install both: LinX works on its own. Add Xpod when you want records, knowledge and model assets kept with you, or read by other applications.
Only confirmed connections are listed; protocol compatibility does not mean a particular client already supports it.
Pick an entry point, connect it following the guide, then do the first thing.
Both LinX and Xpod publish desktop packages; the download page lists them by platform and chip.
@undefineds.co/linx is published on npm and runs; the Pod provider can point at your own.
The hosted entry point is pods.undefineds.co, with sign-up and quotas as that service currently states them; self-hosting needs Bun 1.3+ or Node 22+.
A desktop package, the command-line tool, or your own deployment; choose by device and habit.
You choose and configure the account and model service, and the credentials stay in your own Pod.
Take one small task and carry it through a single decision, reasons included.
Each answer gives the fact first; details live behind the links.
Not both. Install LinX to get work done; add Xpod when you want records, knowledge and model assets kept with you, or read by other applications.
Desktop packages cover macOS Apple silicon, Windows and Linux; macOS Intel has no published build. The command-line tool is on npm and needs you to supply Node.js.
You choose and configure the model service, and the credentials stay in your own Pod. The client and the self-hosting code are publicly available; model usage is billed by whichever service you choose, and the hosted service is billed as that service currently states. No prices are predicted here.
Where it is stored and where a request goes are two different things. Data is stored where you chose; with an external model the request goes to that provider.
Working today: desktop and command-line packages, storage and access, judgement knowledge and task records. Direction: personal model training, and wider autonomous execution. Every target interface on this site is labelled “Upcoming interface preview”.
Take the sign-up discussion above. Each question has a concrete answer.
Running locally, it is kept in SQLite and a disk directory on your own machine. With the hosted service, it is kept in the environment you chose.
Only applications you authorise can read it. Permission is granted per application and can be withdrawn at any time.
Export scope and format follow the documented support. In local mode the data is already your own files, so you can back it up yourself.
Where an external AI request goes is a separate question: where data is stored and which model service receives what are two different things. With an external model, the request goes to the provider you chose.
We came here from an earlier wish. Why we build LinX and Xpod, and where we hope they lead, is written in the letter to whoever finds it.
Start with one thing you have to do today, and leave the choice and the reason behind.