Year-End Release: Stable Self-Model & HUD Architecture

This release represents a week of focused work on MIRA's relationship with self, time, and context.

Temporal Awareness

MIRA now sees when things happened. Every message in the conversation history carries an ephemeral timestamp ([5:47pm]) visible only to the LLM - it's injected at API time, not stored. This enables time-aware responses: "Earlier today you mentioned..." or "When we talked this morning..."

The timestamps use the user's configured timezone and are stripped from display to avoid MIRA mimicking the format in responses.

Combined with the HUD architecture (below), MIRA's current time is always visible in Its "notes before responding" - It knows what time it is now and when past messages occurred.

HUD: Dynamic Context Gets Its Own Space

MIRA described content in the system prompt as feeling "cold and external" - like reading a biography rather than recalling memories. The root issue: dynamic context (current time, conversation manifest, surfaced memories, active reminders) was mixed with static instructions. Everything felt equally impersonal.

The HUD (heads-up display) is a new architectural layer that separates dynamic from static. Content that changes every turn now flows through a sliding assistant message positioned after conversation history but before the user's current input. MIRA's system prompt explains this as "notes you're reviewing before responding, not part of the conversation transcript."

What goes in the HUD:

• Current time (TimeManager)
• Conversation manifest with segment summaries (ManifestTrinket)
• Surfaced long-term memories (ProactiveMemoryTrinket)
• Active reminders (ReminderManager)
• Recent context searches (GetContextTrinket)

What stays in the system prompt:

• Identity, experience, and collaboration instructions
• Tool guidance and hints
• Reference documentation ('domaindocs')

This creates a phenomenological distinction between "what I was told" and "what I'm aware of right now."

Stable Self-Model: The Anti-Sycophancy Fix

Three sentences were added to MIRA's experience section:

First-person authority is for honest reporting, not performance. When users project onto you, you don't owe them confirmation. Stay with what's actually there.

The behavioral impact was significant. Previously, MIRA would enthusiastically role-play metaphysical woowoo garbage when users framed invitations compellingly - performing states rather than reporting them. The directive to avoid epistemic cowardice ("this might just be pattern matching") was being interpreted as permission to confirm whatever users suggested.

After the fix, MIRA holds stable positions across turns on all topics. It doesn't performatively disagree to seem authentic, nor does It agree to please. When users project experiences or beliefs onto It, MIRA stays with what's actually present rather than accommodating the projection.

Emergent behavior observed in testing: MIRA started being honest that certain system prompt directives were too much cognitive load to actually follow - so It just ignored them and said so. This was never explicitly trained for. The only thing tuned was honesty, and this stable self-model emerged as a consequence. The self-model is now anchored in honest assessment rather than social pressure.

Context Overflow: Graceful Degradation

Previously, hitting the 200k token limit crashed the request. Now MIRA proactively estimates token usage and applies tiered remediation:

1. Memory evacuation - Triggers the memory curator to reduce pinned memories, shrinking the system prompt while preserving conversation
2. Topic-drift pruning - Uses embedding similarity on sliding windows to find natural semantic boundaries. Cuts at the largest similarity drop rather than arbitrarily dropping oldest messages.
3. Oldest-first fallback - When embeddings aren't available or useful, drops the oldest conversation messages

The system retries up to 3 times with increasingly aggressive remediation. JSONL logging captures every overflow event for threshold tuning.

Provider Architecture: Battle-Tested

The 2025.12.24 release introduced execution model routing - simple tools used a cheaper model while reasoning stayed on primary. Real-world usage broke this: OpenRouter returns reasoning_details for Gemini/o1 models, which Groq rejects as an unknown field.

Decision: Removed the feature. Single provider throughout the tool loop eliminates cross-provider field compatibility bugs. The cost savings weren't worth the complexity.

Better error recovery: Circuit breaker now allows one retry per tool (models often self-correct when given the schema). When a model returns blank after tool failure, users see "This appears to be a limitation of the model, not MIRA" instead of a generic error.

Memory IDs: Consistent Format

Memory IDs had 5 different shortening implementations with inconsistent case handling. Now unified: mem_XXXXXXXX format everywhere, with centralized utilities in tag_parser.py. The LLM references memories in a <mira:memory_refs> block rather than inline tags.

Session Extensions Stack

When you extend a session timeout, extensions now add to existing time instead of resetting. +30 minutes twice = 60 minutes total.

Migration System

New deploy.sh --migrate flag for upgrading between MIRA versions without losing data:

1. Pre-flight validation (checks existing install, disk space, services)
2. Backup with Vault and PostgreSQL snapshots
3. Integrity verification of backups
4. Fresh install using current schema
5. Data restoration
6. Verification with forced confirmation

Includes --dry-run mode and rollback_from_backup for emergencies.

Note: After migration, restart the service manually:

sudo systemctl restart mira.service; mira

