Free Private Intelligence

Free, Private, On-Device Intelligence

Mission

Short overview here. Technical detail comes in the sections below.

Why we exist

Useful software should not depend on logging everything you type. We want models to get better in ways that do not force people to hand over private data.

What we do

Many AI products send your text and files to a remote service. OIP is meant for models that run on your device. What you send elsewhere, if anything, is up to you.

When a model improves, that improvement can be shared as a weight update. It does not have to include your raw prompts, documents, or other private material.

Why it matters

AI is part of work and daily life. Too often the choice looks like “share everything or fall behind.” We think you should be able to keep sensitive data local and still benefit from models that improve over time.

A simple picture

  1. You run a model on your own hardware (for example in the browser with WebGPU).
  2. It answers you using context that stays under your control.
  3. If you choose to contribute, you send an update to the weights, not a copy of your inputs.
  4. Many sites can improve one shared model without pooling their raw records in one place.
Data can stay on your device. Share model updates, not private inputs. Demos run without a server round-trip. Help improve the model without exporting your files.

A different path for AI

Models do not have to be owned only by a few closed platforms. Open rules for merging updates, clear provenance, and consent matter as much as raw scale. We care about systems where people know what was shared and why.

“Protocols should widen who can contribute, not lock users in.”

Under the hood

For engineers and partners. Train where the data already sits, exchange weight updates instead of datasets, and merge with rules everyone can read.

Data stays at the edge

Sensitive text and logs can stay in the hospital, firm, or plant where they belong. Training and fine-tuning run there (or in an approved enclave). Only weight tensors and metadata leave, as defined by the protocol.

Merge, don’t mirror

Many small updates combine into one shared model with weighted averaging over chunks. The merge rules are simple on purpose so attribution stays clear and you can still split work by region or specialty.

Knowledge as a stake

Chunks can carry provenance so policies can tie access, credit, or payment to real contribution. A full marketplace is still early; the protocol focuses on the shared file formats and merge semantics first.

Why “local” is a big deal

If the model runs on the user’s machine, pricing does not have to be “per API call.” Air-gapped setups stay possible. Product choices can favor the end user instead of only the vendor’s account system. OIP describes how to keep inputs private, share weight updates when people agree, and publish merge rules in the open.

// Illustrative API shape (roadmap)—not a shipping CLI yet const myModel = await trainTransformer({ data: "s3://our-factory-logs/redacted/", architecture: "oip-900mb-stable", tokenizer: "oip-vocab" }); // Publish chunks + terms; registry records your share of the prototype const chunks = myModel.exportWeightChunks(); await oip.contribute(chunks, { prototype: "industrial-vision-coalition", region: "us-midwest", access: "consortium-license" }); // Pull the merged prototype; your local adapter stays yours const collective = await oip.getMergedPrototype("industrial-vision-coalition");

Public checkpoints include oip-300mb-lab, oip-900mb-stable, and oip-1gb-preview. Run them in the browser on kyre.ai through the 300 MB lab, 900 MB lab, and OIP Studio. Federated training and merge tooling are still to come.

Where this matters

The industries differ, but the constraint is the same. Some data cannot legally or safely go to one central training pool. OIP is for teams that still want a shared model to improve by exchanging parameters and written rules, not by copying raw databases.

Operations and supply chains

Factories and suppliers already run models on local telemetry and images. The open question is what may leave the site boundary.

  • A tier-one supplier fine-tunes on internal defect photos and publishes weight chunks; the OEM merges into a shared “line vision” prototype without ingesting the supplier’s library.
  • Regional plants keep adapters separate when regulation or contracts require it. Wider merges happen only when policy and trust allow.
  • Smaller manufacturers can share weight updates that encode process knowledge without emailing customer lists or formula text.

Care delivery and compliance

Health systems need models that reflect local populations without building another national PHI warehouse.

  • Each site trains on its own cohort; charts and notes stay behind the institution’s controls.
  • Specialty and service-line prototypes (cardiology, oncology, perioperative care) can stay logically separate with governance encoded in metadata.
  • Auditors and partners reason about chunk lineage and contribution share instead of asking for a copy of the underlying records.

Legal, public sector, and science

Privileged notes, export-controlled lab data, and field observations are often unsuitable for a generic cloud fine-tune. They can still train a local model, and teams can merge weights later when contracts allow.

  • Legal and policy: Retrieval and drafting assistants tuned per jurisdiction or practice group, without a shared document pool.
  • Research and climate: Sensors, notebooks, and simulations stay where policy requires. Merged weights can still capture patterns that held across sites.
  • Media and language: Tone, safety rules, and locale stay local. Separate sites can still merge adapter weights into one shared language model when they agree to. KYRE runs public checkpoints in the browser as one way to try that stack.

