Here's a walk through them.
Most of v0.5.5 is the kind of work nobody notices until it's gone. The agent just feels snappier in long sessions, and that's because four different bottlenecks got addressed.
When the agent calls several tools in one response — say, three read_files and a run_command — the old behavior was to serialize the whole batch the moment anything needed to run sequentially. Now the batch gets split: parallel tools run concurrently, sequential tools act as barriers. The reads finish together, then the command runs. Multi-tool turns just complete faster.
Event listeners used to take turns blocking the LLM stream. UI rendering, disk persistence, memory management — one at a time, while the next token waited politely. They're now dispatched concurrently, so nothing has to queue.
Token estimates for the compaction system are cached per message in a WeakMap. Since messages are immutable after creation, the cache hit rate climbs nicely in long sessions, and repeated compaction checks skip the work entirely for messages they've already seen.
And then there's a small but mighty fast path: the extension runner used to structuredClone the entire conversation history before handing it to context handlers — even when no extension had registered a handler. For sessions without extensions, which is most sessions, that clone is now skipped. The biggest single cost in the transform pipeline, just deleted.
None of this is glamorous. All of it adds up.
Elyra used to ship with dark and light. Now there are five.
Palenight is based on whizkydee's classic VS Code theme. Purple accent, teal operators, muted blue-gray backgrounds. Soft and warm — if you like your terminal to feel like a cozy evening, this one's for you.
Catppuccin uses the Mocha flavor. If you've already Catppuccinified your editor, your tmux, your shell, and probably your toaster, the set is now complete.
One Dark is the familiar Atom palette via Binaryify's One Dark Pro. Blue accent, neutral, the comfort food of dark themes.
Switching is straightforward:
/theme palenight
/theme catppuccin
/theme onedark
Or just type /theme to get a live-preview selector — the theme changes as you arrow through the list and reverts if you cancel, which is the right way to do this and I'm glad they did. Your choice persists across sessions.
Custom themes work too. Drop a JSON file in ~/.elyra/themes/ following the schema from any built-in theme, and it shows up in the selector immediately.
You always had this data — every provider response carries usage info. You just had no convenient way to see it. Now you do:
Session Cost
Input: 42,380 tokens
Output: 8,912 tokens
Cache read: 38,100 tokens
Cache write: 4,280 tokens
Total: 93,672 tokens
Estimated cost: $0.1847
Context: 67,200 / 200,000 (34%)
That's /cost. Input, output, cache hits, estimated dollars, and how full your context window is. No external tracking, no config. Just visibility.
I find this one quietly useful. Knowing you're at 34% context utilization tells you whether to keep going or wrap up the current thread before compaction kicks in.
After the agent has been editing for a while, you often want the bird's-eye view before committing. /diff runs git diff in the session directory and renders the output with syntax highlighting.
That's it. No interactive accept/reject per hunk, no staging mode. Just git diff, pretty-printed. Sometimes the right feature is the smallest possible feature.
This one solves a problem I've actually run into. Long sessions trigger compaction, which summarizes older messages to free up space — and sometimes it summarizes away the file you really needed the agent to keep referencing.
Pinning sidesteps the whole mess:
/pin src/core/auth.ts
/pin .env.example
Pinned files don't live in the conversation history. They get re-read from disk and injected fresh at the start of every LLM call. Compaction can't touch them, because they're not messages — they're context. And because they're re-read each turn, the agent always sees the current contents, even if you've edited the file since pinning.
Check what's pinned with /pins, remove with /unpin <path>. Pins are project-scoped and survive across sessions via .elyra/settings.json.
A few uses that have stuck for me:
Pin your schema file so the agent always knows the data model
Pin .env.example so it knows what config exists
Pin a style guide you want followed
Pin the file you're actively working on so compaction never drops it
Blueprints are session templates. If you keep starting sessions with the same instructions — "follow these patterns, pin these files, here's what I'm building" — you can save that as a blueprint and apply it with one command.
A blueprint is just a markdown file in .elyra/blueprints/ (project-local) or ~/.elyra/agent/blueprints/ (global):
---
pin: src/routes/api.ts, src/middleware/auth.ts
---
Build a new API endpoint following the patterns in the pinned files.
Use the existing auth middleware. Return JSON responses with proper
error handling. Add request validation. Write a test.
Apply it with /blueprint api-endpoint. The listed files get pinned, the body becomes the first message. Type /blueprint alone to see what's available.
The format is whatever you'd normally type as your first message, plus an optional pin: frontmatter line. That's the whole spec.
A few ideas worth stealing:
api-endpoint — pins routes and middleware, instructions for REST conventions
component — pins your component library and design tokens, instructions for new UI work
migration — pins schema and model directory, instructions for database changes
bugfix — pins your tests directory, instructions to reproduce first, then fix, then verify
Four releases, a long list of small things. None of them rewrite how Elyra works; together they make it noticeably nicer to live in. Which, honestly, is what most release notes should sound like.