# ElizaOS Developer Update (2026-02-02 → 2026-02-08)

This update covers core framework work landing in `elizaos/eliza`, active V2 work-in-progress branches, and key integration pain points surfaced in Discord (notably Milaidy + plugin compatibility, character config, and Postgres performance).

---

## 1) Core Framework

### Per-request / per-entity settings via `RequestContext` (multi-tenant foundation)
Eliza runtime settings resolution now supports a request-scoped override layer using `AsyncLocalStorage`, enabling **per-user API keys / OAuth tokens** in shared runtimes without threading IDs through every call site.

- PR: **feat(core): add request context for per-user entity settings**  
  https://github.com/elizaos/eliza/pull/6457

**Key behavior change**
- `runtime.getSetting(key)` now checks `RequestContext` first (if present), then falls back to agent/global settings. This is critical for cloud + shared agents (Discord/Telegram multi-user rooms) where you must not leak credentials across users.

**Minimal usage pattern (Node)**
```ts
import { RequestContext } from "@elizaos/core";

// Example: isolate a user's provider keys for the duration of a request/turn
await RequestContext.withEntity(
  {
    entityId: userId,
    settings: {
      OPENAI_API_KEY: process.env.USER_OPENAI_KEY,
      ANTHROPIC_API_KEY: process.env.USER_ANTHROPIC_KEY,
    },
  },
  async () => {
    const key = runtime.getSetting("OPENAI_API_KEY"); // resolves from RequestContext
    const reply = await runtime.processMessage(message);
    return reply;
  }
);
```

---

### Prompt bloat reduction: `ActionFilterService` (vector search + BM25 rerank)
The TypeScript runtime now has an action/provider filtering path intended to reduce “200+ actions in prompt” down to a small relevant subset, improving latency, cost, and tool selection reliability.

- PR: **feat: ActionFilterService — vector search + BM25 reranking for action/provider filtering**  
  https://github.com/elizaos/eliza/pull/6475

**How it works (high level)**
1. Embed/query against action descriptions (cosine similarity)
2. Rerank shortlist via BM25
3. Feed only top-N to the LLM/tool planner

If you maintain large plugin bundles, this is the first major runtime-side mitigation for context explosion.

---

### `plugin-bootstrap` robustness + performance work
A large batch of improvements landed in the bootstrap plugin layer (caching/robustness and additional provider/evaluator work).

- PR: **feat(plugin-bootstrap): comprehensive optimization and robustness improvements**  
  https://github.com/elizaos/eliza/pull/6476

This is especially relevant given Discord reports of runtime instability when providers receive null-ish data and when plugins are hot-loaded across different environments (local vs VPS vs cloud).

---

### Infra/perf hot spot (Discord): Postgres `logs` table contention
Core-devs identified a production bottleneck: the Postgres `logs` table is being hit excessively, slowing overall response times. A “major optimization plan” was confirmed as in progress.

- Discord context (core-devs): excessive `logs` hits → Postgres slowdown → slower agent responses  
  https://discord.com/channels/1253563208833433701/1377726087789940836
- Related tracking (perf): **[Infra] Fix cold start latency / perf** (referenced in weekly planning)  
  https://github.com/elizaos/eliza/issues/6450

No merged PR this week specifically addresses the logs-table pressure yet; expect upcoming changes around batching, sampling, indexes/partitioning, or async log sinks.

---

### Architectural proposal (Discord): PM2-managed websocket processes
A community proposal suggests running websocket management under PM2 with a symlink-based repo/workdir layout for cleaner GitOps-style deployments.

- Discord context (coders): PM2 + directory structure proposal  
  https://discord.com/channels/1253563208833433701/1300025221834739744

This is not merged/standardized yet, but if you’re operating at scale, it’s a signal the community is converging on “process manager + structured runtime dirs” for deployments.

---

## 2) New Features

### JWT authentication + user management (data isolation mode)
JWT auth and user management shipped behind a feature flag designed for multi-tenant deployments.

- PR (merged): **feat(auth): implement JWT authentication and user management**  
  https://github.com/elizaos/eliza/pull/6200

**Notes**
- Activation requires `ENABLE_DATA_ISOLATION=true` (per PR notes).
- This pairs naturally with `RequestContext` for per-user settings and credential isolation.

---

### Developer documentation: core guides + API reference
Core docs were added/expanded, covering architecture, concepts, plugin dev, deployment, and API reference.

- PR: **docs: core documentation guides**  
  https://github.com/elizaos/eliza/pull/6356  
