Gnosil/semantix: a memory kernel that keeps coding agents from starting over
semantic agent kernel which make agent efficient and self-evolve
At a glance
- What is it?
- Semantix is a Go coding agent plus an attachable memory kernel that extracts reusable slices from finished sessions and reinjects them, while trying to keep provider prefix caches byte-stable. Here is what the repository documents, and where it is thin.
- Who is it for?
- Adopt Semantix if you run long coding sessions against DeepSeek, GLM or another OpenAI-compatible endpoint and want retrieved project knowledge carried across sessions without rewriting your harness; the kernel path through the gateway needs one base URL change. Do not adopt it if you need a documented rollback or uninstall path, or if you cannot accept a fail-closed L3 result reuse step in the answer path.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 2 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem Semantix targets: session amnesia and byte-exact caches
Two failures sit at the center of this project, and the README states both plainly. The first is that a coding agent loses its entire context when a session ends, so build conventions, test layout and service flags get re-established every time. The second is narrower and more mechanical: a provider's prefix cache hits only on byte-identical prompts, and a single edit near the head invalidates everything after it. The README's own example is a per-request billing marker that Claude Code writes into the head of the system prompt. First-party endpoints strip it server-side; third-party endpoints do not, so there the line invalidates the cache from the first token. The spec behind the prefix-hygiene middleware attributes a 133x difference in hit rate to that single header and records cache spend rising 4 to 5x when stripping is disabled. The audience is therefore specific: people running coding agents against third-party or self-hosted OpenAI-compatible endpoints, where prompt shape is under their control and cache economics are visible on the bill.
Slices, scoring and reinjection: how the memory kernel actually moves data
Semantix extracts reusable slices from finished sessions: task patterns, project knowledge, tool sequences and verified results. Those go into a local scored library, and relevant ones are reinjected when a similar task appears. Each hit carries its retrieval zone (hit, grey or miss) and its source session, which the README points to as real `semantix search`, `dashboard` and `verify` output in the reuse visualization walkthrough. Hits, misses and manual corrections all feed back into slice scores and retrieval thresholds, so the stated intent is that precision improves with use rather than volume alone. Type-aware eviction discards stale results first and retains project knowledge. On the cache side, the mechanism is byte stability rather than cleverness: retrieved slices are ordered by ID rather than by score, so semantically similar requests produce byte-identical prefixes. Per-request attribution markers are stripped, and the tool array is canonicalized by name so client enumeration order stops being a source of invalidation. A vendor capability table carries per-vendor cache lifetimes, budget-aware `cache_control` breakpoint placement and per-model price tables. The go.mod file shows the kernel is a Go module named `semantix` on Go 1.26.5, with `modernc.org/sqlite` for local storage, tree-sitter grammars for JavaScript, Python, Rust and TypeScript, and Bubble Tea plus Lip Gloss for the terminal interface. That dependency set tells you what the binary is: a local, single-process tool with a SQLite-backed library, not a service you deploy.
Installing Semantix and running a first search
The README gives a one-line install for macOS and Linux on arm64 or amd64. It drops `semantix` and `semantix-agent` into `~/.local/bin` and, per the README, turns on cross-session memory.
curl -fsSL https://raw.githubusercontent.com/Gnosil/semantix/main/agent-skill/scripts/install.sh | shA version and architecture can be pinned by passing arguments through the shell, which the README shows as `... | sh -s -- v0.7.2 arm64`. Other install methods and the full command reference are said to live in docs/QUICKSTART.md, which is not reproduced here.
Using it is deliberately split by invocation. A bare `semantix` launches the coding agent in the current folder, and that folder becomes the workspace. First run sets up provider and API key.
cd ~/your-project
semantixAny subcommand instead routes to the memory kernel. The README names search, extract, inject, verify and usage.
semantix search "..."The kernel path for an existing agent has three entry points. An agent skill is installed with `semantix install --target claude-code` and applies to Claude Code. Tool registration needs two tool schemas, `semantix_lookup` and `semantix_inject`, for custom or self-hosted agents. The gateway path needs one base URL and no code change, and applies to any OpenAI-compatible client. The README describes the whole thing as fail-open: on kernel error the agent falls back to its normal execution path.
Where Semantix stops being the right tool
The fail-open claim covers kernel errors, but the README also describes L3 result reuse as fail-closed: a verified result is returned without a model call. Those two properties point in opposite directions, and the README does not reconcile them. If you need every answer to pass through the model, a cached verified result is a behavior change you have to accept, not a fallback you can ignore. The second limitation is operational. The README documents install and usage but does not document rollback or uninstall, so a team that wants a reversible trial has no stated path back. Third, the numbers are workload-bound. The per-provider table reports 99.8% for DeepSeek and 97.5% for GLM as per-turn prompt-token hit rates, `hit / (hit + miss)` over cache token counts returned by the provider rather than estimates, and the GLM figure is described as coming from a week-long spike with a roughly 97.6% telemetry ceiling because trailing partial blocks never count as cached. Those are provider-reported and endpoint-specific. Attach the kernel to a stack whose cache behavior differs and the same configuration will not reproduce them. The 79.8% cost saving is likewise labeled a synthetic replay comparison, with methodology in docs/reports/m0-cost-comparison.md. Anyone treating it as a production measurement is reading past the label.
Semantix against a plain provider prefix cache
The alternative most teams already have is the provider's own prefix cache with no middleware at all. The difference is in what each one assumes. A raw prefix cache assumes the prompt head is stable and that the client is not inserting per-request bytes into it; when that assumption breaks, the whole suffix is recomputed and there is nothing in the path to notice. Semantix inserts a hygiene layer that strips attribution markers and canonicalizes the tool array before the request leaves, then orders injected slices by ID so that varying retrieval scores do not perturb the prefix. It also carries a per-vendor TTL table, which a raw cache cannot express because the lifetime belongs to the serving stack. The README's GLM study is the argument for that table: the same model behind different hosts showed cache lifetimes differing several-fold, one stack holding a prefix for 1 to 8 minutes with real expiry in the 8 to 12 minute band, another maintaining 96 to 98% for 120 seconds and falling to 28% at 301 seconds. A single global TTL would be wrong for at least one of them. The cost of the Semantix approach is a dependency in the request path and a local library to maintain; the cost of the raw approach is that you find out about prefix invalidation on the invoice.
Maintenance, licence and what an upgrade actually costs
The repository is not archived, and the last push was on 2026-09-14, one day before this writing, so the project is being pushed to. Release cadence is visible in the listed tags: v0.7.1 on 2026-08-22, v0.7.2 on 2026-08-23, v0.7.3 on 2026-08-28. Three releases inside a week is a fast-moving 0.x line, and the v0.7.1 release title mentions a system prompt update and GLM adaptation work, which suggests provider-specific tuning lands in releases rather than behind configuration alone. That matters for upgrade cost: a per-vendor capability table and per-model price tables are data that goes stale as vendors change cache behavior, so the practical maintenance burden is not just pulling a new binary but re-validating hit rates after a vendor change. The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are included; this is a description of the licence text, not legal advice, and anyone embedding the kernel in a product should read the LICENSE file in the repository. The go.mod pins Go 1.26.5, so building from source requires a toolchain at least that new.
Editorial conclusion
Adopt Semantix if you run long coding sessions against DeepSeek, GLM or another OpenAI-compatible endpoint and want retrieved project knowledge carried across sessions without rewriting your harness; the kernel path through the gateway needs one base URL change. Do not adopt it if you need a documented rollback or uninstall path, or if you cannot accept a fail-closed L3 result reuse step in the answer path. Before committing, verify three things in your own environment: whether your provider endpoint strips per-request attribution markers from the system prompt, what your vendor's prefix TTL actually is under load, and whether the slice library's eviction keeps the project knowledge you care about. The README states the design goal is to make the provider cache hittable rather than to work around it, and that is the claim worth reproducing on your own traffic before you point a team at it.
Frequently asked questions
What is the Semantix company behind this project?
The repository is Gnosil/semantix, published under the MIT licence with a homepage at semantix.ensureok.ai. The README does not describe a company structure, so any corporate entity using the Semantix name is not documented there.
What is semantic translation?
The README does not cover translation. Semantix here is a Go coding agent and memory kernel for AI coding agents, and its documentation is about session memory, slice retrieval and provider cache hit rates.
What is the difference between semantic translation and literal translation?
This question does not apply to the project in this repository. Semantix does not implement translation; it extracts reusable slices from coding sessions and reinjects them, and handles prompt prefix hygiene for provider caches.
What are the four types of translation?
The README does not discuss translation types. Semantix is documented as a coding agent and a memory kernel with semantic caching, adaptive scheduling, speculative prefetch and cross-session learning.
Community notes