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

This update covers core runtime changes merged into `elizaos/eliza`, critical bug fixes in the SQL plugin, and notable developer discussions from Discord around multi-model agents, deployments, and logging standards.

---

## 1) Core Framework (Architecture / Plugin System / Agent Runtime)

### MultiStep provider execution is now parallelized (performance + fault tolerance)
PR **#6263** refactors the default message service’s MultiStep path to execute providers concurrently using `Promise.allSettled`, instead of sequential execution. This reduces end-to-end latency when multiple providers must fetch or compute in the same step (e.g., embeddings + retrieval + tool context providers).  
- PR: https://github.com/elizaOS/eliza/pull/6263  
- Key file: `packages/core/src/services/default-message-service.ts` (see PR description for line range)

**Behavioral implications**
- Providers no longer have an implicit “run after the previous provider finished” ordering.
- Partial provider failures are handled more gracefully (settled results), enabling MultiStep to proceed while retaining error context.

**Developer guidance**
- If you maintain a custom provider with side effects or ordering dependencies, make it **idempotent** and avoid reliance on shared mutable state across providers.
- If ordering is required, consider consolidating dependent work into a single provider or explicitly sequencing inside that provider.

---

## 2) New Features (Capabilities + Examples)

### Standardized logging workflow + log-format linting (config package)
From core-dev Discord discussion, a log formatting linter was added under the `eliza/config` package to warn when logs don’t match the expected structured format (and to encourage consistency across core + plugins). This pairs with broader logging improvements discussed alongside PR **#6263**.

- Discussion context: Discord `#core-devs` (Jan 3, 2026)  
- Related PR (runtime refactor): https://github.com/elizaOS/eliza/pull/6263

**What to do in plugins**
- Adopt structured log fields (component, operation, ids) consistently.
- Integrate the linter into your plugin CI so formatting drift is caught early.

> Documentation note: if you maintain internal plugin templates, update them to match the current log conventions and run the linter in CI.

### Multi-model agents via OpenRouter routing (recommended pattern)
In Discord `#coders`, core contributors recommended using the **OpenRouter plugin** to mix providers/models within a single agent (e.g., Anthropic for math/forecasting; OpenAI for general reasoning) by selecting models via environment configuration.

**Example: env-based multi-model configuration**
```bash
# Example only — exact keys depend on your provider plugins
OPENROUTER_API_KEY="..."
ELIZA_PROVIDER="openrouter"

# Choose a default model used by the agent runtime
OPENROUTER_MODEL_DEFAULT="openai/gpt-4.1"

# Optionally define a secondary model (e.g., for calculation-heavy calls)
OPENROUTER_MODEL_FASTMATH="anthropic/claude-3.5-sonnet"
```

**Example: selecting models per task (pattern)**
If your agent/tooling layer supports “model hints” (or you maintain a custom tool), route by intent:
```ts
// Pseudocode pattern: pick model by task type
const model =
  task.kind === "forecast" || task.kind === "calculation"
    ? process.env.OPENROUTER_MODEL_FASTMATH
    : process.env.OPENROUTER_MODEL_DEFAULT;

const response = await runtime.generateText({
  prompt: task.prompt,
  model,
});
```

> If you don’t yet have a task router, implement a simple dispatcher at the tool boundary (e.g., math tool → “fastmath” model, narrative tool → default model).

---

## 3) Bug Fixes (Critical Fixes + Technical Context)

### Fix: PostgreSQL `SET LOCAL` must not be parameterized (SQL plugin + data isolation)
PR **#6316** fixes a critical issue when **data isolation** is enabled: PostgreSQL `SET` / `SET LOCAL` commands cannot use parameter placeholders (e.g., `$1`). The previous implementation used Drizzle’s `sql` tagged templates which auto-parameterize interpolated values, leading to runtime failures like:

- `syntax error at or near $1`

**Fix summary**
- Replaces parameterized `sql\`SET LOCAL ... ${value}\`` with `sql.raw()` and an inline literal for `SET LOCAL`.
- Adds both unit and integration coverage to prevent regressions.
- PR: https://github.com/elizaOS/eliza/pull/6316

