Use cases · Developer platform · Integration
You do not integrate
a library. You call the API.
There is no SDK to learn, no package to install, and no model to download. You are calling a Senua AI engine running on your own hardware, over plain HTTP. No cloud round trip, no tokens to burn, no black box. If your language can make a web request, it can already talk to Senua.
The problem
Most platforms make you adopt them before you can try them.
You want to see if a new engine is any good. First you install a client library. Then you pin its version against the rest of your stack. Then you read its abstractions to find the one HTTP call you actually wanted. By the time you get a result you have taken on a dependency you now have to maintain, and an account you now have to route your data through.
Senua works the other way around. Every node runs the same gateway API, and that API is the whole product surface. The web console uses it. The command line uses it. Your code uses the exact same routes. There is no privileged path and no hidden layer, so there is nothing to wrap and nothing to keep in sync. You point it at a node you control and start calling.
What you are not signing up for
The API pain you have learned to expect is not here.
When developers hear API they think of a meter running, a network round trip on every call, and a model that forgets the start of the conversation by the end. None of that applies, because you are calling a daemon on your own hardware, not renting time on someone else's.
No tokens to burn
There is no per-token meter and no per-call bill. The engine runs on hardware you already own, so the cost is fixed and the usage is yours. You can send it a million requests or one; the pricing does not change because there is no pricing on the calls.
No cloud latency
Your request goes to a local daemon, not across the internet to a provider and back. There is no queue, no rate limit, and no round trip you did not choose. The demo talks to a node on localhost; the only latency is the engine doing the work.
No memory to lose
The engine learns into a persistent knowledge base, not a rolling context window that drops the start of the session to fit the end. What you teach it stays taught. There is no window to overflow and no history to re-send on every call.
No confident fiction
Every answer is grounded in what the engine has actually learned, and it comes back with the engine's own confidence and a trace of how it got there. When it does not know, it says so. You are not handed fluent guesses dressed up as fact.
No workflow decay
Quality does not drift as a session grows longer. There is no context filling up and no slow slide into worse answers halfway through the day. It is one engine over stable state, so call one thousand behaves like call one.
No data leaving
Nothing is sent to a third party, because there is no third party in the path. You run the node, you hold the credentials, and your material stays on the machine you chose. The easy path and the private path are the same path.
No black box
The API is direct access to the engine, not a wrapper over a hidden model.
You are not calling a sealed endpoint that returns an answer and hides everything else. The same routes give you the engine's internals: its perception, its learning, and its reasoning, all in the open.
Run a stream through causation
See what the engine perceives, frame by frame.
Send a data stream and get back the causal states the engine induces from it, directly. The audio use case in the demo does exactly this: you watch the engine take a sound apart into its causal structure in real time. That is the engine's actual perception, not a summary of it.
Train the Anima in real time
Teach it what you want, while it runs.
Feed it your own material and it learns immediately into its living knowledge base. There is no retraining job, no fine-tune queue, and no redeploy. You teach it a fact or a document and it can use it on the very next call, on your node, from your data.
Run a workflow end to end
Compose the whole business process over one surface.
Perception, learning, and reasoning are all reachable from the same API, so a real workflow lives in your own code end to end: bring in a stream, ground it in what you have taught, ask the questions your process needs, and act on the answers. No orchestration layer you did not write.
Two ways in, one surface
The CLI for a terminal. The API for your code. Same routes underneath.
Pick whichever fits the moment. They are not two integrations to learn. They are two front doors to one API.
The CLI
An authenticated client for the terminal and your shell scripts. Log in once, then drive the node from the command line: ask a question, ingest a file, check status. It is the fastest way to poke at a node by hand and to wire Senua into a pipeline you already run in bash.
The API
Plain HTTP with JSON bodies. Log in and you get a session; every call after that carries it. This is what the console and the CLI both call, so anything they can do, your code can do, in any language that can post a request.
The whole integration
Three calls. That is the surface.
Perception in, cognition out, and the login that ties them together. Everything in the demo is built on these three routes, and they behave the way you would guess.
Authenticate
POST /api/login
Send a username and password, get back a session. Hold on to it and send it with the calls that follow. The same login the console uses.
Cognition
POST /api/chat
Send a message, get the engine's answer. The reply also carries the engine's own state and confidence trace if you want to show your work, or just the answer if you do not.
Perception
POST /api/audio/analyze
Send a window of audio, get back the causal states the engine induced from it. Stream it window by window and you get a live read of what the engine is hearing, the same path the microphone uses.
That is the entire contract for the demo. No client object graph, no code generation, no build step. You can drive all three from a shell with nothing but curl.
No library. No dependency.
The demo installs nothing, in two languages.
We wrote the same integration twice, in Python and in Node.js, using each language's standard library only. On a fresh machine with either runtime present, they run. There is no requirements file and no package manifest because there are no requirements.
Stdlib only, either stack
Login, chat, and audio analysis in about a hundred and fifty lines of plain code, using the HTTP, JSON, and audio handling that ship with the language. Nothing to pip install and nothing to npm install. Even the audio file is parsed by hand.
Transport, not cognition
The code contains no intelligence. It reads a file, posts it, and renders what comes back. Every answer and every induced state is the engine's, computed on the node. The client just carries bytes, which is why porting it between languages is trivial.
Runs on a laptop
Point the demo at a node on your own machine, on a small board, or on a private server. No GPU, no cloud call, and nothing leaves the node you chose. The engine is a small native daemon.
What the demo does
Perception you can watch. Cognition you can talk to.
Two use cases, two small programs, both talking to the node over that same API.
Audio to causation, visualized
Feed an audio file to the node and watch the engine take it apart in real time. One command prints a live causal-state equalizer in the terminal. A second small web server draws it in the browser: a causal-state spectrogram building left to right, and a live bar chart of the current frame. Every frame on screen arrived from the engine over the stream.
A web chat, in your own UI
A one page chat UI served by a tiny web server. You type, it relays the message to the node, and the engine answers. The session lives in your server, so the browser only ever talks to your own process. It is a working example of putting your own front end on the engine in a few lines.
Demo · Coming soon
Watch the whole thing come together in an editor.
A recording of the full run: open the folder in the editor, set three environment variables, run the audio visualizer and watch the causal states stream in the browser, then start the chat server and talk to the node. From a clean checkout to a working integration, on camera, with no install step.
Why this matters
You own the engine, the data, and the workflow.
The reason integration is this simple is the same reason it is safe and predictable. There is no vendor library phoning home, no meter running, no account your data has to pass through, and no cloud endpoint that can change under you. You run the node, you hold the credentials, you train it on what you choose, and the whole workflow lives in your own code against an API you can read in one sitting.
That is the combination the regulated and disconnected world has been waiting for. A team can put Senua behind their own interface, teach it their own material, and run their own process end to end, all inside their own environment. The demo is a falsification kit as much as a quickstart: point it at your node, feed it your files, and check every claim on this page yourself.
If you can call an API, you have already integrated.
One HTTP surface, a CLI and an API over the same routes, no dependency to carry, and no black box behind it. The engine does the work on your node; your code just asks.