SlyOSBelto Inc. · What we build

A model that lives on your phone and learns you.

Local inference by default. Cloud escalation only on low confidence. Identity held in a user-readable document.

For Charles Ferguson · EWOR · Updated 4 November 2026
4 new research papers ↗
SlyOSWhy now · The bill

Price per token falls. Total spend rises.

Indexed · 2023 = 100
2023
2024
2025
2026 · agents
price per tokentokens produced
−96%
price per token since 2023
32×
tokens produced · agents, not chat
↑
total inference spend · rising
$0
cloud API cost per local inference — local compute still uses energy
Price index from published cloud rates. Volume reflects the shift from chat to agentic workloads.
4 new research papers ↗
SlyOSWhy now · Context

Context windows are bounded. Memory is not.

Context window · 2024
128K
Context window · 2026
1M
Your messages · one year
~4M
Everything you read · one year
~60M
A life of correspondence
~2B
log scale · tokens
Bounded
Every window has a limit. Personal history does not.
Re-billed
The full window is sent and charged on every call.
Lossy
Content past the limit is dropped, not retained.
Persistent state
SOUL: kilobytes, editable, portable across models.
4 new research papers ↗
SlyOSWhat Muse proved

Muse: demand confirmed, trust unsolved.

Proved
Users accept an agent acting inside their messages.
Agent-in-messaging is validated demand.
Broke
Trust and privacy, which cannot be retrofitted.
All traffic server-side. Identity inferred, not held. No inspection, edit or revocation of what was learned.
Our design: inference on device, identity in a user-held document, cloud as an auditable teacher.
4 new research papers ↗
SlyOSFrontier comparison

Everyone sells one of two things: a longer window, or a weaker local model.

A longer window
Memory is context. It is capped, server-held, and not yours.
ChatGPT· 1M tokens, server memory
Claude· projects, long context
Gemini· account-wide context
Personal AI· a cloud model per user
Rewind · Limitless· total recall, cloud transcripts
A weaker local model
Private, but it learns nothing about you.
Apple· on-device, generic
Gemini Nano· on-device, generic
Muse· proved delegation; broke on trust
A document you hold
Identity as an editable file. A small local model acts from it.
SlyOS · user-held, portable, inspectable
Measured · runtime, LoRA, the document
Proposed · the compile loop
The open position:identity that is neither a window nor a weaker model — a document the user holds, that a local model acts from.
4 new research papers ↗
SlyOSArchitecture

Teacher training on Mac. Memory across two models.

measured · within stated scopestill open
Execution path · every prompt
Device profile
RAM · thermal · NPU
→
Quantised local model
0.5–3B · 4-bit
→
Cached text-state reader
typed document as prefix
→
Personal LoRA
style + teacher training
→
Qualified routing
4 real routing calls
Learning path · over time
Typed edits
host-controlled · rollback
→
Automatic update
from approved outputs
→
Teacher targets
32 checked examples
→
Adapter training
48 updates · Mac
→
Same-family state
Qwen 1.5B ↔ 3B
What remains:Automatic corrections, calibrated confidence and the complete phone loop. Green blocks were measured in separate tests.
4 new research papers ↗
SlyOSStep 1 · Read the hardware

The SDK profiles the phone, then picks the model.

RAM available
10.86 GB
Storage free
48 GB
Battery
71%
Thermal headroom
45 s at full clock
NPU · the phone’s AI chip
45 trillion operations / sec
Galaxy S25 · profile built in under a second
7B · 4-bit (compressed)
3.7 GB · does not fit beside the OS
no
small · 4-bit (compressed)
1.9 GB peak · 20 words per second · fits
load
1B · 4-bit (compressed)
0.26 GB · >40 words per second · too shallow for you
fallback
4 new research papers ↗
SlyOSStep 2 · Route the prompt

Easy stays home. Difficult goes up — and comes back smarter.

Prompt
"does the 14th still hold?"
Router
qualification · device limits · privacy · latency
Local model answers
approved checkpoint · local answer
Cloud teacher answers
hard reasoning · long context
↑ student logit-steers
the cloud LM
↓ output distils
into the adapter
Routing ran: approved checkpoint → local; rejection or memory edit → teacher. Four real calls on Mac. Cloud logit access and a repeated phone learning cycle remain open.
4 new research papers ↗
SlyOSStep 3 · Teacher and student

The teacher trained the local student.

32 / 32
trained student · 1.5B
16 / 32
same model · untrained
Complete correct JSON replies · SDK paper ↗
Target: on the phone
Student
Base model · frozen
LoRA adapter · trained on your replies and teacher drafts
→
low confidence
escalates
←
outputs return
as training signal
Target: cloud teacher
Teacher
Handles low-confidence requests · student-steered decoding
48 LoRA updates on Mac. 32 fresh fictional profiles: exact values + valid JSON, current facts supplied. The gap may be largely output format, an unquoted UNKNOWN. Full phone loop still open.
4 new research papers ↗
SlyOSEvidence · Steering

One judge preferred the steered 72B over history prompting.

Pre-specified comparison · 40 items
27
wins
7
losses
6
ties
Retrospective split: 35 · 1 · 3. Second person: no preference shown.
Setup
3B student + personal LoRA biases the 72B teacher’s logits at each token. Baseline: the same 72B, prompted with the user’s message history.
Limits
Run on an M5 Pro laptop, not deployed cloud inference. The judge built the system and identified 38 of 39 steered replies after exposure; a no-emoji rule scores 35 of 35. Steering is not isolated from profile and history. A second person showed neither preference nor non-inferiority. Generalisation is open.
Why it matters:the personal model does not have to be large. It has to be present at decode time — which requires logit access.
4 new research papers ↗
SlyOSWhere knowledge lives

Four kinds of knowledge. Four stores.

RAG · retrieval
Facts
World knowledge. Changes often. Not user-specific.
retrieved on demand from a server index · the query stays on device
CAG · cached prefixes
Quick responses
Repeated responses.
computed once, cached · 210 ms
Context
The situation
The current thread, time and screen.
the context window, used for transient state
SOUL
Writing & style
Register, relationships, commitments.
a typed document · editable, revertible, portable
Loading all four into the context window is slow, expensive and lossy. Separating them is what makes a 3B model sufficient.
4 new research papers ↗
SlyOSStep 4 · The document

Your memory now works on two model sizes.

# soul · v41 · 2.1 KB
voice.emailfull sentences · named sign-off · dates attached
voice.slacklowercase · no greeting · ≤ 12 words
person.danainvestor · replies before 10am · cc Rachel
promise.ilanhandover doc before Thursday
neverconfirm payment details without a second look
# every line: source · date · approved by you
InspectRead and edit the state the model receives.
CorrectLive demo: Lisbon → Porto → deleted. Both comparison arms followed the edits.
RevertRoll back. Style lives in the adapter; facts and context stay in text.
Migrate32/32 correct on each model. One exported SOUL, Qwen2.5-1.5B and 3B. Fresh fictional profiles on Mac; state transfer, not adapter transfer.
210 ms
first token · kept-ready answer
1,449 ms
without it
4 new research papers ↗
SlyOSOver time

The phone takes over, one answer at a time.

Share of prompts answered on the phone
month 0 · 10% (illustrative)
month 12 · 80% (illustrative)
Teacher
answers less and less
Adapter
grows with every hard answer
SOUL
stays small, stays readable
Tokens leaving the phone
→ 0
4 new research papers ↗
SlyOSMeasured

Can a phone do this? Four numbers, one Galaxy S25.