**Why this matters**
If you run with `ENABLE_DATA_ISOLATION=true`, this bug could break *all* DB operations inside the entity context (depending on how/where the transaction-local setting is applied).

**Before (problematic pattern)**
```ts
// Parameterized interpolation breaks in PostgreSQL SET LOCAL
await tx.execute(sql`SET LOCAL app.entity_id = ${entityId}`);
```

**After (working pattern)**
```ts
// Use raw SQL for SET LOCAL
await tx.execute(sql.raw(`SET LOCAL app.entity_id = '${entityId}'`));
```

**Security note**
Because `sql.raw()` bypasses parameterization, ensure `entityId` is a trusted identifier (e.g., validated UUID) before inlining. If you accept user input, validate and/or escape appropriately.

---

## 4) API Changes (Developer-facing or Integration-impacting)

### MultiStep provider execution order is no longer sequential
While PR **#6263** is framed as internal, it can affect downstream behavior if your providers were relying on order-of-execution side effects.

- PR: https://github.com/elizaOS/eliza/pull/6263

**Action required for plugin authors**
- Audit providers that:
  - mutate shared objects
  - depend on “provider A sets X before provider B reads X”
- Prefer returning explicit outputs rather than mutating global/shared state.

### CLI / env template touchpoints
PR **#6263** also touches `.env.example` and related test timeouts. If you vendor or pin `.env.example` patterns in your deployment templates, re-sync with upstream to avoid drift.

---

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

### Discord plugin versioning issue (community-reported)
Developers reported a Discord plugin publishing/version mismatch (v1.3.3 → v1.3.5, with v1.3.4 failing to publish). This is not yet resolved in the provided GitHub activity, but it is flagged for investigation.

- Discussion: Discord `#coders` (Jan 3, 2026)
- Action item: investigate release pipeline + registry publishing consistency

### Twitter: poll creation requested (not yet implemented)
A feature request came in to allow agents to create Twitter polls. No PR is linked this week; track as an upcoming enhancement in the Twitter plugin workstream.

---

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

### OpenRouter highlighted as the recommended multi-provider abstraction
Discord guidance this week explicitly recommended OpenRouter for configuring multi-model usage through env configuration, enabling model selection per task without hard-binding agents to a single provider.

- Developer discussion: Discord `#coders` (Jan 3, 2026)

> If you’re building “calc/forecast” vs “reasoning” model splits, start with OpenRouter routing; avoid embedding provider-specific assumptions in your agent logic.

---

## 7) Breaking Changes (V1 → V2 migration warnings)

No explicit “hard break” PR landed this week, but there are **two migration-sensitive areas** flagged by community discussion:

### A) Provider concurrency assumptions (MultiStep)
If you upgraded and see different tool/provider context composition, check for hidden ordering dependencies in your providers (see sections 1 and 4). This is the most likely source of “it used to work, now it’s inconsistent” reports after pulling current `main`.

### B) Agent “knowledge/lore” / bio recall expectations
A developer reported that agents are not recalling information “from bio,” and asked whether “knowledge & lore” sections can be added back to JSON configuration (legacy behavior). No linked PR/issue is included in this dataset, but it’s a recurring migration friction point worth calling out.

**Mitigation**
- Ensure your character/agent config is aligned with the current schema and ingestion pipeline.
- If you depend on large static lore blocks, verify they are being loaded into the correct memory/knowledge subsystem for your runtime version.

---

## Relevant Issues (Opened)

Two new UI/UX issues were opened in `elizaos/eliza`:
- **#6317** “Connect wallet should ideally go straight to wallet options”  
  https://github.com/elizaOS/eliza/issues/6317
- **#6318** “Scroll should work on whole page”  
  https://github.com/elizaOS/eliza/issues/6318

---

## Links & References
- Core repo: https://github.com/elizaOS/eliza
- PR **#6263** (MultiStep provider parallelization): https://github.com/elizaOS/eliza/pull/6263
- PR **#6316** (SQL plugin `SET LOCAL` fix): https://github.com/elizaOS/eliza/pull/6316
- Roadmap: https://github.com/elizaOS/roadmap
- Discord discussions referenced:
  - `#coders` (multi-model agents, deployment, plugin versioning)
  - `#core-devs` (logging + log linter rollout)