Local-first agentic memory for AI tools, powered by the Pi runtime.
Project description
Syke
Syke is a local-first cross-harness agentic memory. It works with the AI harnesses you already use, keeps them in sync, and adapts its memory design to match your usage patterns.
AI-enabled work now means many sessions running in parallel across different harnesses, agents, repos, and chats. A decision made in one place often fails to reach the next place where it matters. Syke connects those threads so context carries forward.
That improves continuity and memory. It also makes the harnesses more efficient. They can rely more on what has already been discovered, decided, or learned, instead of starting over each time.
Syke introduces a kind of federation across your harnesses. Each harness can keep its own memory design and still rely on a general memory agent specialized in continuity across them. In that sense, Syke becomes a memory of memory.
Start Here
Use Syke directly
pipx install syke
syke auth set openai --api-key YOUR_KEY --model gpt-5-mini --use
syke setup
syke doctor
syke context
syke ask "What changed this week?"
syke setup reviews the current setup plan first. It ingests detected sources, runs initial synthesis when needed, and can enable background sync as a separate choice.
Other install methods
uv tool install
uv tool install syke
syke auth set openrouter --api-key YOUR_KEY --use
syke setup
From source
git clone https://github.com/saxenauts/syke.git && cd syke
uv sync --extra dev --locked
uv run syke auth set openai --api-key YOUR_KEY --model gpt-5-mini --use
uv run syke setup
Use Syke through an agent
Point the agent at this repo or the installed Syke skill, then let it drive the process.
If Syke is not set up yet, let the agent inspect the current plan with syke setup --json or syke setup, guide provider selection if needed, and finish setup first.
Once setup is done, a good agent workflow is:
- call
syke askfor deeper timeline and evidence-backed queries - call
syke contextwhen the current memex is enough - call
syke recordto write observations back into memory - call
syke statusfor a quick operational snapshot - call
syke doctoronly when setup or runtime looks wrong
After sync and synthesis, Syke refreshes its local attachments and can install its skill file into detected skill-capable agent directories.
Why this loop is trustworthy
Syke separates capture from inference. Supported local harnesses feed raw activity into an append-only events timeline. When Syke synthesizes memory or answers a question, it does so inside a local workspace where the events snapshot is read-only, the learned-memory store is writable, and the current memex is routed back out as additive context.
That gives you something simple to trust: a record you can inspect, a memory layer that carries forward, and a loop that stays local-first until ask or synthesis calls your configured provider.
How It Works
Claude Code Codex Hermes OpenCode
\ | | /
\ | | /
+-----------+-------------+-----------+
|
v
Observe: deterministic local ingest
no LLM before the ledger
|
v
+-------------------------------------------+
| events.db |
| immutable observed timeline |
| append-only evidence ledger |
+-------------------------------------------+
|
v
+-------------------------------------------+
| local Syke workspace |
| |
| read events.db snapshot |
| write syke.db learned memory |
| route MEMEX.md |
| |
| ask and synthesis run here |
+-------------------------------------------+
|
+--------------+---------------+
| |
v v
direct reads routed context
syke context syke ask
MEMEX.md
CLAUDE.md / AGENTS.md / SKILL.md
events.dbstores what happened.syke.dbstores what Syke currently believes.MEMEX.mdis the current map returned to future work.- The raw timeline stays separate from learned memory.
CLI
syke ask "question" # deeper timeline and evidence-backed recall
syke context # current memex, instant local read
syke record "note" # write an observation back into memory
syke status # quick operational snapshot
syke doctor # deeper diagnostic
syke setup # start or repair the system
syke sync # manual refresh and synthesis cycle
Use syke ask when the agent needs more than the current memex. Use syke context when the current memex is enough and speed matters. Use syke record after useful work so the next session inherits it.
syke status is the quick snapshot. syke doctor is the deeper repair path.
Background sync commands
syke daemon start
syke daemon stop
syke daemon status
syke daemon logs
Platforms
Syke discovers supported local harnesses from descriptor files and their expected local paths. During setup, it scans those paths, checks what is actually present on disk, and ingests what it finds.
Supported local harnesses today:
- Claude Code: sessions, tools, projects, branches
- Codex: sessions, prompts, tool and model metadata
- Hermes: distribution and harness events
- OpenCode: sessions and model metadata
Current active discovery roots in code include:
~/.claude/projects~/.claude/transcripts~/.codex~/.hermes~/.local/share/opencode
All ingestion is local-first. Syke reads these surfaces from local files and local databases.
When a supported harness exposes a native skill directory, Syke can also install its SKILL.md there as part of distribution.
For supported harnesses, setup can bootstrap or repair missing adapters before the first ingest pass. It does this through the Observe factory, which reads local samples, generates or repairs an adapter, validates it, and deploys it into the user adapter directory.
If your harness layout is unusual, or if you want to connect a new harness yourself, use:
syke connect /path/to/your/harness
The factory auto-detects JSONL versus SQLite, uses the appropriate adapter path, and writes the result into Syke's local adapters directory. In practice, that means your agent can usually connect a new harness by pointing Syke at the real local path and following the contract.
Privacy and ownership
Canonical user stores live under ~/.syke/data/{user}/. The workspace mirrors current state locally for synthesis and ask flows.
events.dbis the immutable observed ledger.syke.dbis the learned-memory store.MEMEX.mdis the current memex returned to future sessions.- A content filter strips API keys, OAuth tokens, credential patterns, and private message bodies before ingest.
- Network calls go only to your configured LLM provider during ask and synthesis.
Users should have one place under their control for the scattered material their harnesses leave behind.
What changes when Syke is running
The simplest change is that your agents stop starting from blank.
A decision made in one harness can show up in the next place where it matters. A useful pattern does not have to stay trapped inside one session. A question like "what did I ship today?" can be answered from accumulated work instead of being rebuilt from scratch.
The bigger bet is that memory management itself should improve from use. Syke keeps the raw timeline separate from learned memory, then uses synthesis to keep reshaping the memex as a map. Over time, that lets the system learn better routes through a user's own history instead of forcing one fixed memory schema on everyone.
One controlled example: on February 26, 2026, the same question was asked against the same codebase in the same minute: "What did I ship today?" Manual multi-agent orchestration was compared with syke ask.
| Metric | Result |
|---|---|
| Token usage | 55% fewer tokens, from 970K to 431K |
| User-facing calls | 96% fewer calls, from 51 to 2 |
| Agents spawned | 3 to 0 |
This is one measured example from one workflow on one date. Freshness still has a gap of up to 15 minutes. The current claim is narrower and more useful: continuity can reduce reconstruction, and memory can get better at routing through repeated use.
Learn More
Start here
Runtime and internals
Story and evolution
Provider examples
syke auth set openai --api-key YOUR_KEY --model gpt-5-mini --use
syke auth set openrouter --api-key YOUR_KEY --use
syke auth use codex
syke auth set zai --api-key KEY --use
syke auth set kimi --api-key KEY --use
syke auth set azure --api-key KEY --endpoint URL --model MODEL --use
syke auth set ollama --model llama3.2 --use
syke auth set vllm --base-url URL --model MODEL --use
syke auth set llama-cpp --base-url URL --model MODEL --use
AGPL-3.0-only
Project details
Release history Release notifications | RSS feed
Download files
Download the file for your platform. If you're not sure which to choose, learn more about installing packages.
Source Distribution
Built Distribution
Filter files by name, interpreter, ABI, and platform.
If you're not sure about the file name format, learn more about wheel file names.
Copy a direct link to the current filters
File details
Details for the file syke-0.5.0.tar.gz.
File metadata
- Download URL: syke-0.5.0.tar.gz
- Upload date:
- Size: 247.2 kB
- Tags: Source
- Uploaded using Trusted Publishing? Yes
- Uploaded via: twine/6.1.0 CPython/3.13.7
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 |
823c3566193bef08fbfb6cc510bbddb659c5c21ee4f5d0c0783a7bf13e81e3f4
|
|
| MD5 |
2bb058d6b35a9ceef3acc84f8f13253f
|
|
| BLAKE2b-256 |
3e0cbf0fe5cbfaf1d78530308725e817c4233cd9a1c5717ebbb712d9954a712f
|
Provenance
The following attestation bundles were made for syke-0.5.0.tar.gz:
Publisher:
publish.yml on saxenauts/syke
-
Statement:
-
Statement type:
https://in-toto.io/Statement/v1 -
Predicate type:
https://docs.pypi.org/attestations/publish/v1 -
Subject name:
syke-0.5.0.tar.gz -
Subject digest:
823c3566193bef08fbfb6cc510bbddb659c5c21ee4f5d0c0783a7bf13e81e3f4 - Sigstore transparency entry: 1207693703
- Sigstore integration time:
-
Permalink:
saxenauts/syke@8d7b65784c9a0444c0b5145bf3e2daaef6a9dc34 -
Branch / Tag:
refs/tags/v0.5.0 - Owner: https://github.com/saxenauts
-
Access:
public
-
Token Issuer:
https://token.actions.githubusercontent.com -
Runner Environment:
github-hosted -
Publication workflow:
publish.yml@8d7b65784c9a0444c0b5145bf3e2daaef6a9dc34 -
Trigger Event:
push
-
Statement type:
File details
Details for the file syke-0.5.0-py3-none-any.whl.
File metadata
- Download URL: syke-0.5.0-py3-none-any.whl
- Upload date:
- Size: 192.3 kB
- Tags: Python 3
- Uploaded using Trusted Publishing? Yes
- Uploaded via: twine/6.1.0 CPython/3.13.7
File hashes
| Algorithm | Hash digest | |
|---|---|---|
| SHA256 |
20f686dd7c441c6fdaed95f21b19cf75aa83b4c169629e43517c55caa0771c06
|
|
| MD5 |
9aaaacdcc181cb231790c1d9891b82ac
|
|
| BLAKE2b-256 |
b6e96be29406d855e334027ad9de4b278a9acda0c8858dff66216aa5c51206ea
|
Provenance
The following attestation bundles were made for syke-0.5.0-py3-none-any.whl:
Publisher:
publish.yml on saxenauts/syke
-
Statement:
-
Statement type:
https://in-toto.io/Statement/v1 -
Predicate type:
https://docs.pypi.org/attestations/publish/v1 -
Subject name:
syke-0.5.0-py3-none-any.whl -
Subject digest:
20f686dd7c441c6fdaed95f21b19cf75aa83b4c169629e43517c55caa0771c06 - Sigstore transparency entry: 1207693739
- Sigstore integration time:
-
Permalink:
saxenauts/syke@8d7b65784c9a0444c0b5145bf3e2daaef6a9dc34 -
Branch / Tag:
refs/tags/v0.5.0 - Owner: https://github.com/saxenauts
-
Access:
public
-
Token Issuer:
https://token.actions.githubusercontent.com -
Runner Environment:
github-hosted -
Publication workflow:
publish.yml@8d7b65784c9a0444c0b5145bf3e2daaef6a9dc34 -
Trigger Event:
push
-
Statement type: