A chat reply is a paragraph. Proto is the same model, cognira Retrain, asked for a map instead: a title, a sentence, and a few branches you can click.

You start with a sentence

The composer is the same one as chat. You describe one idea (a shed the street already has, a loaf club, a fact you want a model to remember) and send it. While the model works you get the same waiting state as a chat reply, and if the machine is busy you see the queue.

Nothing is drawn until the model answers in the shape Proto can read.

Edit a card, branch it when you want more

The first reply is four to six branches, specific to that idea. A few design choices I made:

• Clicking a card lets you change its name or the sentence under it. That edit stays in your browser and doesn't call the model.
• Right-click a card and choose Branch to get children. Only that card is sent back to the model, along with the path that got you there. The other cards stay put.
• The map stops four steps out from the centre, so it stays readable on one screen.
• If the model replies with a paragraph, or a single lonely branch, Proto doesn't invent the rest. You get a message and the grid stays as it was.

That last one matters to me. A tool that quietly fills gaps with made-up structure is worse than one that tells you the answer didn't come back in the right shape.

No second meter

A new map and each branch you grow count toward the same weekly tokens as chat, and share the same short burst limit. A call that reaches the model is charged; a call you stop, or that never reaches the model, releases the hold.

The idea isn't filed into your chat history. The map stays in your browser, under the account that drew it, and you can copy an outline or download the cards as an image.

Proto is in the header on cognira.dev, and inside chat it sits in the sidebar under Workspace.

A chat you start on the website should carry on when you pick up your phone. In cognira's Android app, the Chat tab opens on the list, not on a blank composer, and that list is the account's: conversations from cognira.dev and from the app, merged, pinned ones first, then grouped by day.

Open it, reply, and both sides have the turn

Tap a chat you started on the website and the messages are there, including the rating you left and the memories that reply used. Send another message and you're in the same conversation. The next time the website loads that chat, the new turn is in it.

A few details I cared about:

• Replies type themselves out in Markdown: headings, lists, quotes, and code you can copy.
• If the model returned its reasoning, a row labelled Thought for (with the seconds it took) opens into it.
• Ordinary web links open in the in-app browser.
• The app never invents a reply when the iMac that serves the model can't be reached. You get the error, and a retry.

The list

• Search appears as soon as there's a chat.
• Long-press deletes one.
• A New chat button floats over the list; the ask bar on Home does the same thing and opens the keyboard.
• Android's back button, the back arrow labelled All chats, or tapping the Chat tab again returns you to the list.

Home keeps a shorter row of recent chats under the week's numbers. The empty state says "Your conversations, from here and cognira.dev, land here", and it's literal. If a chat you just had on the website is missing, pull down on Home or on the list to sync.

One allowance

Tokens count against the plan on the account, the same weekly number the website shows. Home draws it as a bar with when it resets, and Upgrade plan opens the plans page. Free, Pro, and Max all talk to cognira Retrain, the model cognira runs. The phone doesn't get a second quota.

More on cognira at cognira.dev. The full post, with screenshots and context, is on the cognira blog.

cognira's Android app can read an assistant reply out loud. It sounds like a one-line feature, but most of the work was deciding the rules: what speaks, when it starts, what stops it, and what never gets read at all. Here's where I landed.

The phone's own voice, not ours

Read aloud uses the phone's speech engine, in British English. That's separate from Speak on the cognira website, which is a recording made on our side. On the phone, the audio never leaves the handset.

Before anything is spoken, the Markdown is stripped. If a reply has nothing left after cleaning (only markup), it's skipped rather than read as silence or symbols.

One reply at a time