- Key doc entry points:  
  - Architecture: https://github.com/elizaos/eliza/blob/main/docs/ARCHITECTURE.md  
  - Plugin development: https://github.com/elizaos/eliza/blob/main/docs/PLUGIN_DEVELOPMENT.md  
  - Deployment: https://github.com/elizaos/eliza/blob/main/docs/DEPLOYMENT_GUIDE.md  
  - API reference: https://github.com/elizaos/eliza/blob/main/docs/API_REFERENCE.md  

---

### V2 / “next generation” multi-language runtime (WIP, not merged)
Two large PRs are open that represent a substantial shift: **Rust + Python + TypeScript** core packages, plugin ports, removal of “default app/server/CLI” assumptions, and runtime behavior changes (planningMode, action args, etc.).

- PR (open): **next** https://github.com/elizaos/eliza/pull/6474  
- PR (open): **feat: next generation multi-language Eliza** https://github.com/elizaos/eliza/pull/6485  
- Earlier large branch (open): **V2.0.0** https://github.com/elizaos/eliza/pull/6351  

Treat these as *preview branches* unless you are actively testing V2 internals.

---

### Milaidy: Mac-native Eliza-based “openclaw” variant (ecosystem)
Discord focus this week remained on **Milaidy**, a Mac `.app` with plugin-based connectors (openclaw connectors as Eliza plugins) and agent “skills” support.

- Repo: https://github.com/milady-ai/milaidy  
- Discord context (launch + testing):  
  https://discord.com/channels/1253563208833433701/1300025221834739744

---

## 3) Bug Fixes (Critical / High-impact)

### MESSAGE_SENT event now emitted for central bus submissions
A longstanding issue where `EventType.MESSAGE_SENT` was not emitted when submitting to `/api/messaging/submit` has been fixed.

- Issue (closed): **EVENT MESSAGE SENT not working**  
  https://github.com/elizaos/eliza/issues/5216
- PR (merged): **fix(server): emit MESSAGE_SENT event after sending to central server**  
  https://github.com/elizaos/eliza/pull/6378

**Why it mattered**
Plugins depending on message lifecycle events (telemetry, downstream dispatch, auditing) silently failed to trigger, making integrations appear “randomly broken”.

---

### CLI remote auth fixes: `.env` loading for `elizaos agent *`
When servers are secured with `ELIZA_SERVER_AUTH_TOKEN`, `elizaos agent` commands against remote servers could fail due to missing auth config loading.

- Issue (closed): https://github.com/elizaos/eliza/issues/5707  
- PR (merged): **fix(cli): load .env files in agent commands for authentication**  
  https://github.com/elizaos/eliza/pull/6376

**Practical impact**
You can now rely on `.env` for agent admin workflows (list/start/stop) consistently across local and remote targets.

---

### Null-safety hardening in core settings + bootstrap providers
Discord and GitHub both reflect instability rooted in unexpected null/undefined values. Several defensive fixes landed:

- PR (merged): **fix: add null checks to Object.entries calls in settings utilities**  
  https://github.com/elizaos/eliza/pull/6471
- PR (merged): **fix(plugin-bootstrap): add null check for runtime.providers**  
  https://github.com/elizaos/eliza/pull/6473

These prevent runtime crashes from propagating into “agent ignored my message” symptoms that are often misdiagnosed as model issues.

---

### CLI reliability: template dependency resolution + safer directory handling
- PR (merged): **fix(cli): always use 'latest' for @elizaos deps in created projects**  
  https://github.com/elizaos/eliza/pull/6362
- PR (merged): **fix(cli): validate directory path in ensureDir to prevent ENOENT error**  
  https://github.com/elizaos/eliza/pull/6379

If you develop locally with linked monorepo packages, this reduces create/update failures caused by alpha-tag versions not present on npm.

---

## 4) API Changes (Developer-facing)

### `runtime.getSetting()` precedence now includes RequestContext
If you have custom providers or plugins that call `runtime.getSetting()`, be aware:
- In request-scoped contexts, settings may now resolve to **entity-specific** values.
- This is usually desirable (multi-user key isolation), but it can surprise code that assumed settings were static during runtime lifetime.

- PR: https://github.com/elizaos/eliza/pull/6457

**Recommendation**
- For “global-only” configuration, use a separate config channel (e.g., plugin init config) rather than relying on `getSetting()` returning a stable value across requests.

---

### Server auth / env var documentation consolidated
Environment variables (including server auth) are now documented centrally:

- PR: **docs: add environment variables documentation**  
  https://github.com/elizaos/eliza/pull/6377
- Doc: https://github.com/elizaos/eliza/blob/main/docs/environment-variables.md

This doc clarifies use of `ELIZA_SERVER_AUTH_TOKEN` and related operational toggles.

---

## 5) Social Media Integrations (Twitter / Telegram / Discord / Farcaster)

### Twitter (X): quote repost is not native
Discord reports confirm the current Twitter integration can post, but “quote repost” behavior is incorrect: it posts quoted text + link rather than a native quote tweet object.

- Discord thread (coders):  
  https://discord.com/channels/1253563208833433701/1300025221834739744

**Action for developers**
- Please file an issue (or PR) against the Twitter plugin repo once identified (not linked in the current dataset). Include:
  - Endpoint used (`POST statuses/update` vs v2 create tweet w/ quote_tweet_id)
  - Whether media/URL entities are being passed correctly
  - Required OAuth scopes for quote tweets

### Discord/Telegram
This week’s Discord discussions did not add new merged PRs specifically for Discord/Telegram plugins, but ongoing infra work remains relevant:
- Discord-as-service and cloud integration were tracked recently in `elizaos/eliza` issues (e.g., Discord plugin/cloud/AWS service references).  
  Example issue reference from last week summary: https://github.com/elizaos/eliza/issues/6398

### Farcaster
No Farcaster-specific changes were surfaced in GitHub/Discord this week.

---

## 6) Model Provider Updates (OpenAI / Anthropic / etc.)

### Provider plugin compatibility regression: `MAX_EMBEDDING_TOKENS` missing
Milaidy integration surfaced a breaking compatibility issue: newer plugin versions are missing the `MAX_EMBEDDING_TOKENS` constant (expected by some runtime/plugin codepaths), causing plugin loading failures.

- Discord (coders): `MAX_EMBEDDING_TOKENS` missing; suggested rollback vs PRs across plugin repos  
  https://discord.com/channels/1253563208833433701/1300025221834739744

**Short-term workaround**
- Pin provider plugins to versions known to export the constant (rollback), *or*
- Patch provider plugins to re-export `MAX_EMBEDDING_TOKENS` consistently across repos.

**Suggested compatibility shim (plugin-side)**
```ts
// provider-plugin/src/constants.ts
export const MAX_EMBEDDING_TOKENS =
  Number(process.env.MAX_EMBEDDING_TOKENS) || 8192;
```

**Recommended follow-up**
- Standardize provider capability metadata (e.g., `embedding.maxTokens`) instead of relying on ad-hoc exported constants.

---

### Model selection mismatch reported (Anthropic Haiku selected unexpectedly)
Users reported the agent selecting `claude-haiku-3.5` despite different configuration, alongside character-loading defaults.

- Discord (coders): model selection + character issues  
  https://discord.com/channels/1253563208833433701/1300025221834739744

No root cause/fix PR is linked yet; likely suspects include:
- settings precedence changes (RequestContext vs agent settings)
- config file load order / environment override precedence
- plugin/provider default fallback logic

---

## 7) Breaking Changes / V1 → V2 Migration Warnings

### V2 branches remove “non-essentials” and restructure runtime assumptions (WIP)
The open V2 PRs represent a **major surface-area change**:
- multi-language core (Rust/Python/TS)
- plugins ported per language
- removal of default app/client/server scaffolding
- runtime behavior changes (planning mode, action args, message memory creation path)

- PRs (open):  
  - https://github.com/elizaos/eliza/pull/6474  
  - https://github.com/elizaos/eliza/pull/6485  
  - https://github.com/elizaos/eliza/pull/6351  

**Migration risk areas**
1. **Project structure**: if your app depends on the monorepo server/client, V2 branches may not include them.
2. **Plugin API expectations**: action calling semantics (“actions can have arguments”) and filtering (ActionFilterService) can change how tools appear to the model.
3. **Settings resolution**: RequestContext-driven precedence can change behavior in multi-user deployments if you previously depended on static settings.
4. **Operational tooling**: CLI expectations may diverge as V2 focuses on runtime packages rather than the full “app stack”.

**Recommendation**
- Treat V2 as an opt-in experimental track for now. If you do evaluate it, isolate it in a separate branch and validate:
  - provider plugin compatibility (including the `MAX_EMBEDDING_TOKENS` regression)
  - your deployment process (PM2/systemd/docker) against new entrypoints
  - any assumptions about message memory creation and event emission

---