Knowledge as capital

A trained model is an asset, not only a UI feature. When each update is a signed, attributable chunk, you can see who changed what, who may run it, and how to pay contributors back, without relabeling every training job as a bulk data collection.

Access and policy

Licenses can name which prototypes or parties may use a chunk, including open use, credential gates, metering, or revenue splits. The idea is simple. Permission to merge or run a model is not the same thing as holding the original dataset.

Stakes that match contribution

If you know what share of a prototype’s chunks came from your batches, that number is a concrete input for governance and payment, within your own contracts and law. The protocol records contribution and merge rules. It does not replace lawyers.

Quality and impact over time

Evaluations and production metrics can show which updates helped. Missing domain coverage and real lift matter for trust, not only who spent the most on compute.

Incentive alignment

When merges and shares are logged in the open, a better shared model can still help your install. You keep local adapters, pull an improved shared base model, and you never needed to export the private texts or tables that trained your part.

Charge for better model weights, not for access to someone else’s raw files. Pooling updates builds lasting skill; hoarding identical copies of data often does not.

Hierarchical intelligence

You do not have to merge everything into a single model. Routing by region, specialty, or training loss can keep specialist models separate until a wider merge actually makes sense.

Multi-Stage Reduction

  • Stage 1 (parallel): 30 site batches → 3 regional prototypes (10:1 fan-in)
  • Stage 2 (sequential): 3 regional → 1 federation master
  • Efficiency: Reduces serial bottleneck, enables parallel merging
  • Flexibility: Keep regional models separate or merge up hierarchy

Future Extensions

  • Similarity Routing: Assign batches to prototypes by loss profile or domain
  • Mixture of Experts: Multiple specialized prototypes, inference routing
  • Cross-Model Merge: Combine models trained on different architectures
  • Temporal Layers: Layer historical knowledge with recent specializations
// Initialize K prototypes for specialized domains const prototypes = [ { id: 0, specialty: "medical", seed: "batch0000" }, { id: 1, specialty: "legal", seed: "batch0010" }, { id: 2, specialty: "technical", seed: "batch0020" } ]; // Assign remaining batches to nearest prototype by similarity for (const batch of remainingBatches) { const prototypeId = findNearestByLoss(batch, prototypes); await mergeToPrototype(batch, prototypeId); } // Result: 3 specialized models instead of 1 averaged model // Deploy as mixture-of-experts with routing layer

Who builds this

Protocol designers, ML engineers, policy staff, and the KYRE team that ships the first browser checkpoints. No one company should own the only copy of “the” model. That is the design goal.

Technical primitives

  • Merge core: Chunked weighted averaging, resumable jobs, provenance logs
  • Checkpoints: oip-300mb-lab, oip-900mb-stable, oip-1gb-preview (live on KYRE)
  • Metadata: Contribution fractions, licenses, revocation hooks
  • Coordinators: Fan-in/fan-out graphs for regional → global roll-ups

Live entry points

  • 300 MB lab: oip-300mb-lab, smallest checkpoint, runs in-browser
  • 900 MB lab: oip-900mb-stable, same WebGPU path
  • OIP Studio: Playground UI; good home for oip-1gb-preview and experiments
  • KYRE: Home for shipping demos

Researchers

Test merge code under bad or dishonest peers and uneven chunk counts across sites, and measure fairness in plain numbers.

Enterprises

Run pilots where legal already said “no” to data lakes. Measure lift from federated fine-tunes vs. isolated baselines.

Builders & guilds

Keep customer relationships and trade craft off the network while still merging weight updates that capture what general models skip.

Start today

You can run OIP-aligned models in the browser today on KYRE. Command-line federated training and public merge registries are still in progress. This section separates what works now from what is planned.

Live on KYRE (WebGPU)

// No install — open in Chromium / Chrome, allow WebGPU // 1) Load tokenizer + weights from KYRE CDN // 2) Run prefill + decode in-page // 3) Try OIP Studio for sliders / presets window.location = "https://kyre.ai/oip-300mb-lab"; // or: oip-900mb-stable @ /oip-900mb-lab , oip-1gb-preview via /qwen-studio (OIP Studio)

Use a recent desktop Chrome. Mobile WebGPU is uneven; use a laptop-class machine for the largest checkpoints.

Visit us

Updates on the roadmap, demos, and community discussion.

  • theoip.org: Project home & narrative
  • Federated CLI: Train / publish / merge tooling (in progress)
  • Registries: Public prototype directories (in progress)