• Tap Read aloud and that reply starts.
• Tap it again (it's now labelled Stop reading) and it stops.
• Starting another reply stops the one that was going.
• A line of sound sits on the message while it speaks, so you can see which turn is the one in the air.

Only one thing ever talks, and the button always tells you what pressing it will do.

Or every reply, as it arrives

Settings has a Read replies aloud switch.

• On: each finished reply speaks by itself, and it takes the speaker if something else was already being read.
• Off: only the button starts speech, and a new reply leaves a reading you started alone.

The choice is kept on the phone between launches, next to the haptics switch. Haptics (the small taps on buttons and tabs) are independent of the voice.

One deliberate choice: speech starts when the reply has landed, not one token at a time while it's still streaming.

What it won't read

• The button is only on assistant messages. Your own turns stay text.
• Code fences lose their fence marks and are read as the words inside. That's useful for a short snippet and noisy for a long one.
• For a long snippet, copy is the other action on the same row, and it keeps the original Markdown.

Try it

cognira for Android is free on Google Play, and the full post with the rest of the details is on the cognira blog. I'm happy to answer questions about how it's built in the comments.

cognira's Android app has a streak on its Home screen, and an optional reminder to keep it going. The rule I set for that reminder was simple: one nudge at 7pm, and only on days you haven't used cognira. Getting "haven't used cognira" right turned out to be the interesting part, because people use it on the website as well as the phone.

Ask once, then get out of the way

The first time there's a streak to keep, Home shows a card: "Keep your streak going?" Turn on asks Android for notification permission (on Android 13 and later that's the system dialog). Not now dismisses the card. After that the switch lives in Settings, next to haptics and read aloud, so changing your mind doesn't mean hunting for it.

The card says exactly what you're signing up for: one nudge at 7pm, on days you haven't opened cognira. The notification title is "Don't lose your streak", and the body names the length, either a first day or the number you're on.

Two ways it can fire, and why both exist

Server push (the main path). With permission granted, the phone registers an Expo push token with the account, along with the time zone and whether reminders are on. The server sends the 7pm nudge only when that account has been quiet everywhere that day, the app and the website included. Signing out removes the token, so the pushes stop.

On-phone reminder (the fallback). If the token never lands, because permission was refused or the network was down, a local reminder takes over. Each time you open the app it moves that reminder to tomorrow evening, so it only fires on a day the app itself wasn't opened.

The trade-off is worth stating plainly: the fallback can't see a day you spent only on cognira.dev, and the server push can. That's why the server path is the main one. And a reminder that fails to schedule is just dropped; it isn't worth an error on screen.

What the streak actually counts

The marks are days the account was active, recorded by the backend from signed-in requests, not taps counted on the phone. Under the streak are three numbers: questions and maps touched in the last seven days, and how many chats are saved. The card also names your best run when the current one is shorter, or tells you this is your best. A day that gets marked plays a short burst on the card, once.

The reminder is optional. Chat, Proto (cognira's idea-mapping tool) and robot control all work with it off.

The takeaway for anyone building a streak reminder

If your product lives on more than one surface, the device alone can't know whether the user showed up today. Put the "was this account active today?" check on the server, where every signed-in request lands, and keep a local reminder only as a fallback for when the push token can't be registered.

cognira is an AI assistant you can teach, running its own model (cognira Retrain 12B on a Gemma 4 base). More at cognira.dev.

cognira is an AI assistant you can teach things to in plain conversation. The part I most want other people building memory features to steal is a small design choice: every memory is stored as a third-person statement about the user, never as an instruction. Here is how the whole flow works and why that choice matters.

Teaching happens mid-sentence

There's no settings panel and no special prefix. If a message matches a pattern cognira knows, it's saved before the reply comes back. Some real examples:

You can also teach vocabulary: glimble means a tiny useful shortcut, EOD = end of day, or a correction like no, glimble is a small workaround. If you use a word it doesn't know and the conversation depends on it, it asks what you meant, and your plain answer is saved as a confirmed definition. That's the highest-confidence signal in the system, because you were answering a direct question about a specific word.

What happens when you hit send

Three things, in order, before the first token of the reply:

1. The message is scanned for anything teachable, and a match is written to private memory immediately.
2. Everything relevant you've taught before is recalled and put in front of the model, including things from a different conversation weeks ago. The store is indexed, so "keep it short" on a Tuesday still shapes an unrelated answer on Friday.
3. Both are attached to the reply so the interface can show exactly what was used.

Under each reply there's a receipt: a chip like Learned · "prefers replies kept short" · Undo, and Used 2 memories, which expands into the actual statements, where each came from, and a Forget button per line. Saving is instant and doesn't block the reply; the slower machinery runs later on an idle machine.

Statements, not orders

When you say "keep it short", cognira stores Prefers replies kept short. It does not store Always reply in under three sentences. The first is data about a person; the second is a standing order.

Memories are injected into the model's context inside a fixed frame that says, in effect, "here is some known context about this user", never as rules. That's the firewall. If memories were stored as instructions, anyone could type a sentence designed to be remembered as a rule, and that rule would be silently re-applied to every future conversation. Storing statements means something you typed can inform a reply but can never quietly become policy.

Every memory also keeps its evidence: the conversation and message it came from. That's what makes "where did that come from?" answerable, and what makes deleting it mean something.

Forgetting is real

You can remove anything from the chat (expand Used N memories and hit Forget) or from Settings → Learning, which lists everything with Mute (stop using it, keep it) and Forget (gone). A forgotten memory drops out of recall on the next message. If it was vouching for a piece of shared knowledge, that entry loses your corroboration too, and can be withdrawn if it no longer has enough independent support.

The narrow path to shared knowledge

Almost everything you teach stays yours. Only one category can travel: a word meaning. Never your name, job, location or preferences. Three people liking short replies doesn't make short replies a fact about the world.

A definition has to clear seven checks, in order, and any one stops it:

1. Independent: at least three different accounts taught it.
2. Spread out: the lessons are at least a week apart.
3. In agreement: the definitions actually match.
4. Screened: no personal details, secrets or unsafe content.
5. Non-conflicting: it doesn't contradict shared knowledge already live.
6. Reworded: rewritten generally, and rejected if it reproduces anyone's sentence.
7. Quizzed: the rewrite is tested back against every original definition.

Then it serves to a small slice of traffic for a week before going fully live. It's deliberately slow: the failure I care about isn't "shared knowledge grew too slowly", it's "one confident person redefined a word for everybody".

Every check writes to an append-only ledger, pass or fail, and it's public at cognira.dev/learning. Showing what got rejected is the only version of "look what our AI learned" you can actually check. (It's cached, so a new lesson can take a couple of minutes to show.)

What it doesn't do yet

• It doesn't catch every phrasing. Capture is tuned for precision over coverage, because a wrong memory is worse than a missing one. No receipt means no memory.
• Shared knowledge is nearly empty. Three unrelated accounts teaching the same word a week apart is a high bar on a young service.
• Nothing has changed the model's weights yet. The eval-gated path for folding shared knowledge into the checkpoint is built and tested, but no candidate has been promoted. When one is, it'll appear in the same public ledger with its scores.

If you're building memory into your own assistant, the one thing I'd pass on is the statements-not-instructions rule. It costs nothing and closes a whole class of persistent prompt injection.

You can try it at cognira.dev: type "call me" and your name, then ask anything, and look at the receipt under the reply.

cognira runs its own models (cognira Retrain 12B, retrained on a Gemma 4 base, and the older Omega 188M) behind an OpenAI-compatible API. I wanted to see how it holds up as the brain of a terminal coding agent, so I wired it into opencode and gave it one sentence.

The config

opencode reads providers from ~/.config/opencode/opencode.json (global) or opencode.json in a project root. Because the API is OpenAI-compatible, the generic @ai-sdk/openai-compatible adapter is all you need: no plugin, no shim.

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "cognira": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "cognira",
      "options": {
        "baseURL": "https://cognira.dev/v1",
        "apiKey": "{env:COGNIRA_API_KEY}"
      },
      "models": {
        "cognira-retrain": { "name": "cognira/cognira-retrain" },
        "cognira-omega": { "name": "cognira/cognira-omega" }
      }
    }
  }
}

Using {env:COGNIRA_API_KEY} keeps the key out of the file (and out of git). Two models then show up in the picker: Retrain answers straight out, Omega thinks first. Both bill from the same balance at £1.50 per million tokens, input and output.

Say hello first

Before giving an agent a real task I spend one prompt on "hello". It proves the auth, base URL and streaming path work. In my run:

• Retrain: no thinking block, 20.3 seconds end to end.
• Omega: a 7.4-second thought, then the reply, 26.2 seconds total.

For the actual build I stayed on Retrain. When a task is mostly "emit a lot of correct boilerplate", thinking tokens are just latency.

One prompt, no follow-ups

The prompt was a single sentence asking for a "full stack html portfolio" for me. After 37.5 seconds it started streaming, and it opened by pushing back: a portfolio doesn't need a backend. Then it delivered the front end anyway, as three files (index.html, style.css, script.js), with sectioned, commented HTML, anchor nav wired to matching IDs, a custom-property palette, and a mobile breakpoint, which is the part models usually forget.

It also left a marker instead of inventing an asset URL, url('path/to/tech_bg.jpg') with a comment to drop in a background image. Saving one image was the only edit I made by hand.

What it got wrong

It isn't a design award. The social links were href="#" placeholders, the projects were invented, and the copyright said 2024. But it was responsive and shippable after about ten minutes of filling in real content.

