[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"project-3006":3},{"id":4,"name":5,"fullName":6,"owner":7,"repo":5,"description":8,"homepage":9,"htmlUrl":10,"language":11,"languages":10,"totalLinesOfCode":10,"stars":12,"forks":13,"watchers":14,"openIssues":15,"contributorsCount":16,"subscribersCount":16,"size":16,"stars1d":17,"stars7d":18,"stars30d":19,"stars90d":16,"forks30d":16,"starsTrendScore":20,"compositeScore":21,"rankGlobal":10,"rankLanguage":10,"license":10,"archived":22,"fork":22,"defaultBranch":23,"hasWiki":24,"hasPages":22,"topics":25,"createdAt":10,"pushedAt":10,"updatedAt":26,"readmeContent":27,"aiSummary":28,"trendingCount":16,"starSnapshotCount":16,"syncStatus":29,"lastSyncTime":30,"discoverSource":31},3006,"pi-context-prune","championswimmer\u002Fpi-context-prune","championswimmer","Pi coding-agent extension for pruning tool-call trees","",null,"TypeScript",184,13,82,5,0,7,9,97,21,3.44,false,"main",true,[],"2026-06-12 02:00:45","# pi-context-prune\n\nA [Pi coding-agent](https:\u002F\u002Fgithub.com\u002Fbadlogic\u002Fpi-mono) extension that **summarizes completed tool-call batches**, prunes raw tool outputs from future LLM context, and exposes a `context_tree_query` escape hatch to recover any original output on demand.\n\n## Related Extensions\n\nHere are some other Pi extensions that work well alongside context pruning:\n\n*   **[pi-context-usage](https:\u002F\u002Fgithub.com\u002Fchampionswimmer\u002Fpi-context-usage) ([npm](https:\u002F\u002Fwww.npmjs.com\u002Fpackage\u002Fpi-context-usage))**\n    *   **What it does:** Visualizes the current size of your LLM context and breaks it down to show exactly what is taking up space (system prompt, user messages, tool calls, tool results, etc.).\n    *   **Why use it:** It's the perfect way to see *why* you need pruning. You can use it to inspect your context before and after a prune to see exactly how much space the `pi-context-prune` extension just saved you.\n*   **[pi-cache-graph](https:\u002F\u002Fgithub.com\u002Fchampionswimmer\u002Fpi-cache-graph) ([npm](https:\u002F\u002Fwww.npmjs.com\u002Fpackage\u002Fpi-cache-graph))**\n    *   **What it does:** Plots your provider's prefix cache hits and misses as a live graph inside the TUI.\n    *   **Why use it:** Pruning context directly impacts cache re-use. This extension lets you see the real-time effect of your chosen `pruneOn` mode on cache stability.\n\n---\n\n## Why\n\n> 📖 For a deep dive into how pruning works, how prefix caching interacts with it, and the research behind summarization-based context management, see [**PRUNING.md**](PRUNING.md).\n\nAs long agent sessions grow, every tool call adds token-heavy output to the context window. Most of it is not needed verbatim after the first use. This extension:\n\n1. **Detects** when an assistant turn finishes calling tools (`turn_end`)\n2. **Summarizes** that batch of tool calls using your configured model\n3. **Injects** a compact summary message before the next LLM call (`deliverAs: \"steer\"`)\n4. **Prunes** the original verbose tool outputs from future context (`context` event)\n5. **Preserves** every original output in the session index — retrievable at any time via `context_tree_query`\n\nThe session file is never modified. Pruning only affects the next request's context build.\n\n## Installation\n\n### Install from npm (stable releases)\n\nThe package is published on [npmjs.org](https:\u002F\u002Fwww.npmjs.com\u002Fpackage\u002Fpi-context-prune). Use this for stable, versioned releases:\n\n```bash\n# Install globally (all projects)\npi install npm:pi-context-prune\n\n# Or install for the current project only\npi install -l npm:pi-context-prune\n```\n\nOnce installed, the extension is auto-loaded every time you run `pi`. No flags needed.\n\nTo **upgrade to a newer release**, simply re-run the install command — Pi will pull the latest version from npm.\n\n### Install from GitHub (cutting-edge \u002F main branch)\n\nIf you want the latest unreleased changes from `main`, install directly from the git repository:\n\n```bash\n# Install globally (all projects)\npi install git:github.com\u002Fchampionswimmer\u002Fpi-context-prune\n\n# Or install for the current project only\npi install -l git:github.com\u002Fchampionswimmer\u002Fpi-context-prune\n```\n\n> **Note:** The `main` branch may contain unreleased or experimental changes. Prefer the npm install for day-to-day use.\n\n### Try without installing\n\n```bash\n# Load for this session only (no install)\npi -e npm:pi-context-prune\n\n# Or try the latest from git without installing\npi -e git:github.com\u002Fchampionswimmer\u002Fpi-context-prune\n```\n\n### From source (development)\n\n```bash\ngit clone https:\u002F\u002Fgithub.com\u002Fchampionswimmer\u002Fpi-context-prune\ncd pi-context-prune\npi -e .\n```\n\n### Manage installed extensions\n\n```bash\npi list           # show installed packages\npi remove pi-context-prune\n```\n\n## Prune-On Modes\n\nThe extension supports five trigger modes controlling **when** summarization and pruning happen.\n\n### Cache-aware guidance\n\nThis extension rewrites the **future request context** by replacing old raw `toolResult` messages with a compact summary. That saves tokens, but it also changes the prompt prefix seen by the model.\n\nOn providers with **prefix \u002F prompt caching** (for example Anthropic-style prompt caching), cache hits require the earlier prompt prefix to stay identical. If you keep changing earlier context, the provider has to recompute from the point of change onward, which means **higher latency, higher input cost, and fewer cache hits**. In other words: pruning too often can save tokens in-context while still hurting overall performance by repeatedly busting the provider cache.\n\nThat is why **`agent-message` is the default**: it batches a whole stretch of tool work, prunes **once** when the agent is done and sends a final text reply, and then leaves the new shorter context stable again. You usually pay one cache bust per meaningful work batch instead of one cache bust per tool turn.\n\nReferences:\n- Anthropic prompt caching docs: \u003Chttps:\u002F\u002Fdocs.claude.com\u002Fen\u002Fdocs\u002Fbuild-with-claude\u002Fprompt-caching>\n- AWS Bedrock prompt caching overview: \u003Chttps:\u002F\u002Fdocs.aws.amazon.com\u002Fbedrock\u002Flatest\u002Fuserguide\u002Fprompt-caching.html>\n- `pi-context` extension (`context_tag`, `context_log`, `context_checkout`): \u003Chttps:\u002F\u002Fgithub.com\u002Fttttmr\u002Fpi-context>\n\n### Mode trade-offs\n\n| Mode | Trigger | Pros | Cons \u002F cache impact | Recommendation |\n|---|---|---|---|---|\n| `every-turn` | Immediately after each tool-calling turn | Smallest raw context as fast as possible; easiest to reason about | **Busts prompt cache the most often** because earlier context is rewritten after almost every tool turn; adds summarizer latency every turn; can cost more overall despite saving context tokens | **Debugging only.** Useful to test the extension, inspect summaries, or study behavior — not recommended for normal day-to-day use |\n| `on-context-tag` | When `context_tag` is called | Lets you align pruning with explicit milestones \u002F save-points; fewer cache busts than `every-turn` if you tag sparingly | Only auto-triggers if you have the [`pi-context`](https:\u002F\u002Fgithub.com\u002Fttttmr\u002Fpi-context) extension installed, because that extension provides the `context_tag` tool; if you tag too often, you still churn cache; if you forget to tag, pending batches keep growing | Good if you already use `pi-context` and think in checkpoints \u002F milestones |\n| `on-demand` | Only when you run `\u002Fpruner now` | Maximum manual control; easiest mode for preserving cache because nothing changes until you decide; good for long investigations where you want to delay pruning | Easy to forget; pending batches can grow large; you must manage timing yourself | Good for advanced users who want explicit control over when the cache is intentionally invalidated |\n| `agent-message` | When the agent sends a final text-only response, or when the agent loop ends | Best balance of automation, context savings, and cache friendliness; batches many tool turns into one prune; after the prune, future requests become highly cacheable again until the next batch finishes | You do not reclaim space mid-batch; if a run goes extremely long before the final reply, context can grow more than in aggressive modes | **Recommended default.** Safest general-purpose mode for normal coding-agent workflows |\n| `agentic-auto` | The model decides by calling `context_prune` | Lets the agent compact context before it gets too large; can work well for long autonomous runs when the model is disciplined | Depends on model judgment; if the model calls `context_prune` too often, it can churn cache similarly to `every-turn`; behavior is less predictable than `agent-message` | Good for longer autonomous sessions after prompt-tuning and observation |\n\n### How each mode works\n\n**`every-turn`** — Every tool-calling turn is summarized and pruned immediately. This is intentionally aggressive. It is useful for debugging the extension or validating summaries, but in real work it usually rewrites the prompt prefix too frequently and hurts provider-side prompt caching.\n\n**`on-context-tag`** — Tool-call turns are queued until `context_tag` is called, then all pending batches are summarized in one LLM call and pruned together. This mode is meant to pair with the [`pi-context`](https:\u002F\u002Fgithub.com\u002Fttttmr\u002Fpi-context) extension; without that extension, `context_tag` is not available, so this mode will not auto-trigger unless you switch modes or flush manually with `\u002Fpruner now`.\n\n**`on-demand`** — Tool-call turns are batched but never summarized automatically. You decide when to flush with `\u002Fpruner now`. This is the most manual mode and also the easiest to keep cache-friendly, because you can wait until a large chunk of work is complete before changing earlier context.\n\n**`agent-message`** — Tool-call turns are batched. When the agent finally replies with a normal text answer (a turn with no tool calls), all pending batches are summarized and pruned together. If the agent loop ends before that happens, a safety-net flush runs on `agent_end`. This mode is the default because it usually causes just one context rewrite per meaningful task batch.\n\n**`agentic-auto`** — The `context_prune` tool is activated and exposed to the LLM. The system prompt tells the model to use it only after a meaningful batch of related tool calls, not after every small step. Used well, this gives the agent flexibility; used badly, it can over-prune and reduce cache effectiveness.\n\n## Commands\n\nThe extension registers the `\u002Fpruner` command:\n\n| Command | Effect |\n|---|---|\n| `\u002Fpruner` | Interactive picker over all subcommands |\n| `\u002Fpruner settings` | Opens an interactive settings overlay |\n| `\u002Fpruner on` | Enable pruning |\n| `\u002Fpruner off` | Disable pruning |\n| `\u002Fpruner status` | Show enabled state, summarizer model, thinking level, prune trigger, and cumulative stats |\n| `\u002Fpruner model` | Show current summarizer model |\n| `\u002Fpruner model \u003Cid>` | Set summarizer model (e.g. `anthropic\u002Fclaude-haiku-3-5`) |\n| `\u002Fpruner model \u003Cid>:\u003Cthinking>` | Set summarizer model and thinking together (e.g. `openai\u002Fgpt-5-mini:low`) |\n| `\u002Fpruner thinking` | Show current summarizer thinking level |\n| `\u002Fpruner thinking \u003Clevel>` | Set summarizer thinking (`default`, `off`, `minimal`, `low`, `medium`, `high`, `xhigh`) |\n| `\u002Fpruner prune-on` | Interactive picker over all trigger modes |\n| `\u002Fpruner prune-on \u003Cmode>` | Set trigger mode directly |\n| `\u002Fpruner stats` | Show cumulative summarizer token\u002Fcost stats |\n| `\u002Fpruner tree` | Browse pruned tool calls in a foldable tree browser; press `Ctrl-O` on a summary to open it in a bordered overlay |\n| `\u002Fpruner now` | Flush pending tool calls immediately (works in all modes) with a live progress overlay that shows streamed received-character counts per batch |\n| `\u002Fpruner help` | Show full help text |\n\n### Settings overlay\n\n`\u002Fpruner settings` opens a TUI overlay with five interactive items:\n\n1. **Enabled** — toggle pruning on\u002Foff\n2. **Prune status line** — show or hide the footer status widget and queued turn notifications\n3. **Prune trigger** — cycle through all five `pruneOn` modes\n4. **Summarizer model** — press Enter to open a searchable submenu listing `\"default\"` plus all available models\n5. **Summarizer thinking** — cycle through the thinking\u002Freasoning level used for summarizer calls\n\nAll changes are saved immediately to `~\u002F.pi\u002Fagent\u002Fcontext-prune\u002Fsettings.json` and reflected in the footer status widget when it is enabled.\n\n## Tools\n\n### `context_tree_query`\n\nWhen pruning is on, the LLM sees compact summary messages instead of raw tool outputs. Each summary ends with short aliases such as:\n\n```\nSummarized tool refs: `t1`, `t2`\nUse `context_tree_query` with these refs to retrieve the original full outputs.\n```\n\nThose short refs are generated by the extension and mapped back to the real `toolCallId`s in the summary message metadata. The LLM only sees the short refs in future context; the full IDs stay in the stored details used by `context_tree_query` and internal tree\u002Fbrowser recovery. The tool is always available when the extension is loaded.\n\n### `context_prune` (agentic-auto mode only)\n\nWhen `pruneOn` is set to `agentic-auto`, the `context_prune` tool is activated and made available to the LLM. It is removed from the active tool list in all other modes.\n\nWhen the model calls `context_prune`:\n- All pending tool-call batches are summarized together (parallel one-call-per-batch by default, or sequentially in `\u002Fpruner now` so the overlay can show live progress)\n- While the tool is running, compact live progress is streamed into the tool output box above the input (for example `Context prune running… batch 2\u002F4 · 1.2k chars received`)\n- If the summary is smaller than the raw tool-result text it would replace, the original outputs are pruned from future context and a summary message is injected as a steer\n- If the summary is larger than the raw tool-result text, pruning is skipped for that attempted range: the original tool results remain in context, but the prune frontier still advances so the next prune attempt starts after that range instead of retrying it forever\n\nThe tool is guided by a system prompt that instructs the model to use it after completing a meaningful batch of work (not after every trivial call).\n\n## Configuration\n\nConfig is stored in `~\u002F.pi\u002Fagent\u002Fcontext-prune\u002Fsettings.json` (global, project-independent):\n\n```json\n{\n  \"enabled\": false,\n  \"showPruneStatusLine\": true,\n  \"summarizerModel\": \"default\",\n  \"summarizerThinking\": \"default\",\n  \"pruneOn\": \"agent-message\",\n  \"remindUnprunedCount\": true\n}\n```\n\n| Key | Values | Default |\n|---|---|---|\n| `enabled` | `true` \u002F `false` | `false` |\n| `showPruneStatusLine` | `true` \u002F `false` | `true` |\n| `summarizerModel` | `\"default\"` or `\"provider\u002Fmodel-id\"` | `\"default\"` |\n| `summarizerThinking` | `\"default\"`, `\"off\"`, `\"minimal\"`, `\"low\"`, `\"medium\"`, `\"high\"`, `\"xhigh\"` | `\"default\"` |\n| `pruneOn` | `\"every-turn\"`, `\"on-context-tag\"`, `\"on-demand\"`, `\"agent-message\"`, `\"agentic-auto\"` | `\"agent-message\"` |\n| `remindUnprunedCount` | `true` \u002F `false` | `true` |\n\n- `showPruneStatusLine: true` keeps the prune footer widget and the automatic queued-turn notice visible. Turn it off if you want pruning to stay active without the extra status noise.\n- `remindUnprunedCount: true` appends a small ephemeral `\u003Cpruner-note>` to the last tool result before each LLM call to remind the model of the number of unpruned tool calls in context. This only has an effect when `pruneOn` is set to `\"agentic-auto\"`.\n\n- `summarizerModel: \"default\"` means the current active Pi model. An explicit value like `\"anthropic\u002Fclaude-haiku-3-5\"` uses that model for summarization (must be registered in Pi and have an API key).\n- `summarizerThinking: \"default\"` preserves old behavior: no explicit thinking\u002Freasoning option is added to summarizer calls.\n- `summarizerThinking: \"off\"` requests no summarizer reasoning where the provider adapter supports an explicit disable path. Some providers may still fall back to their own default behavior.\n- `\"minimal\"`, `\"low\"`, `\"medium\"`, `\"high\"`, and `\"xhigh\"` request that thinking level for summarizer calls where supported. For cheap background summarization, prefer `\"minimal\"` or `\"low\"` with a small\u002Ffast model.\n- Settings are persisted on every change via the `\u002Fpruner` command or the settings overlay.\n\n### Choosing a Summarizer Model\n\nThe default (`\"default\"`) reuses whatever model you have active in Pi. **This is convenient but wasteful** — you don't need a powerful coding model to write a bullet-point summary of tool outputs. Using a cheaper, faster model here reduces both latency and cost without any quality trade-off.\n\n> **Rule of thumb:** pick the smallest\u002Ffastest model available on your current subscription or API plan.\n\n| Subscription \u002F API plan | Recommended summarizer model |\n|---|---|\n| GitHub Copilot \u002F Codex | `openai\u002Fgpt-4.1-mini` or `google\u002Fgemini-2.5-flash` or `xai\u002Fgrok-3-fast` |\n| OpenRouter | `openrouter\u002Fqwen\u002Fqwen3-30b-a3b` (fast MoE, very cheap) |\n| Anthropic direct | `anthropic\u002Fclaude-haiku-3-5` |\n| Google AI direct | `google\u002Fgemini-2.5-flash` |\n\nSet it with:\n\n```bash\n\u002Fpruner model openai\u002Fgpt-4.1-mini\n\u002Fpruner thinking low\n\n# Or set both at once:\n\u002Fpruner model openai\u002Fgpt-4.1-mini:low\n\n# Or via the interactive settings overlay\n\u002Fpruner settings\n```\n\nOr directly in `~\u002F.pi\u002Fagent\u002Fcontext-prune\u002Fsettings.json`:\n\n```json\n{\n  \"summarizerModel\": \"openrouter\u002Fqwen\u002Fqwen3-30b-a3b\",\n  \"summarizerThinking\": \"low\"\n}\n```\n\n## Architecture\n\n```\nindex.ts                    — entry point, wires events + modules\nsrc\u002F\n  types.ts                  — shared types, constants, PruneOn modes\n  config.ts                 — load\u002Fsave ~\u002F.pi\u002Fagent\u002Fcontext-prune\u002Fsettings.json\n  batch-capture.ts          — serialize turn_end event → CapturedBatch\n  summarizer.ts             — resolve model, call LLM, build summary text\n  indexer.ts                — Map\u003CtoolCallId, ToolCallRecord> + session persistence\n  pruner.ts                 — filter context event messages\n  query-tool.ts             — context_tree_query tool registration\n  context-prune-tool.ts     — context_prune tool registration (agentic-auto)\n  frontier.ts               — persisted prune-frontier tracker for last attempted prune boundary\n  stats.ts                  — StatsAccumulator for cumulative token\u002Fcost tracking\n  tree-browser.ts           — foldable tree browser for \u002Fpruner tree\n  commands.ts               — \u002Fpruner command + settings overlay + message renderer\n```\n\n### Event flow\n\n```\nsession_start\n  └─► loadConfig()              read ~\u002F.pi\u002Fagent\u002Fcontext-prune\u002Fsettings.json\n  └─► indexer.reconstruct()     rebuild Map from session branch entries\n  └─► statsAccum.reconstruct()  rebuild stats from session branch entries\n  └─► frontier.reconstruct()    rebuild last prune-attempt boundary from session entries\n  └─► syncToolActivation()      activate\u002Fdeactivate context_prune tool\n\nsession_tree\n  └─► indexer.reconstruct()     rebuild Map (branch may have different history)\n  └─► statsAccum.reconstruct()  rebuild stats (branch may have different history)\n  └─► frontier.reconstruct()    rebuild last prune-attempt boundary for the branch\n  └─► clear pendingBatches      discard queued batches from old branch\n\nturn_end (tool calls present + enabled)\n  └─► captureBatch()            serialize the tool call batch\n  └─► trim against index\u002Ffrontier so same-turn later tool calls survive an earlier mid-turn prune\n  └─► push remaining tool calls to pendingBatches\n  └─► if every-turn: flushPending() immediately\n  └─► otherwise: notify user of pending count + trigger\n\ntool_execution_end (context_tag, on-context-tag mode)\n  └─► flushPending()\n\nagent_end\n  └─► update footer status only if batches remain pending\n\ncontext_prune tool call (agentic-auto mode)\n  └─► flushPending()\n\nflushPending()\n  └─► scan the session branch for completed unpruned tool results, including mid-turn subsets\n  └─► trim against index\u002Ffrontier so already-attempted prefixes are ignored\n  └─► summarizeBatches()         call LLM(s) → summary text + usage stats\n  └─► compare summary chars vs raw tool-result chars\n  └─► if smaller: persist index + inject summary, then advance frontier\n  └─► if larger: keep original tool results, skip summary\u002Findex writes, still advance frontier\n  └─► statsAccum.add()\u002Fpersist() accumulate token\u002Fcost stats for the summarizer call\n\ncontext (enabled + index non-empty)\n  └─► pruneMessages()            remove toolResult messages in the index\n\nbefore_agent_start (agentic-auto mode)\n  └─► append AGENTIC_AUTO_SYSTEM_PROMPT to system prompt\n```\n\n### Session persistence\n\n- **Config** lives in `~\u002F.pi\u002Fagent\u002Fcontext-prune\u002Fsettings.json` — the extension's own file, independent of Pi's project settings\n- **Index** is persisted via `pi.appendEntry(\"context-prune-index\", { toolCalls })` — one entry per summarized batch, NOT in LLM context\n- **Prune frontier** is persisted via `pi.appendEntry(\"context-prune-frontier\", ...)` — it records the last attempted prune boundary even when an oversized summary is rejected\n- **Summaries** are injected as `custom_message` entries with `customType: \"context-prune-summary\"` — these ARE in LLM context (replacing the raw outputs only when pruning is accepted). Their visible text uses short refs, while the `details.toolCallRefs` metadata keeps the full `toolCallId` mapping for later recovery.\n- The underlying session JSONL file always retains the original `ToolResultMessage` entries unchanged\n\n### Footer status widget\n\nThe extension registers a status widget in the Pi footer that shows the current state:\n\n- `prune: OFF (On agent message)` — pruning disabled, showing what mode it would use\n- `prune: ON (On agent message)` — pruning active with the current trigger mode\n- `prune: ON (Every turn) │ ↑1.2k ↓340 $0.003` — pruning active with cumulative stats (input\u002Foutput tokens, cost)\n- `prune: 3 pending` — batches queued, waiting for the trigger\n- `prune: summarizing…` — currently running the summarizer LLM call\n- Live progress details are shown in richer surfaces instead: `\u002Fpruner now` uses the multi-row overlay, and agentic-auto `context_prune` streams updates in the tool output box above the input\n- When `showPruneStatusLine` is `false`, the footer stays clear and the queued-turn notice is suppressed, but pruning still works normally.\n\n## v1 Limitations\n\n- Summarization only runs when pruning is **enabled**. If you enable it mid-session, earlier turns are not retroactively summarized.\n- The `context_tree_query` tool is only active when the extension is loaded.\n- The `context_prune` tool is only activated in `agentic-auto` mode.\n- The summarizer call happens synchronously inside `turn_end`, adding latency between turns proportional to the summarizer model's response time.\n- Mid-turn pruning now supports completed subsets of a longer tool chain, but batching is still based on assistant-message groups rather than arbitrary semantic task labels.\n- The `\u002Fpruner tree` browser shows pruned tool calls grouped under their summaries. Press `Ctrl-O` on a summary node to open the full pruned summary message in a bordered overlay. It still does not recover full original tool outputs inline (use `context_tree_query` for that).\n- Summary grouping across multiple turns (e.g., \"compress the last 5 summaries\") is a follow-up item.\n\n## Follow-up ideas\n\n- Auto-summarize older unsummarized turns on `\u002Fpruner on`\n- Batch multiple turn summaries into a single meta-summary at compaction time\n- ~~`\u002Fpruner original-tree`~~ ✅ `\u002Fpruner tree` foldable tree browser — done\n- Configurable pruning policy (prune only large tool results, prune by token count threshold)\n- Tighter `\u002Fsettings` integration once Pi exposes a settings UI API","pi-context-prune 是一个用于 Pi coding-agent 的扩展，旨在通过总结已完成的工具调用批次并从未来的LLM上下文中移除原始工具输出来优化上下文管理。它能够在助手完成一轮工具调用后自动检测、总结，并将简洁的摘要注入到下一个LLM请求中，同时保留所有原始输出以供按需检索。该扩展采用TypeScript编写，特别适用于需要长时间运行且频繁调用外部工具的应用场景，如复杂的对话系统或基于AI的工作流自动化项目，有助于减少不必要的上下文负担，提高处理效率。",2,"2026-06-11 02:52:08","CREATED_QUERY"]