Two small changes that make a big difference - Elyra v0.7.7

The cache problem nobody talks about

Every time you send a message to Claude, Elyra includes your system prompt, tool definitions, pinned files, and the full conversation history. Anthropic caches this content so you don't pay full price for the same prefix on every request. The cache works on prefixes — if the first N bytes of your request match a previous request, those bytes are served from cache at a 90% discount.

Elyra was leaving money on the table. Here's why.

The first message in every conversation contained two things: your pinned files and the current date. They were packed into the same content block, date first:

[
  { "type": "text", "text": "Current date: 2026-05-23" },
  { "type": "text", "text": "[Pinned: src/schema.ts]\n```\n...800 lines...\n```" }
]

The date changes at midnight. When it does, the entire cache for everything after the system prompt is invalidated — including those 800 lines of pinned schema that haven't changed in weeks. On a project with several pinned files, that's thousands of tokens re-processed at full price every morning for no reason.

The fix is embarrassingly simple: put the stable content first.

[
  { "type": "text", "text": "[Pinned: src/schema.ts]\n```\n...800 lines...\n```" },
  { "type": "text", "text": "Current date: 2026-05-23" }
]

Now the pinned files form a stable prefix. Even when the date changes, the cache still covers system prompt + tools + pinned files.

We also added a fourth cache breakpoint. Anthropic allows up to four, and we were only using three (system prompt, last tool, last user message). The new breakpoint sits on the first user message — the one containing pinned files — so the stable context prefix gets its own explicit cache boundary.

The result: fewer cache misses, lower costs, no behaviour change. You won't notice anything different except a slightly smaller bill.

Teaching the agent to read code, not guess at it

When Elyra's agent needs to find where a function is defined, it runs grep. When it needs to understand who calls a method, it runs grep again. Grep is fast and usually good enough. But "usually" isn't "always."

> Find all callers of validateUserInput
Agent runs:    grep -r "validateUserInput" src/
Agent reads:   14 results across 8 files
Agent reads:   4 of those files to understand context
Agent realises: 3 results were comments, 2 were imports, 1 was a type definition
Actual callers: 4
Tokens spent:  ~12,000

A TypeScript language server already knows the answer. It has the full type graph in memory. "Find references" is a single RPC call that returns exactly the four call sites, with zero false positives.

@elyracode/lsp-typescript bridges that gap. Install it, and the agent gets four new tools:

elyra install @elyracode/lsp-typescript

Tool What it does lsp_definitions Go to definition — resolve where a symbol is declared lsp_references Find all references — every usage across the project lsp_diagnostics Get compiler errors for a file without running the build lsp_hover Get the resolved type signature and JSDoc for a symbol

The extension starts typescript-language-server in the background when your session begins (if it finds a tsconfig.json), and shuts it down when the session ends. The agent uses these tools instead of grep when it needs semantic precision.

Here's what the same "find callers" task looks like with LSP:

> Find all callers of validateUserInput

Agent runs:     lsp_references(file: "src/validation.ts", line: 42, column: 17)
Agent receives: 4 locations with file paths and line numbers
Tokens spent:   ~800

Same answer. 15× fewer tokens. No false positives from comments, imports, or type annotations.

When it helps most

The token savings are largest on tasks that involve understanding how code connects:

• Refactoring — rename a function and update all call sites. With lsp_references, the agent finds every usage on the first try instead of iterating through grep results.

• Bug investigation — trace a value through the codebase. lsp_definitions jumps straight to the source instead of scanning for string matches.

• Type errors — lsp_diagnostics gives the same errors as tsc --noEmit but for a single file, without running the full type checker. The agent can check its work after each edit.

• Understanding unfamiliar code — lsp_hover shows the resolved type of any expression. No need to read the entire file to understand what a variable holds.

Prerequisites

Your project needs two things:

1. A tsconfig.json (the extension skips activation without one).

2. typescript-language-server installed — either locally or globally:

npm i -D typescript-language-server

The extension finds the binary automatically. If it's not installed, it logs a message and the agent continues working with its standard tools. No breakage, no popups.

It's an extension, not core

We deliberately built this as a separate package rather than baking it into Elyra's core. Language servers are heavy — tsserver uses 100–500 MB of RAM and takes a few seconds to start. If you're working on a Python project or writing shell scripts, you shouldn't pay that cost.

The extension pattern also means the community can build lsp-python, lsp-go, or lsp-rust without waiting for us. The only thing these extensions need from core is registerTool() and the session lifecycle events, both of which are already stable.

Get it

elyra update
elyra install @elyracode/lsp-typescript

The cache optimisation applies automatically — no action needed.

Elyra v0.7.7 — changelog