# ElizaOS Developer Update (2025-12-29 to 2026-01-04)

This update covers core runtime performance improvements, ongoing work on data isolation correctness, early-stage roadmap issues for “public agents”, and active plugin work (notably Twitter OAuth2 PKCE). It also summarizes key technical discussions from the developer Discord (multi-model agents, logging format linting, and infra concerns like turbo build memory).

---

## 1) Core Framework

### Parallelized provider execution in multi-step runtime (performance + fault tolerance)
The default message service’s multi-step execution path has been refactored to execute providers concurrently rather than sequentially.

- Merged PR: **“refactor(default-message-service): optimize provider handling in MultiStep”** (elizaos/eliza **#6263**)  
  https://github.com/elizaos/eliza/pull/6263

**What changed**
- `runMultiStepCore` moved from sequential provider iteration to `Promise.allSettled(...)`.
- This reduces wall-clock latency for multi-step actions where providers are IO-bound (web fetchers, DB lookups, tool calls, etc.).
- Failures are isolated per-provider (allSettled), improving resilience when one provider is flaky.

**Developer implications**
- Provider completion order is no longer inherently deterministic (because concurrency).
- If you were implicitly relying on provider side-effects occurring in a strict order, you should make ordering explicit (e.g., split steps, or wrap dependent providers into one provider).

---

## 2) New Features

### (Roadmap) Public agent UX + discovery primitives (issues opened)
A significant set of product/UX roadmap issues were created to support a “public agent ecosystem” (discover, fork, and chat via shareable URLs). These are not merged features yet, but they define the near-term API/UI direction.

Key issues:
- Public agent discovery platform: https://github.com/elizaos/eliza/issues/6302  
- Knowledge sharing between agents: https://github.com/elizaos/eliza/issues/6303  
- Standardized public agent URLs: https://github.com/elizaos/eliza/issues/6304  
- Forking public agents: https://github.com/elizaos/eliza/issues/6305  
- Public agent UI states (unauth visitor vs auth non-owner vs owner): https://github.com/elizaos/eliza/issues/6313  
- Limit unauth public-agent messages (~2–3): https://github.com/elizaos/eliza/issues/6312  
- Public agent cards show chat count: https://github.com/elizaos/eliza/issues/6314  

These issues are useful context if you’re building plugins or external services that assume:
- agents can be shared by URL,
- public chat sessions may be rate/credit-limited for anonymous users,
- “fork” becomes a first-class action.

### Multi-model agents via provider selection (Discord guidance)
Developers discussed running **multiple LLMs in one agent** (e.g., Anthropic for certain tasks, OpenAI for others). The recommended pattern in Discord was to use the OpenRouter plugin and select the provider/model via environment configuration, then select providers in code paths as needed.

Related discussion highlight (Discord, 2026-01-03): multi-model agent setup and provider selection.

Example (conceptual) usage pattern:
```ts
// Pseudocode illustrating selecting a specific provider/model per task.
// Exact APIs vary by runtime/package version.

const reasoning = await useModel({
  provider: "openrouter",
  model: "openai/gpt-4.1-mini",
}).complete({ prompt: "Draft a plan." });

const math = await useModel({
  provider: "openrouter",
  model: "anthropic/claude-3.5-sonnet",
}).complete({ prompt: "Compute expected value for ..." });
```

If you’re shipping an agent that depends on this, document your `.env` expectations and fallbacks clearly.

---

## 3) Bug Fixes

### Multi-step runtime: reduced latency without dropping provider failures
While primarily a performance refactor, **#6263** also changes failure handling semantics:
- Previously, a failing provider could block subsequent providers in a sequential pipeline depending on implementation.
- With `Promise.allSettled`, all providers run; failures are captured and can be surfaced/handled without aborting the whole provider batch.

PR: https://github.com/elizaos/eliza/pull/6263

### Critical SQL isolation bug: `SET LOCAL` cannot be parameterized (fix in progress)
A critical bug was identified in the SQL plugin path when **data isolation** is enabled.

- Open PR: **“fix(plugin-sql): use sql.raw() for SET LOCAL to avoid parameterization…”** (elizaos/eliza **#6316**)  
  https://github.com/elizaos/eliza/pull/6316

**Root cause**
- PostgreSQL `SET` / `SET LOCAL` does **not** accept parameter placeholders (`$1`), but Drizzle’s `sql\`\`` template parameterizes interpolations by default.
- This produced runtime errors like: `syntax error at or near $1` when `ENABLE_DATA_ISOLATION=true`, effectively breaking DB operations under isolation.

**Fix approach**
- Inline the `entityId` into a raw SQL string for `SET LOCAL`, and add both unit + integration tests (including a real PostgreSQL integration test).

Snippet (from PR description; conceptually):
```ts
// Before (auto-parameterized, breaks SET LOCAL)
sql`SET LOCAL app.entity_id = ${entityId}`

// After (inline, using raw)
sql.raw(`SET LOCAL app.entity_id = '${entityId}'`)
```

**Security note**
If `entityId` can be influenced externally, ensure it is strictly validated/escaped before inlining. The PR adds tests, but downstream callers should still treat context identifiers as trusted-only.

---

## 4) API Changes

### MultiStep provider execution ordering is no longer sequential
Although no public API signatures changed in the merged work, **behavioral semantics** changed:

- Providers invoked by multi-step execution may now resolve out-of-order.
- Any plugin/provider that relied on “provider A always runs before provider B” should be updated to:
  - encode dependencies as explicit steps, or
  - aggregate dependent work into a single provider.

Reference: https://github.com/elizaos/eliza/pull/6263

### Logging format enforcement (tooling/lint)
From Discord: PR **#6263** was also referenced as introducing **logging system improvements** including a linter in `eliza/config` that warns when logs are in the wrong format (per developer discussion on 2026-01-03). If you maintain plugins, keep logs consistent with the expected schema to avoid warnings during CI/dev.

(If you’re seeing warnings, search the `eliza/config` package lint rules in the repo and align your logger calls accordingly.)

---

## 5) Social Media Integrations

### Twitter plugin: OAuth2 PKCE + provider abstraction (in progress)
Work is ongoing to move the Twitter integration to a more secure auth flow.

- PR: elizaos-plugins/plugin-twitter **#46**  
  https://github.com/elizaos-plugins/plugin-twitter/pull/46

**What to expect**
- OAuth2 PKCE reduces risk vs long-lived secrets and improves the developer/operator experience for deployed agents.
- A “provider abstraction” is being introduced, likely impacting configuration and how credentials are injected.

**Action for plugin users**
- Do not hardcode assumptions about OAuth1.1-style secrets remaining stable.
- Prepare for updated environment variables and callback/redirect requirements once merged.

### Discord plugin: version publishing inconsistency (reported)
Discord discussion flagged a publishing/versioning problem:
- Discord plugin failed to publish v1.3.4 and jumped from v1.3.3 → v1.3.5.
- Track and verify plugin registry versions before pinning in production builds.

(Discord discussion: 2026-01-03; no PR link provided in the aggregated data.)

---

## 6) Model Provider Updates

### OpenAI plugin: media handling fixes + caching (in progress)
Work started on improving image description correctness and adding caching for audio/image handlers.

- PR: elizaos-plugins/plugin-openai **#23**  
  https://github.com/elizaos-plugins/plugin-openai/pull/23

**Expected impact**
- More reliable image description behavior for multimodal flows.
- Reduced repeated compute/latency via caching (especially relevant for agents that reprocess the same media across turns).

### Provider selection in custom code (`useModel` “provider” option)
From Discord (2026-01-04): developers noted that `useModel` can be used with a `provider` option when running custom code. If you’re building advanced routing (e.g., different models per task), ensure your agent’s configuration and secrets management supports multiple providers simultaneously.

---

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

No explicit V1→V2 breaking change was merged this week in the provided data. However, there are **two upcoming areas that can behave like breaking changes** depending on how tightly you coupled to prior behavior:

1) **MultiStep provider ordering (merged)**
- If a V1-era agent/plugin implicitly depended on sequential provider side-effects, **#6263** can change outcomes.  
  Reference: https://github.com/elizaos/eliza/pull/6263

2) **Twitter auth flow (pending, but high-impact)**
- Once OAuth2 PKCE lands, existing deployments may require new configuration (redirect URLs, PKCE flow support) and may not be “drop-in” compatible.  
  Reference: https://github.com/elizaos-plugins/plugin-twitter/pull/46

---

### Additional Notes from Developer Discord (Engineering Context)

- **Turbo build memory usage**: reports of extremely high memory consumption during builds (21GB+). If you’re hitting this locally/CI, consider isolating which package graph triggers it and pinning toolchain versions until investigated (no linked issue/PR in provided data).
- **Low-latency Solana trading**: discussion emphasized that profitable Solana trading requires millisecond-grade ingestion (gRPC ingesters, payload preshot systems). Standard agent reaction loops and common SDK paths (~4s delay) are too slow for that category of use case. This is relevant if you’re planning a trading plugin: you’ll likely need a specialized ingestion + execution subsystem rather than a normal conversational loop.
- **Polymarket “Phase 2”**: updates mentioned with potential upcoming changes to the polymarket plugin (no PR link in provided data).
- **Knowledge data pipelines**: ongoing work on Eliza knowledge pipelines, with documentation/presentation planned soon (no PR link in provided data).

---