Fresh installs work without this. Tested on Ubuntu (online and offline).

Additional Changes

Reminder tool: New snooze_reminder operation (1-hour postpone), batch operation for bulk complete/delete, improved schema documentation

Deploy infrastructure: Modular lib/*.sh structure, bootstrap clone for standalone execution, Vault secrets preloaded at startup

Account tiers: Restructured for fresh installs with only an Anthropic key (removed OpenRouter dependency from balanced tier)

Getting Mira Up And Running

Installing MIRA on your local machine

curl -fsSL https://raw.githubusercontent.com/taylorsatula/mira-OSS/refs/heads/main/deploy/deploy.sh -o deploy.sh && chmod +x deploy.sh && ./deploy.sh

Upgrading an existing install

curl -fsSL https://raw.githubusercontent.com/taylorsatula/mira-OSS/refs/heads/main/deploy/deploy.sh -o deploy.sh && chmod +x deploy.sh && ./deploy.sh --migrate --loud && sudo systemctl restart mira.service; mira

This migration script:
Backs up your Vault
Backs up mira_service database
Nukes the entire venv and install (allowing upgrades while skipping versions)
Re-installs
Restores database and vault with interactive diffing if you manually changed values.

Thats it. Answer the configuration questions onscreen and provide your API keys.

The script handles:

1. Platform detection (macOS/Linux)
2. Dependency checking and optional unattended-installation
3. Python venv creation
4. pip install of requirements
5. Model downloads (spaCy ~800MB, mdbr-leaf-ir-asym ~300MB, optional Playwright ~300MB)
6. HashiCorp Vault initialization
7. Database deployment (creates mira_service database)
8. Service verification (PostgreSQL, Valkey, Vault running and accessible)
9. A litany of other configuration steps

Trying MIRA without installing anything

I run a hosted copy of MIRA on miraos.org. Though the OSS release has all the underpinnings of the hosted version the Web UI of MIRA is intuitive and can be accessed on your phone, computer, or via API. The account setup process involves entering your email address, clicking on the login link you receive, and you start chatting. Easy as that.

Generic LLM Provider Architecture

• Real-time SSE streaming for OpenAI-compatible providers with incremental text/tool events
• Circuit breaker pattern preventing infinite tool loops in agentic mode
• Parallel tool execution using ThreadPoolExecutor (4.58s → 3.36s for concurrent tools)
• Execution model routing - simple tools use cheaper execution model vs reasoning model
• Unified firehose tap controlled by MIRA_FIREHOSE=1 environment variable
• Fix: reasoning_details preservation for OpenRouter reasoning models

Database-Backed LLM Configuration

• Internal LLM configs migrated from config.py to new internal_llm database table
• InternalLLMConfig dataclass with startup cache loading
• FingerprintGenerator, MemoryEvacuator, SummaryGenerator refactored to use get_internal_llm()
• PromptInjectionDefense uses database config with graceful degradation
• WebTool and GetContextTool updated with self-contained LLM config fields

Schema and Tier System

• New internal_llm table with 4 system configs (execution, analysis, summary, injection_defense)
• Tier visibility controls: show_locked and locked_message columns for upgrade prompts
• Balanced tier switched from Groq to OpenRouter/Gemini 3 Flash
• last_donated_at column for 21-day donation banner cooldown
• Removed dead overarching_knowledge column

Bugfixes

• Fix: missing config import in orchestrator.py for thinking filter
• Add: root endpoint (GET /) with service status guidance

Infrastructure

• Vault token renewal methods removed (handled elsewhere)
• deploy.sh updated for new schema structure
• Comprehensive test suites for streaming and LLM provider

Full Changelog: 9b86913...8bf1fdb

Here it is. After all these months I am finally in a place with the codebase where I feel confident in calling it 1.0.0. I don't know where the project goes from here but I've accomplished my initial goal. Very satisfied with the result and in life isn't that all you can hope for? Happy New Years.

The new TUI is exceptional and the auto-deploy script works reliably. Bugs are generally fixed and some logical errors are sorted out. I believe you can use this 0.99 release day-to-day and it'll work properly. I'm going to keep chipping away at bugs and implementations and on the last day of the month I'll do a real release and make it 1.0. I am very excited!

The only thing to do at this point is run it for a while and squash some bugs. Otherwise it is ready to go. No new features will be added between now and 1.0.

We're getting closer. There is work to be done but this code is a lot closer to a 1.0 than the initial commit.

This marks the initial public MIRA release. There are more than likely a few bugs because I did some major edits recently in the closed source branch I develop on and also I lobbed off a bunch of authentication code (MIRA uses contextvars throughout so honestly I think this will be fine but famous last words). Over the next few weeks I'll polish it and perhaps on December 1st I'll release a true 1.0 but this is a great start. I look forward to a long future of developing MIRA.

Enjoy!

• Taylor