PowerContext
Not only memory but a full story: keep context with your work so humans and agents can hand off and pick up where things left off.
- Source repo
- oceanbase/powercontext
- Stars
- ★ 1.4k
- Last updated
- today
- License
- Apache-2.0
- Primary language
- Python
- FA score
- 55/100 · Major gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformCodex · Claude Code
- Cost
- Free, no paid service needed
- Setup effort
- Low · running in minutes
- You'll need
- Typical use
- A developer hands a coding task to Codex or Claude Code, and later resumes it in a new session or hands it to a teammate with decisions, progress, and next steps intact
- Not a fit if
- Teams needing official SDKs beyond Python; only HTTP API or MCP is documented
- Teams that want to mix tool and integration versions freely; both must share one Git ref
- Existing PowerMem users needing a migration path; none is described in the source
- Source review
- 55/100 · Major gaps
What does this agent do, and when should you use it?
PowerContext is an open-source context manager from OceanBase that solves the loss of reasoning and state when work is handed between people and agents. It stores durable information as Memory, organizes the current objective and state into a Handoff, and lets you record reusable approaches as Experience or Skill, keeping every item within the scope of the work with preserved sources and earlier revisions. It runs as a local Server that persists context in a local SQLite database by default, and agents can connect via MCP, an async Python client, an HTTP API, or the in-process Core SDK. Documented integrations cover Codex, Claude Code, DeepSeek Harness, Hermes Agent, OpenCode, LangChain, LangGraph, and more. Released under Apache-2.0, it ships 22 Chinese Jupyter tutorials, the first seven of which require no model or API key.
After installation, powercontext server run starts a local Server that persists context — confirmed decisions, constraints, progress, evidence, and next steps — into a local SQLite database. You decide what must travel with the task: durable facts become Memory, the current objective and state form a Handoff, and reusable approaches are stored as Experience or Skill, each retaining sources and prior revisions. A returning user or a new agent reads the current state and continues without rereading full history. powercontext setup codex --ref powercontext-v0.2.0 wires up a given agent integration, and powercontext service install installs a persistent native service that survives terminal closure. Applications integrate through the async Python client, HTTP API, MCP, or the in-process Core SDK.
- A developer hands a coding task to Codex or Claude Code, and later resumes it in a new session or hands it to a teammate with decisions, progress, and next steps intact
- Multi-agent pipelines where one agent hands its Handoff to the next agent to continue execution
- Teams that want to accumulate validated Experience and Skill entries that future tasks and members can reuse
- Developers building on LangChain or LangGraph who need cross-session long-term memory for their agents
- Users who need everything on-premise, running the full context service against a local SQLite store
- Beginners learning step by step: 22 Chinese Jupyter tutorials, the first seven needing no model or API key
How do you install or deploy this agent?
- Install the latest release:
uv tool install "powercontext[cli,server]==0.2.0". 2. (Optional) Try unreleased master:uv tool install --force "powercontext[cli,server] @ git+https://github.com/oceanbase/powercontext.git@master". 3. (Optional) Install the persistent native service:powercontext service install; check withpowercontext service status; remove withpowercontext service uninstall. On Windows, the installer asks about start-on-login; press Enter to keep it disabled or use--start-on-login/--no-start-on-login.
How do you use this agent?
- Start a local Server in its own terminal:
powercontext server run— context is stored in a local SQLite database by default. 2. Set up an agent integration, e.g.powercontext setup codex --ref powercontext-v0.2.0; keep the PowerContext tool and the agent integration on the same Git ref; for master, runpowercontext setup codex --source oceanbase/powercontext --ref master. 3. Other clients (Claude Code, OpenCode, LangChain, LangGraph, etc.) connect through MCP or a dedicated integration per the official agent setup guide. 4. Developers can build withmake install,make check,make test.
What are this agent's strengths and limitations?
- Four structured context types — Memory, Handoff, Experience, Skill — with preserved sources and revision history, so resumed work starts from the actual current state
- Four access paths (MCP, async Python client, HTTP API, Core SDK) covering mainstream agent clients and frameworks like LangChain/LangGraph
- Local-first SQLite storage with an optional persistent service; clear data boundary and fully self-hostable
- 22 Chinese Jupyter tutorials, the first seven requiring no model or API key, lowering the entry barrier
- The tool and agent integration must stay on the same Git ref; mismatched versions cause broken setups
- Benchmark comparisons on LoCoMo and SWE-bench Pro are summarized in the README but methods, full results, and limitations live on the website, not independently verifiable from the source alone
- The documented install path is a Python/uv CLI; no official SDKs for other languages are documented, so non-Python stacks must use HTTP API or MCP
- As the successor to PowerMem, no migration path from PowerMem is described in the source material
How does this agent compare with similar options?
The README states PowerContext is the successor to PowerMem; benchmark comparisons on LoCoMo and SWE-bench Pro are referenced on the official website, but the source does not name specific competing products.
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| PowerContext This agent | 55 · Major gaps | CLIFree | ★ 1.4k | today | Python | Codex · Claude Code |
| Hello-Agents | 54 · Major gaps | Web appFree + model costs | ★ 84k | 11d ago | Python | OpenAI API |
| Understanding AI Agents: Design Principles and Engineering Practice | 41 · Major gaps | CLIFree + model costs | ★ 56k | 16d ago | Python | — |
| GenAI Agents Comprehensive Tutorial Collection | 25 · Major gaps | Library / SDKFree + model costs | ★ 25k | 2d ago | Jupyter Notebook | OpenAI API |
How does FollowAgents rate this agent?
Why each dimension lost points
Least privilege and dependency security have solid evidence: CI workflows declare contents:read minimal permissions, use locked dependencies with --require-hashes and sha256 verification, and the server defaults to 127.0.0.1. Deductions: user confirmation, data-flow transparency, and sensitive-data handling are only implied (commented AUTH_TOKEN in env example) with no visible implementation; no documented rollback path; external side effects (local SQLite writes, hooks injected into agent sessions) are not scoped in the visible files.
Self-consistency: README, pyproject, and CI agree (version refs, 0.2.0, script entry points). Dependency availability: uv lock --locked, offline wheelhouse, and smoke tests show supply-chain availability is taken seriously. Failure messages: doctor/ready endpoints exist, but the visible files lack concrete error-message examples, so 1.
Audience and scenarios are clear (developer/agent users) with a labeled integration matrix (official/community/evaluation). Capability boundaries are explicit (Windows experimental, Bub evaluation-only, Python 3.11+). Trigger precision: hooks (SessionStart/PreToolUse/UserPromptSubmit) exist but their semantics are only inferable from build scripts; docs are out of view. Environment fit is supported by platform matrices and Docker amd64/arm64 builds.
License is full marks: complete Apache-2.0 text consistent with badges and file headers. Install notes are thorough including generated offline INSTALL.md with checksums. Known limitations visible via benchmark-limits link and Windows tag. Versioning uses hatch-vcs, PyPI badge, pinned-ref installs, but no CHANGELOG file is visible. Maintenance responsibility: contact email and OceanBase copyright headers exist but no maintenance commitment document is visible. Information architecture inferred from directory references: 2.
Marginal value is clear: cross-session, cross-agent context handoff with Memory/Handoff/Experience/Skill models plus LoCoMo/SWE-bench Pro comparisons. Cost-benefit is reasonable: local SQLite default and split extras (builtin/client/server/cli). Output usability: the static review can only see declared entry points (async client, HTTP API, MCP, SDK); actual output shape is not demonstrable from these files, so 1.
Fact/inference separation is decent: official/community/evaluation tags describe maintenance status rather than inflating capability. Claim traceability and cross-source corroboration are weak: benchmark results appear only as README graphics pointing to an external site, unverifiable from the visible files; the visible e2e scripts cover only three narrow harbor tasks and cannot corroborate overall claims.
- This static review is based only on README, LICENSE, pyproject, and CI build files; core implementation source was not in scope, so confidence is low.
- Server auth defaults to AUTH_ENABLED=false and the auth token appears only as a commented example; explicitly enable authentication and verify data flow before production use.
- Installed hooks execute code on every agent session event (SessionStart/PreToolUse/UserPromptSubmit); review hook script contents and data destinations before deployment.
- Benchmark comparisons point to an external site and cannot be verified from the repository; treat them as unvalidated performance claims.
- The context database holds work-sensitive information; confirm the default SQLite storage location plus encryption/retention policy — no rollback/migration documentation is visible.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
powercontext-v1.4.0 PowerContext v1.4.0
Release notes excerpt
PowerContext v1.4.0 Not only memory, but a full story. English PowerContext v1.4.0 helps project knowledge evolve while keeping work and changes traceable. This release introduces explicit Dream reviews, Working Notes for current progress, Dashboard revision history and comparison, and an experimental Kimi Code integration. Dream: evolve knowledge through review - Use task outcomes, explicit corrections, or usage feedback as a reason to start Dream. Select the relevant knowledge and evidence, then inspect the proposed changes. …View on GitHub ↗ -
powercontext-v1.3.0 PowerContext v1.3.0
Release notes excerpt
PowerContext v1.3.0 Not only memory, but a full story. English PowerContext v1.3.0 makes project knowledge easier to manage and reuse. It introduces independent Atomic Memory, versioned decision policies, Artifact search and shared merge/restoration workflows, a Windows Desktop preview, and an experimental Dify integration. Independent Atomic Memory - Store each fact, preference, or decision as an independent atomic-memory Artifact with immutable content revisions, exact evidence references, and a separate lifecycle. …View on GitHub ↗ -
v1.1.7 PowerMem v1.1.7
Release notes excerpt
What's Changed * fix(ci): dispatch publish workflow without git checkout by @wayyoungboy in https://github.com/oceanbase/powermem/pull/1116 * feat(plugin): enable transcript inference by default; remove recall/remember skills by @lightzt99 in https://github.com/oceanbase/powermem/pull/1126 * Fix powermem-mcp help to exit without starting the server by @wayyoungboy in https://github.com/oceanbase/powermem/pull/1124 * fix(ci): avoid duplicate generated release notes by @wayyoungboy in https://github.com/oceanbase/powermem/pull/1123 …View on GitHub ↗