Fast enough?
53 tok/s
generation, 4 threads, Power saving off.
1.5B · Q4
Fits beside the OS?
2.01 GiB
peak resident; the phone exposes 10.86 GB.
1.5B · Q4
Good after compression?
0.1
perplexity lost at 4-bit — measured on desktop, not phone.
7B · runtime §5.5
Sustainable?
45 s
back-to-back decode before thermal throttling.
1.5B fig. 61
On-device training: the first schedule (20 s on / 90 s off) failed. A later 0.5B rank-8 LoRA schedule (20 s train / 200 s cool) reached 232 / 236 / 225 steps. A full adaptation cycle and its energy cost remain unproven
Runtime measured.Full SOUL loop not yet run on device.
4 new research papers ↗
SlyOSEvidence

What worked. What failed. What is untested.

Worked
Teacher → student: 32/32 vs 16/32
correct JSON replies · 32 fresh fictional profiles · gap may be output format
Same SOUL → two Qwen sizes
32/32 each · state transfer on Mac
Routing + revocation ran
4 calls · local, reject, correct → teacher
3B steers 72B · one judge: 27 wins / 7 losses / 6 ties
S25 inference · 53 tok/s; typed edits + rollback
Failed
Document → adapter compiler lost to a matched text reader: 78.0% vs 96.7% strict style adherence
On-device training: 232 / 236 / 225 steps on 20 s train · 200 s cool — full cycle and energy unproven
Cross-model transfer pilot stopped
Untested
Calibrated confidence · rising local share over time
Automatic update from approved outputs
Teacher → student distillation at scale
Cross-family and phone migration of the document
Steering with real logit access to a deployed cloud model
Why the design moved:compiling the document into weights lost to reading it. So: shared reading of a typed document, plus controlled personal adaptation.
4 new research papers ↗
SlyOSOpen problems

Three problems the first year of engineering has to solve.

01
Training a phone can sustain
20 s train / 200 s cool reached 232, 236 and 225 steps on an S25. A complete adaptation cycle, and its energy cost, have not been shown.
02
Steering a deployed model
Proxy-tuning needs per-token logits. One judge’s 27 / 7 / 6 result ran against a 72B on a laptop; no public cloud API exposes the logits it requires.
03
Updating without drift
Today every change to the SOUL is a typed, host-controlled edit with rollback. Automatic update from approved outputs is designed, not built or evaluated.
Each has a measurable gate.A sustained cycle on device · a steering win against a real endpoint · an automatic update that holds style without regression.
4 new research papers ↗
SlyOSWhere it goes

A phone with no widgets.

One prompt. One agent that knows you, running on the device. The apps become its tools.

YouPersonal agentApps & tools
› what should happen?
4 new research papers ↗
SlyOSTeam

Who is on the call.

Emil Shirokikh
Founder · CEO
Author of both papers — the edge runtime and the SOUL Blueprint. Stanford GSB Ignite, UC Riverside MBA, mathematics and economics. Enterprise programmes at Capgemini.
Anna Gong
Advisor · Founder & Chairwoman, Perx Technologies
Scaled Perx to 20+ markets and 70M+ users; raised US$25M+ as a solo founder. Advisory Board, Duke Corporate Education · former board, GeniusU (to NYSE) · YPO Global Board · IASE AI.
Research and go-to-market, one table.Runtime paper + four SOUL research drafts · 20 years scaling enterprise software across APAC, EMEA and the US.
4 new research papers ↗
SlyOS

Small where it can be. Cloud only when it must.

REVISED PAPERS · 4 NOVEMBER 2026 · RESEARCH DRAFTS
Runtime paperOn-Device LLM Inference at the Network EdgeSOUL papersDownload all four new papers ↗Productslyos.worldEmailemil.shirokikh@belto.world
4 new research papers ↗
SlyOSAppendix · Measured vs proposed

What is measured, and what is proposed.

