About NinaCorp
We build Tiny Agent, a desktop assistant that runs small language models entirely on your own computer. Our goal is to find out how much real work those models can do, and to tell you only what we have actually measured.
Our mission
Get the most out of small models on the hardware people already own.
Most AI assistants send your words to a data centre and bill you for it. Tiny Agent runs 1.5–14 billion parameter models on an ordinary PC through a local model server such as Ollama. There's no cloud account and no per-message cost, and your conversations never leave the machine.
Our bet is that a small model paired with a strict harness beats a large model with a loose one on many everyday structured jobs. A harness is the software around the model that decides what it sees, what it's allowed to do, and whether its output is accepted. We don't wait for bigger models. We put the engineering effort into the harness, where anyone with a consumer PC benefits.
Core values
- Consumer-grade first. If it only works on a workstation GPU, it doesn't count as working. We test on the same kind of machine our users have and treat memory and context limits as design constraints, not excuses.
- Local and private by default. The model, your notes, your tasks and the conversation journal all live on your computer. Features that reach the internet, such as web search, are read-only and identified separately in the app.
- The harness owns the truth. The model never touches your computer directly. It can only name a registered tool, and the harness decides whether that call is allowed, validates its arguments and asks for your confirmation before anything risky.
- Compute first, infer second. If code can work out the answer exactly, such as how many tasks you have, today's date or whether a web page's button works, code does it. The model is asked only for judgement.
- Evidence over claims. Every change to how the model behaves is logged with a hypothesis, a baseline, a sample size and an evidence grade. We publish failures and refuted hypotheses as well as wins.
How we measure improvement
It's easy to make an AI product look better than it is: run one impressive demo and call the feature finished. We keep a research log instead. It's an append-only scientific record of every change meant to make small models more capable through the harness.
The protocol
- Observe first. Every change starts from recorded evidence: a real conversation in the local journal, an evaluation report or a reproduction.
- Write the hypothesis before the change. It must be falsifiable, for example “with a draft open, ‘make the header blue’ routes to editing, not to a new task.” When an entry's hypothesis was written after the fact, the entry says so.
- Record a baseline on the unchanged system, using the same instrument we'll use afterwards.
- Version the harness so results from before and after the change are never mixed together.
- Report the sample size, model, context size and configuration with every number. One run is a reproduction, not a reliability rate.
- Keep negative and null results. A fix that didn't work is a finding too.
- Separate what was verified from what was assumed. A test with a simulated model proves the harness behaves correctly. It says nothing about how good the real model is.
Evidence grades
Every result carries a grade, so you can see how much weight it can bear.
| Grade | What it means |
|---|---|
| A | Controlled and repeated: fixed model, version and settings, at least 3 runs per condition, measured before and after with the same instrument. |
| B | Live reproduction: a real model run once or twice, or a single before-and-after pair. |
| C | Harness only: deterministic replay or tests with simulated model output. Proves routing and state, not model quality. |
| D | Observational: patterns in real use, uncontrolled. Tells us what to work on; doesn't confirm a fix. |
What the evidence has taught us so far
These findings from the research log shape how we build.
Most failures were the harness, not the model
A request for a Python Snake game was being saved as a task. Switching from a 1.5B to a 7B model didn't fix it. Fixing one routing rule brought both models to 3 out of 3 correct (RL-004, grade A, narrow). Better engineering in the harness often achieves what people assume needs a bigger model, and that matters a lot for people with modest hardware.
Checking the output makes small models more useful
For websites and small apps, the harness opens the result in an isolated browser, runs fixed functional checks, and sends the model only the element that failed. On a 12-check website brief, qwen2.5-coder:7b went from 10/12 to 12/12, and a later build passed 10 of 10 checks inside the chat app (RL-010, RL-011, grade B). The same loop gave no gain for 1.5B models, and we record that too.
Some things didn't work, and we say so
Given a state table and the exact failing observation, the 7B model still couldn't repair a task app's reactive filters within three attempts (RL-012, grade B, negative result). A token-estimate correction we expected to help turned out to be unsafe for code (RL-002, refuted). Correcting a context-size mismatch on its own changed nothing about behaviour (RL-010, refuted).
Test the real thing, and check what's actually served
Our command-line evaluations passed while the desktop app quietly dropped search results. Only testing through the real app caught it (RL-006). In another case, settings said the model had an 8,192-token context, but the local server was actually giving it 4,096, because a background request reset it (RL-015, grade B). We now check what's actually served, not what's configured.
Reasoning models spend their budget thinking
Small "thinking" models such as qwen3:4b-thinking often use up their whole reply allowance on deliberation, especially when continuing long code. This is the most frequent failure we've recorded for that model. It now has its own failure category, and the harness continues drafts from where they stopped instead of rewriting them (RL-009, RL-014, RL-015). The effect of that change on live models hasn't been measured yet.
We record our own lapses
One batch of changes was made without a log entry and before the project was under version control, so its exact diff can't be recovered. Rather than quietly forget it, the log has an entry that reconstructs what is known and marks it as unattributable (RL-012a).
Where we are, honestly
- Tiny Agent is an early test build. Most results are grade B or C: single live runs and harness tests. We don't yet have controlled reliability rates across many users, models and machines.
- Harness behaviour is covered by an automated suite of over 680 tests. Those tests show that the rules work; they don't show how often a given model succeeds.
- Small models have real limits. Multi-page sites, long code and complex app logic still regularly exceed what a 4–7B model can do in one pass.
How you can help
Grade A evidence needs more than one person's computer. Testers who use Tiny Agent on their own hardware, with their own requests, help us measure what small models can really do and make the harness better for everyone.
Tester data sharing will be strictly opt-in: nothing leaves your machine unless you choose to share a specific conversation, and you'll see exactly what is sent first. Full details will be on our privacy page before the test build is released.