Canner/wren-engine is merging into Canner/WrenAI — both repos frozen now

[goldmedal]

We're consolidating Wren's open-source projects. On 2026-05-05, the contents of Canner/wren-engine will be merged into Canner/WrenAI under a new core/ directory. Shortly after, Canner/wren-engine will be archived (read-only).

TL;DR for you:

• If you pip install wren-core-py / wren-engine or npm install @wrenai/wren-core-wasm — nothing changes. Same package names, version numbers stay continuous.
• No new PRs will be accepted on either repo from today. If you were planning to open one, please hold it. After the migration completes (2026-05-07), open it on Canner/WrenAI against core/<module>/ instead. If you have something already in flight that's urgent, reach us on Discord (#general) and we'll coordinate.
• If you depend on ibis-server, mcp-server, or the Java engine in wren-core-legacy — these modules will be archived (no new releases). Pin to the last published version. We'll publish a separate migration note for these.

Why we're doing this

1. Repo positioning is confusing. Users and contributors keep asking which repo is the "main" project. Some point at wren-engine, others at WrenAI, and the relationship between them isn't obvious. One repo removes that ambiguity.
2. Two-repo overhead is slowing us down. Splitting the engine, SDKs, integrations, and skills across two repos created duplicate issues, mismatched release cadences, and two READMEs to keep in sync.

After the merge, Canner/WrenAI becomes the single home for:

Open Context Engine for AI Agents

Timeline

Date	Day	What happens
2026-04-30	Thu	This announcement (today). main on both repos becomes admin-only the same day; no new PRs accepted.
2026-05-04	Mon	Consolidation work begins on the now-frozen repos
2026-05-05	Tue	Import PR merges on Canner/WrenAI. Old WrenAI app preserved on legacy/v1 branch (tag v1-final).
2026-05-06	Wed	First release published from new repo (smoke test)
2026-05-07	Thu	Canner/wren-engine archived
2026-05-08	Fri	Buffer / cleanup

What's NOT changing

• Code under core/ stays Apache 2.0 (same as today's wren-engine). The new repo uses a multi-license layout: code is Apache 2.0, docs/ will be CC BY 4.0, with AGPL-3.0 reserved for some future modules. Full license map will be at the repo root.
• Package names on PyPI / npm: unchanged.
• git blame: preserved. We're using git filter-repo so per-commit authorship survives the move.
• Issues & PR history on wren-engine: stay accessible (the repo becomes read-only, not deleted).

Where to ask questions

• Open an issue on this repo with the migration label
• Or comment on this discussion
• Or join us in #general on Discord

We'll be watching closely for the next two weeks. Thanks for your patience while we tidy up the OSS — it'll be easier to contribute to and easier to use afterwards.

[YuzhouZhang]

Hi Team,

Thanks for the clear roadmap on the repository consolidation.

I have a question regarding the future of the Wren AI user interface. Will the new consolidated repo continue to support the original visual interface, specifically the modeling and knowledge functionalities?

Many of us rely on these visual tools for our workflow, so I’d love to know if they will be integrated into the new core/ structure or maintained in another way.

Best regards,

[goldmedal]

Hi Team,

Thanks for the clear roadmap on the repository consolidation.

I have a question regarding the future of the Wren AI user interface. Will the new consolidated repo continue to support the original visual interface, specifically the modeling and knowledge functionalities?

Many of us rely on these visual tools for our workflow, so I’d love to know if they will be integrated into the new core/ structure or maintained in another way.

Best regards,

@YuzhouZhang Thanks for asking — this is a fair concern and I should have addressed it more clearly in the original announcement.

TL;DR

The visual UI (wren-ui, including the modeling and knowledge views you're referring to) is not being migrated into core/ on the new main. It's preserved on the legacy/v1 branch (tag v1-final) and remains usable, but it won't receive new features.

Why we're doing this

The new Canner/WrenAI is being repositioned as an Open Context Engine for AI Agents — the primary user is an LLM agent or MCP client interacting programmatically, rather than a human clicking through a UI. The engine, SDKs, skills, and integrations are what we'll actively develop.

Where modeling and knowledge go in the new world

The good news: both have direct, concrete replacements in core/wren/ (the wren CLI). They're not gone — they've moved from "GUI in a browser" to "files + CLI + an indexed memory layer that agents can query".

Modeling

YAML-based MDL projects + the memory index:

• wren context init and wren context build manage your MDL as version-controllable YAML files (models, relationships, views).
• wren memory index then indexes the compiled MDL into a LanceDB-backed semantic memory so agents can fetch relevant schema context on demand.
• The MDL JSON schema lives at core/wren-mdl/, so any UI — yours, ours, or a community one — can read and write it.

Knowledge

The memory layer (wren memory).

This is the cleaner part of the story. The "Knowledge" features in wren-ui (business glossary, instructions, curated NL-SQL examples) map directly to two file-based primitives that the engine indexes:

1. instructions.md in your project — free-text business context, glossary terms, and rules. Indexed alongside the schema so agents see them in retrieval results.
2. queries.yml — curated NL → SQL pairs that act as few-shot examples for future questions. You can hand-author them, or let wren memory store accumulate them during use and wren memory dump --source user export them back to YAML for review and version control.

Both are loaded into a LanceDB index by wren memory index and queried by the agent via wren memory recall (find similar past queries) and wren memory fetch (get relevant schema context). Full docs: https://docs.getwren.ai/oss/engine/guide/memory.

This is arguably a stronger model than the UI flow for two reasons: (a) it's git-versionable and code-reviewable, (b) it's the same data the engine actually uses at query time, so there's no UI/engine drift.

GenBI UI

A new GenBI app built on top of core/ is on the roadmap — design is in progress, and we'll share more once it's ready to preview. In the meantime, the recommended GenBI surface is an agentic client (Claude Code, Cursor,...) connected to the wren CLI, which already covers NL → SQL → results with memory recall.

What you can do today

1. Continue using legacy/v1 — it's frozen, not deleted. The Docker images on GHCR up to 0.29.1 stay published. You can spin up the full GenBI stack from that branch indefinitely if a UI is non-negotiable.
2. Migrate to the CLI + memory flow — start from the installation guide and quickstart to set up the new engine and CLI. The modeling and memory guides walk through schema and knowledge in the new system.
3. Build or sponsor a UI on top of core/. Apache 2.0, so a community-maintained or paid UI on top of the new engine is welcome.