Measured · S25 / M5 Pro
53 tok/s generation, 1.5B Q4SOUL Blueprint
0.72 / 2.01 / 3.78 GiB RSS · 0.5B / 1.5B / 3BSOUL Blueprint
30 s gaps: stability criterion met; 0 s: stoppedSOUL Blueprint
0.5B LoRA step 3.56 s on phone CPUSOUL Blueprint
Teacher-trained 1.5B: 32/32 vs 16/32 bare32 fresh profiles · may be format
One SOUL on Qwen 1.5B + 3B: 32/32 eachSOUL Blueprint
Limits, failures and remaining work
Document → adapter compiler lost to matched text reader: 78.0% vs 96.7%SOUL Blueprint
Canonical front end: 0.0013 vs 0.005 gateSOUL Blueprint
On-device training: 232 / 236 / 225 steps · 20 s train / 200 s cool · full cycle unprovenSOUL Blueprint
C7 transfer stopped; combined V2 also failedSOUL Blueprint
Routing / rising local share4 calls / growth untested
Steering vs deployed cloud (logit access) · energyno experiment
Local training measured. Full phone loop open.Full claim ledger · SOUL Blueprint (12 chapters), Appendix A.
4 new research papers ↗
SlyOS/ Appendix · Methods

Five mechanisms. Each has a different job.

Separate what the model knows about you from how it answers and where it runs.
Versioned memory
Owner-approved append / correct / delete. Retrieve current, permitted facts into a bounded prompt.
Facts stay editable; source and history remain auditable.
Context + KV cache
The model reads selected text. Attention caches reuse computation during decoding.
Text conditioning and caching; not a document-to-weights compiler.
Teacher → LoRA
Check teacher examples, then train a small low-rank adapter while the base stays frozen.
A measured structured-reply gain on a small local model, possibly output format.
Logit steering
On the teacher route, add the adapted guider’s token-score change to the target’s scores.
Personalization without retraining the target; needs logits access.
Qualified routing
Allow local only for evaluated requests, matching state/model identities and an eligible device.
Permission backed by tests; not model-reported confidence.
The boundary: host-controlled state and permissions surround learned generation. Automatic correction proposals remain unqualified.
4 new research papers ↗
SlyOS/ Appendix · Request pipeline

One request. Two controlled execution paths.

Python contract: SoulApp → Soul / qualification adapter → supervised native backend.
01 →
Receive
Question + scope
Authenticated, idempotent request
02 →
Read SOUL
Versioned state + permitted sources
Token-bounded current context
03 →
Check permission
Exact evaluation approval
Model identity + device eligibility
04
Serve + record
Raw response + chosen route
State-bound receipt
QUALIFIED LOCAL PATH
Trained 1.5B → answer
One model stream. No local logit steering.
Error or explicit validator rejection can invoke the teacher.
TEACHER PATH
Target + personal logit delta → answer
z = z3B + 0.5 × (zadapted 1.5B − zbase 1.5B)
Three KV streams; shared vocabulary. Cloud logits access remains open.
Owner edit → revoke local approval. An unseen request under an active exact-cohort approval is refused. Device eligibility alone never grants quality approval.
Evidence: four earlier routing calls ran. This corrected trained-first route is implemented; its new operational probe has not run.
4 new research papers ↗
SlyOS/ Appendix · Learning pipeline

Teaching is a checked job, not a side effect of chat.

CohortLearningCycle → DualRouteNativeRuntime.train_profiles() → fresh evaluation → explicit approval.
01 →
Collect teacher replies
Save raw trajectories as unverified candidates.
02 →
Qualify the whole bank
Every target must pass the task checks. No repair or cherry-picking.
03 ↓
Train a LoRA adapter
Frozen base; separate admitted job. Save checkpoint + receipt.
06
Approve exact scope
Independent audit + explicit host approval. New state revokes it.
05 ←
Evaluate fresh profiles
Fixed checkpoint. No training on heldout cases; compare teacher + bare base.
04 ←
Freeze before evaluation
Bind model, tokenizer, prompt, decoder and checkpoint identities.
PROMOTION GATES
≥32 profiles · student ≥90% · ≤2 percentage points below teacher
At least bare-base accuracy · zero protected violations · independent audit
Trained-first approval also requires teacher ≥90%
Measured: 48 training updates; later 32/32 complete JSON replies versus 16/32 bare, possibly a format gain. Repeated autonomous improvement remains open.
4 new research papers ↗
SlyOS/ Appendix · Stack & boundaries