Notes if you try this with any OpenAI-compatible model

• Use the fast model for volume (code generation) and the thinking model for debugging and architecture calls.
• Expect a wait before the first token; once streaming starts it doesn't stall, so don't kill the process at 30 seconds.
• It may argue with your prompt. If you want the over-engineered version, say so.
• Watch opencode's context and spend readout to notice a long session eating tokens.

The same config shape works for anything that takes an OpenAI-compatible base URL: Cline, Aider, the OpenAI SDKs, or your own scripts. Docs and keys are on the cognira API platform page.

exceeder is a Chromium browser with my assistant, cognira, built in. It isn't a web app dressed up as a browser: it's Chromium compiled from source on one Windows PC, with 65 patches and our own code on top. Here's what that took, including the afternoon the linker ran a 32GB machine out of memory.

Why a fork and not Electron

The first prototype was an Electron app. It was a fine sketch of the design, but Electron is an app framework, not a browser. Chrome extensions, the Web Store, a real tab model and Chrome's settings would all have had to be rebuilt by hand, and every web page would have lived inside another web page. So exceeder is Chromium itself: Blink, V8, the sandbox, the tab strip and the extension system. The Electron prototype stays in the repo as the design reference.

How the tree is laid out

The layout borrows from Brave's: our code never lives only inside a Chromium checkout. The repo holds three things, and one script lays them onto a clean checkout:

• exceeder/: our own C++ and TypeScript (the cognira panel, setup pages, importer, new tab additions).
• patches/: one patch per upstream file we change, 65 of them, kept small on purpose. Most wire something of ours in or switch a Chrome behaviour off.
• overlay/: files that replace upstream ones outright, like icons generated from the brand kit.

python scripts/exceeder.py apply           # our tree + overlay + patches + rebrand
python scripts/exceeder.py build           # the dev build
python scripts/exceeder.py update-patches  # turn edits in the checkout back into patches

Chrome features we don't want (the avatar sign-in pill, the restore bar, new tab promos, AI Mode entry points) are switched off from one file of feature defaults instead of being patched out where they live. The next Chromium version is then a rebase of a short list.

The numbers

The release build uses Chrome's "official" configuration, which turns on ThinLTO: the compiler leaves optimisation half-done and the linker finishes it across the whole program. You get a faster browser and a long, hungry link. Compiling took a little over five hours on this machine.

The link that ran out of memory

With everything compiled, the build reached the link of chrome.dll. Chromium tells the linker to run its ThinLTO work on all of the machine's threads: twelve here, each holding its own slice of the program in memory. The PC ran critically low on memory and the build was stopped.

The obvious fixes were worse:

• The thread setting is hard-coded in Chromium's build files. Changing it changes the link command of every program in the build, so dozens of build tools relink and everything they generate is treated as new.
• The linker's _LINK_ environment variable looked like an escape hatch, but lld puts its contents before the command line, so the build's own setting still wins. I checked: the output name from the command line beat the one from the variable.

The fix was to tell the linker it had fewer CPUs. LLVM's "all" counts the CPUs the process is allowed to run on, and child processes inherit that. On a test link the linker peaked at 18 threads with every CPU allowed, 12 with six, and 8 with two. So the restarted build ran pinned to one logical CPU per physical core:

# One logical CPU per core on a 6-core, 12-thread Ryzen: 0b010101010101.
kernel32.SetProcessAffinityMask(kernel32.GetCurrentProcess(), 0x555)

Six ThinLTO jobs instead of twelve, and no build command changed. The linker also keeps a cache of work it has already finished, so the restart picked up where the stopped link left off, and the restarted build finished in 11 minutes.

A bug in my own tooling

The first release build showed two headers on the cognira panel, even though the change removing one was already in the repo. The apply script copied changed files with their original timestamps, so the copies looked older than the already-compiled objects and the build kept the stale ones. Now a copied file gets the current time and an unchanged one keeps its timestamp, so builds stay incremental. The bug lasted one build.

Day to day

Daily work happens in a component build, which splits Chromium into many small libraries so a change relinks quickly. A small UI change rebuilds in about a minute (58 seconds for the change that added the panel's Ctrl+Shift+. shortcut). The setup pages and the cognira panel are TypeScript, and a small preview tool compiles them with Chromium's own TypeScript settings against a fake browser and screenshots them in seconds, so most design work never waits for a build.

Try it

exceeder is free in early access for Windows 10 and 11 (64-bit). Chrome extensions work, and anything the assistant would send, buy or delete waits for your OK. Details are on the exceeder page. If you've fought Chromium's ThinLTO link on a desktop machine and found a better trick, I'd genuinely like to hear it.

Most hobby robot projects end up with a little web page for driving them, and most of those pages are built by hand, once per robot. I wanted to skip that step: write the Python functions you already have, put a decorator on each, and get a control panel for free.

That part turned out to be the easy bit. The part I spent the most time on was stopping. A robot is not a chat window. A button press that arrives late can knock something off a table, so I decided the safety behaviour had to live in the SDK itself instead of being left to every script.

The basic idea

pip install cognira-robotics

It needs Python 3.8 or newer and has no dependencies outside the standard library, so it runs on a Raspberry Pi, a Jetson, or a laptop wired to an Arduino.

from cognira_robotics import Robot

robot = Robot("Hello robot")

@robot.button("Wave", key="w")
def wave():
    robot.log("waving")

robot.run()

The first robot.run() prints a code. You approve it on cognira.dev, and from then on the robot shows up under Robotics whenever its script is running, with each control drawn next to the function it calls. The robot only makes outbound HTTPS requests, so it works behind home Wi-Fi, a school network or a phone hotspot without opening any ports.

The decorators map to controls like this:

Any control can take a keyboard key, so key="w" and friends give you WASD driving. robot.show() and robot.log() stream values and log lines back to the page.

Safety decision 1: Stop interrupts, it doesn't queue

The red button (or Esc) calls your @robot.on_stop function straight away, even while another function is still running, and drops anything queued behind it.

The awkward case is a long-running action, like a sweep loop. For that, robot.sleep() returns False the moment Stop is pressed, so loops can end cleanly instead of finishing their routine:

@robot.button("Sweep", key="s")
def sweep():
    for target in (25, 155, 25, 155):
        send(f"a {target}")
        if not robot.sleep(0.6):   # False the moment Stop is pressed
            return

@robot.on_stop
def stop():
    send("off")                    # let the servo go limp

In my test with an ESP32 and a servo, Stop arrived about a second into a sweep. The servo went limp mid-swing at 104°, and the sweep's robot.sleep() woke up and returned.

Safety decision 2: held controls need a pulse

A joystick or hold-button is the dangerous kind of control, because "the user is still holding it" and "the user's Wi-Fi died while holding it" look the same to a naive robot.

So while you hold a joystick, the page re-sends its position four times a second. If those refreshes stop, because you let go, closed the tab or lost the connection, the robot lets go after 1.5 seconds by default: joysticks re-centre and held buttons release. When I steered the servo hard left and then stopped sending, it came back to 90° on its own.

Safety decision 3: late commands are thrown away

Reconnection is where replayed commands bite. If a robot drops off the network and comes back, the last thing you want is a burst of stale presses arriving all at once.

So a button press that can't be delivered within 10 seconds is discarded, and a joystick position within 1.5 seconds. Neither is replayed into a robot that has just reconnected.

Clamping happens before the hardware

Sliders carry their own limits. In the ESP32 test, a slider set to 140 moved the servo to 140°, and a value of 999 was capped at the slider's 155° maximum before it ever reached the board. Full left on the joystick went to 25° and half right to 122°, matching the 90 + x * 65 mapping in the script.

The ESP32 can't run desktop Python, so the SDK runs on the computer it's plugged into and passes one-line commands down the USB cable (a 120 to move to 120°, off to go limp, status to report). The whole bridge is one short script using pyserial.

Trying it without an account

robot.run(local=True) serves the same control panel from the robot itself at http://localhost:8700, with no sign-in. It only listens on your own machine, so other people on your network can't drive it. It's the quickest way to get the wiring right before linking anything.

Robotics is free on every cognira plan, including Free, with up to 25 robots per account.

A question for you

The 1.5-second release and the 10-second drop window are defaults I picked from testing on one servo, not from any standard. If you've built remote-control or teleoperation tools, what timeouts did you settle on, and did you make them per-control or global? I'd genuinely like to hear what's bitten other people.

Links: cognira-robotics on PyPI · Robotics quickstart · cognira.dev · X: @cogniraAI

For the past while I've been building cognira on my own. It's an AI assistant that learns from the people who use it. Its model, cognira Retrain 12B, is retrained on top of a Gemma 4 base and served through MLX on a single 16GB iMac in my living room. Questions aren't forwarded to anyone else's API.

The part I want to write about is the hardest one: how does a self-learning assistant decide what it's allowed to learn? Letting users teach a model is easy. Stopping one bad chat from rewriting the system is the real work.

Two kinds of learning, kept apart on purpose

I split "learning" into two paths with very different rules.

1. Private memory: immediate. If you tell cognira "call me Tom" or "keep answers short", that goes into your private memory and is used from the next reply. The reply then shows which memory it drew on, with a one-tap Forget button next to each one. On the site's example, a reply reads "Used 2 memories from what you've taught it", with "Preference: Keep answers short" and "Name: Call me Tom" listed underneath, each with Forget.

That was deliberate: if an assistant personalises itself quietly, you can't tell what it thinks it knows about you.

2. Shared knowledge: slow and gated. Something one person teaches stays private. It can only become knowledge every conversation draws on after it passes a pipeline that's logged publicly at cognira.dev/learning.

The shared-knowledge pipeline

Each stage is shown on the learning page with its counts:

1. Clustered. A claim only becomes a candidate when separate accounts arrive at it independently. A taught word has to come from several people, days apart.
2. Screened. Unsafe, personal or contradicted material is thrown out before anything is written down. The claim is also reworded, so it's never anyone's literal sentence.
3. Quizzed. The abstracted claim is questioned from angles nobody taught it. Most of the losses happen here.
4. Canaried. Anything that survives goes live for a small slice of conversations first, and stays under watch.
5. Shared. Only then does it become shared knowledge, and it can still be pulled.

Personal detail never enters the public log. A claim has to be abstracted away from whoever taught it before it's recorded at all.

Weight updates: never in the hot path

Separately from the knowledge cards, the model itself can be retrained. A few rules govern that:

• Filtering first. Sensitive, unsafe and badly formatted replies stay out. Only short, useful examples are ever copied. A reply you down-rate can only teach the model what not to say.
• Wait for enough clean data and an idle machine. Background updates only run once there are enough clean examples and the server isn't busy. On one iMac, inference wins every time, so learning pauses whenever people need the machine.
• A candidate must pass checks before it replaces anything live. If it doesn't, it gets rolled back.
• Your reply never waits on training. Confirmed teaching works straight away from private memory. Weight updates happen in the background.

What the public log actually shows

I publish the whole thing, failures included. A few recent entries from cognira.dev/learning:

Rolled back weights (10d ago): "Recorded by the learning pipeline." Candidate adapter, Notes 5

That entry appears paired with Eval started over and over in the recent log. Each pair is a candidate adapter that was evaluated and then rolled back instead of going live. That's the system working as intended: a candidate that doesn't earn its place doesn't replace the live model.

Quiz passed: proto (13d ago): "Survived being questioned from angles it was never explicitly taught." Quiz score 100%, method: source

glimble: "A feeling of satisfaction and pride derived from successfully completing a task." 3 independent accounts, 100% on the quiz

"glimble" is a made-up word, and it's my favourite test case. The model can't have known it from pretraining. It became shared knowledge only after three separate accounts taught it and it passed the quiz.

To be straight about scale: this is a small project. The contributor table currently lists 15 people, and there are 5 shared knowledge cards. Several of the newer cards came through a "trusted teacher" path with one account (mine), and the log says so. I'd rather show that than hide it.

Honest limits

cognira Retrain 12B is a compact model, served locally. Frontier systems will still beat it on breadth and trivia. Its edge is the loop: teaching works immediately from private memory, and verified updates can improve the model where people actually use it.

I also don't publish a carbon number. The service runs on one 16GB iMac, caps needless output, and defers background learning when inference is busy. But I can't meter energy properly yet, so I don't claim a figure.

Running it yourself

There's also cognira Entity, a local desktop app that runs the same models (cognira Retrain 12B and the older Omega 188M checkpoint) on your own machine. Memory and optional weight retraining stay on your disk. If you'd rather build on the hosted model, there's an OpenAI-compatible endpoint at api.cognira.dev.

A question for you

The part I keep rethinking is the clustering threshold. Requiring several independent people, days apart, keeps one bad actor out. But on a small user base it also means good, niche knowledge can sit in the queue for a long time. If you've built systems that learn from user feedback, how did you balance "hard to poison" against "actually learns something"? Did you lean on trusted contributors, longer canaries, or something else entirely?

Everything above, including the rejections, is at cognira.dev/learning. I'm also on X as @cogniraAI.