Glow: a private AI that lives with the person using it

Status: public draft, 1 October 2026. This paper describes behavior and measured results. It is not an implementation specification.

What a conventional assistant does

A typical assistant is a service. The person sends text to a company. The company runs a model in its own computers, keeps the conversation, and decides who else can see it. The person's access depends on that company's account, price, and retention rules.

That model is simple, and it concentrates memory, identity, and cost in one operator.

What Glow does

Glow is Kapra's client for that person's AI. It runs as an app on the person's own device. The mobile store edition is the current shipping client. Desktop and browser clients belong to the same product family.

The split of responsibility is:

• The device holds the person's keys and the private side of their AI.
• The Kapra network does the heavy model work and returns the answer to the device.
• The person pays a published flat price per prompt, currently $0.002.
• A Glow install can help confirm the network. It does not write the next block. Block writing is a server role.

Glow is not an offline copy of a large model inside every phone. The phone is the person's node for identity, keys, and private memory. The network answers.

Privacy, as a product rule

Glow separates three kinds of material:

• Personal. Sensitive or identifying content stays with that user. It is not reused as shared knowledge.
• General. A general answer may be saved and served again only after identifying details are removed, and it is not tied to the user's identity.
• Dropped. Harmful content is not kept for reuse.

The public settlement record is there to account for use. It is not a public copy of the person's prompts.

Memory

Each person has a private memory that stays on their side of the product. Shared memory is a separate store of general answers. A later ask can be served from that shared store when the answer already exists. A new general answer can be added for later reuse. Personal content does not take that path.

One device, many devices

The shape is the same at every size. Each device is one person's AI. Devices do not become one shared brain, and they do not pool private memory.

The million-device figure is the intended shape. It is not a deployment we have measured.

Diagrams: traditional AI, Glow, one device, one hundred devices, one million devices, Kapra and Glow.

What it costs to run

A person needs a phone that can run the app. They do not need a GPU or a datacenter account.

The model computation is done by the network. This paper does not publish server sizes, bandwidth budgets, or a cost model for operators. Those measurements are not in the result set yet. See benchmarks.md.

Security, at the boundary a user can check

• Account keys are created and kept on the device.
• Personal content is not published into the shared answer store.
• General answers that are reused have identifying details removed.
• The client can take part in confirming the chain. Confirmation is not the same thing as writing blocks.

This paper does not describe algorithms, key formats, or message layouts.

What we have measured

On 29 September 2026, internal fleet runs of Glow answered at the following rates. The full table, including slower passing hours and the short peaks, is in benchmarks.md.

• Highest hour-long passing run: 122.6 answers per second, average 1.5 seconds to answer, 441,180 answers, internal correctness score 96.4%.
• Highest six-minute passing run the same day: 295 answers per second, average 0.8 seconds.
• A separate scenario run on 30 September 2026 passed: known answers matched, new answers were stored, and asking those new questions again returned the same answers.

These are our measurements. They are not an independent comparison against another lab's model.

Why the architecture matters

The person keeps their keys and their private memory. The price of a prompt is a flat published number. General knowledge can be reused. Personal knowledge stays personal. More devices add more people who can confirm the network. They do not add more companies in the middle of the conversation.

Limits of this paper

• It is not enough to reproduce Glow.
• Inference is network-served. A phone is not claimed to run a full foundation model offline.
• Correctness scores come from our checker, not from an outside audit.
• We have not published a head-to-head against a conventional API, or measurements of memory, bandwidth, or operator cost.
• Chain throughput and finality are covered only where we have numbers. Those numbers are not in this draft.

Kapra Chain: what the network is for

Status: public draft, 1 October 2026. This paper describes roles, economics, and measured behavior. It does not describe how blocks are chosen, how participants are admitted, or how data is stored.

Purpose

Kapra is the settlement network under Glow and the other Kapra applications. It accounts for payments, stored knowledge, and AI use in one system, with a flat published price instead of an open fee auction.

Glow is the client. Kapra is the network the client settles on. See Kapra and Glow.

Who does what

Confirmation and block writing are different jobs. A Glow install can join the confirmation side, where the product allows it. It does not become a block producer.

The current launch keeps block writing to servers. Consumer devices widen confirmation. They do not widen who is allowed to mint the next block.

Applications

Applications on Kapra can be written in KSL, Kapra's own language for on-network programs. This paper does not describe the language's implementation.

User-facing work, including AI prompts, is settled through the network as accounted operations. The public record shows that an operation was settled. It is not a public transcript of a person's AI conversation.

Performance

Measured Glow answer rates are in benchmarks.md.

This draft does not state a chain transactions-per-second figure or a block-finality time. Those measurements were not in the Glow result logs reviewed on 1 October 2026. They will be added only from a recorded run.

Security

• Users hold their own keys on their own devices.
• Servers that write blocks are a different set from the devices that confirm.
• Personal AI content stays with the user. General answers can be reused only after identifying details are removed.
• Harmful content is not kept for reuse.

This paper does not describe the signature schemes, the confirmation rule, or the checks a server performs.

Economics

Kapra prices user-facing operations with a flat fee, currently $0.002 per billable operation. The published AI prompt price is the same $0.002 per prompt.

A multi-recipient payment, up to 1,000 recipients, is one fee. That single-fee rule applies to that payment. It does not mean a large batch of other operations collapses into one charge.

There is no open auction for block space in this price model. The number above is the published price, not a measurement of our infrastructure cost per user.

Decentralization, stated plainly

Anyone running Glow can hold their own keys and, where the product allows, help confirm the chain. Block production stays with servers. A reader should treat "the phone participates" as confirmation and custody, not as "the phone writes blocks."

Limits of this paper

• It is not enough to reproduce Kapra, KSL, or the validator software.
• It does not claim a measured finality time or a measured chain throughput.
• Consumer confirmation and server block production are easy to confuse. The table above is the distinction that matters.

Measured results

Status: 1 October 2026. Figures below are KapraLabs measurements. This file does not describe how the runs were driven.

An outside party cannot reproduce the system from these numbers. They also cannot independently verify them until the same runs are repeated by someone else. Treat every figure as our measurement.

Glow answer rate

"Answers per second" is the number of replies the run delivered, divided by the length of the run. "Correctness" is the share of those replies our checker marked correct. It is not an independent human evaluation.

Passing hour-long runs:

The 122.6 figure is the highest hour-long passing run in this set. Earlier passing hours were much slower. The rate depends on the conditions of that run. It is not a guaranteed floor.

Passing six-minute runs on 29 September 2026:

Recorded error classes on the hour-long passes were authentication, backpressure, balance, timeout, sync, and other. All of those counts were zero on the runs in the table. That is a property of those runs, not a claim that the service never returns an error.

Glow scenario check

On 30 September 2026 a scenario run passed overall:

• Known questions returned the expected answers.
• New questions produced stored answers.
• Asking those new questions again returned the same answers.

This was a correctness check, not a capacity test.

Price

Infrastructure cost per user was not measured.

Not yet measured

Not published

• Model weights
• The Glow client and Kapra chain implementation
• How blocks are chosen
• Test questions and the way the measurements were produced
• A live prompt box. This page cannot answer as Glow.

The million-device diagram is the intended shape. It is not a deployment we have measured.