What is actually running, and where.

Research prototype today. The phone is the intended destination of the same state-and-routing contract.
App / HTTP clients
JavaScript · fetch
Swift · URLSession
Kotlin · HttpURLConnection
Service clients. Swift host type-checks; Kotlin device validation remains. These are not phone inference kernels.
Host SDK / state
Python · SoulApp / Soul
Typed JSON event history
Hashes · locks · request receipts
Memory import/export transfers state. It does not transfer adapter weights, credentials or approval.
Model execution
Mac: Python + MLX native compute
Qwen2.5 · LoRA · supervised jobs
Mac inference and training exercised. Phone llama.cpp / C++ benchmarks are separate from these SDK bindings.
Device / safety gates
Reported DeviceProfile
Explicit ModelRequirements
One heavy worker + resource guards
Memory/runtime/accelerator checks can veto local use. No universal kernel selector or hardware attestation yet.
Today’s live demo: same bare 3B, full history versus current SOUL. Training, steering and teacher fallback are off in that comparison.
4 new research papers ↗
SlyOS Belto Inc. · Business · First application

Every promise has to survive the next message.

First market · longevity merchants

They need to sell again to the customers they already have.

A campaign, a social post and a customer reply should carry the same product facts and approved claims.

Marketing

Create content and flag unsupported claims before review.

Customer replies

Ground answers in product information and merchant policies.

Sales follow-up

Prepare relevant outreach and next steps for existing customers.

Checks against approved claims, applicable FDA requirements and processor policies, including Stripe where relevant. Review controls support decisions; they do not confer approval.
SlyOS Belto Inc. · Business · Distribution

The processor opens the door.
The merchant buys.

01 · Distribution partner

Payment processor

An existing network of merchant relationships.

SlyOS offered under the partner’s branding.

02 · Paying buyer

Longevity merchant

Subscribes and connects its own customer database, product knowledge and policies.

03 · Customer relationship

Existing customers

Relevant outreach, repeat purchases and replies in one continuous workflow.

One merchant brings its customer context. Each new conversation improves what the merchant can understand and review.

Proposed channel strategy. Partner discussions are not signed integrations. Merchant database contacts are not SlyOS users.
SlyOS Belto Inc. · Business · Economics

A subscription for the merchant.
A shared incentive to make it useful.

$149per user / month

Unlimited Inbox & Brain

15 AI videos monthly
15 video compliance checks monthly
300 outreach marketing emails monthly

$249per user / month

Unlimited Inbox & Brain

45 videos + 45 checks shared monthly
+15 of each per additional paid seat
900 outreach marketing emails shared monthly

50 / 50

Subscription revenue less actual API usage and hosting costs, split with the partner and settled monthly.

Proposed partner model. Unused allowances are not incurred costs. Merchant conversion, retention and contribution margins remain to be validated.
SlyOS Belto Inc. · Business · Evidence

Early use. A commercial thesis to prove.

162

open accounts

18,994

What this does establish

People have used the product to handle messages and send drafted replies.

What comes next

Paid merchant pilots, repeat usage, retention and the cost to serve through a processor channel.

Early evidence, small samples
Snapshot: published product counters, 28 Oct 2026, 17:09 UTC. Accounts and messages are not paid merchants or channel revenue.
SlyOS Belto Inc. · Business · Execution

$1.6M to earn the next stage.

12 months

of planned execution, plus contingency and cash reserves.

Four-person team

Founder, two ML hires and business development, with specialist contractors.

Two proofs to earn

A developer-tested SDK and a paid merchant workflow with measurable repeat use.

$1.046M · operating cash need

First twelve months’ modeled cash deficit.

$214K · contingency

20% of fixed operating costs and capex.

$280K · cash buffer

Three months at modeled exit fixed spend.

$60K · fees and rounding

$24K financing fees; remaining headroom.

Target based on the existing SDK financial plan. Merchant subscriptions and channel economics still need validation. This round funds execution; the OS and phone follow later gates.