Skip to content

feat: fast mode on lucy-vton-3.6; lucy-vton-latest resolves to 3.6 - #15

Merged
tomershlasky merged 1 commit into
mainfrom
vton-3-6-fast-latest
Oct 12, 2026
Merged

tomershlasky merged 1 commit into
mainfrom
vton-3-6-fast-latest

Conversation

@tomershlasky

@tomershlasky tomershlasky commented Oct 11, 2026 •

Copy link
Copy Markdown
Contributor

Summary

Mirrors DecartAI/sdk#222. Two registry/doc changes:

  1. Fast mode on lucy-vton-3.6. The API now serves 3.6 on the fast tier, billed at 2x like 3.5. The 3.6 entry now advertises Speed::Fast in supportedSpeeds, so ConnectOptions::speed = Speed::Fast no longer logs the "unsupported speed" warning for it.
  2. lucy-vton-latest now resolves server-side to lucy-vton-3.6 (was 3.5). Geometry is identical (1280x720 @ 30fps) and the alias already had fast mode, so only comments/docs/tests change. 3.6 is no longer opt-in-only.

Fast set after this PR: lucy-2.5, lucy-latest, lucy-vton-3.5, lucy-vton-3.6, lucy-vton-latest.

Changes

File Change
src/models.cpp /*fastSpeed=*/true on the lucy-vton-3.6 entry; alias comment "Resolves server-side to lucy-vton-3.6"
include/decart/models.h realtime() doc notes that aliases are server-resolved (lucy-vton-latest currently serves 3.6)
include/decart/realtime/types.h, include/decart/realtime/realtime.h, README.md, examples/realtime_warmup.cpp fast-mode model lists now include lucy-vton-3.6
tests/test_models.cpp 3.6 geometry block asserts supportedSpeeds == {Fast}; 3.6 added to the explicit fast checks and the withFast set; removed from the standard-only list; alias test asserts lucy-vton-latest geometry matches lucy-vton-3.6
tests/test_stream_url.cpp supportsSpeed(lucy-vton-3.6, Fast) positive check

No version bump.

Verification

Linux (Amazon Linux 2023) / GCC 11.5 / CMake 3.22 / Ninja:

Command Result
./scripts/format.sh --check (clang-format 15.0.7) clean
CI-style configure + build (-DDECART_BUILD_EXAMPLES=ON -DDECART_BUILD_TESTS=ON -DDECART_LIVEKIT_VERSION=1.11.0) every translation unit compiles (incl. realtime_warmup.cpp, test_models.cpp, test_stream_url.cpp); linking fails locally because the prebuilt LiveKit 1.11.0 binaries require glibc 2.38 / GLIBCXX_3.4.32 and this host has glibc 2.34. Environment issue, unrelated to this change; CI on ubuntu-latest/macOS/Windows is the authoritative full-build check.
cmake -DDECART_BUILD_REALTIME=OFF -DDECART_BUILD_TESTS=ON + ctest 1/1 passed; decart_tests: 19 test cases, 102 assertions, 0 failed (includes test_models.cpp and test_stream_url.cpp; only test_messages.cpp, untouched here, is excluded in this config)
Same tests with the src/models.cpp change reverted 3 test cases / 4 assertions fail, so the new assertions do pin the change

Server-side

  • Fast mode for lucy-vton-3.6 is already live on the API.
  • The lucy-vton-latest → 3.6 alias change is rolling out on the API separately. This PR only changes docs/comments for the alias (geometry and fast capability are identical for 3.5 and 3.6), so merge order doesn't matter.

Companion PRs (lucy-vton-3.6: fast mode + lucy-vton-latest → 3.6)

tomershlasky added a commit to DecartAI/sdk that referenced this pull request Oct 12, 2026
…lves to 3.6 (#222)

## Description

Two updates for `lucy-vton-3.6`, now that the API supports them:

1. **Fast mode on `lucy-vton-3.6`.** The realtime registry entry gains
`supportedSpeeds: ["fast"]`. The API already serves 3.6 on the fast
tier, billed at 2x the standard realtime rate like 3.5. Without this
change, `speed: "fast"` on 3.6 logs a "model does not list it" warning.
This applies to realtime only; batch has no speed tier.
2. **`lucy-vton-latest` → `lucy-vton-3.6`.** The alias resolves
server-side, so the SDK only updates comments, docs and test names. 3.5
and 3.6 have identical geometry: realtime 1280x720 at `{ideal: 30, max:
30}`, video 1280x720 at 20 fps. The alias entries keep their values, and
`lucy-vton-latest` keeps `supportedSpeeds: ["fast"]`.

Following the AGENTS.md runbook, `supportedSpeeds` is added only now
that the API actually serves 3.6 on the fast tier.

## Changes

| File | Change |
| --- | --- |
| `src/shared/model.ts` | `supportedSpeeds: ["fast"]` on realtime
`lucy-vton-3.6`; both `lucy-vton-latest` comments now point at 3.6 |
| `src/realtime/client.ts`, `README.md`, `index.html` | fast-mode model
lists now include `lucy-vton-3.6` |
| `AGENTS.md` | removes "opt-in by name; no fast tier" from 3.6;
`lucy-vton-latest` → `lucy-vton-3.6` |
| `tests/unit.test.ts` | adds 3.6 to `fastRealtimeModels` (the pinned
exact set); 3.6 asserts `["fast"]`; latest test titles say 3.6 |
| `tests/realtime.unit.test.ts` | adds 3.6 to the "no speed warning"
loop |

## Verification

| Command | Result |
| --- | --- |
| `pnpm --filter @decartai/sdk typecheck` | pass |
| `pnpm --filter @decartai/sdk test` | 386 passed (15 files) |
| `pnpm --filter @decartai/sdk build` | pass |
| `pnpm --filter @decartai/sdk test:package` | pass |
| `pnpm --filter @decartai/sdk format:check` | 86 files, clean |

The live e2e was not run locally because no `DECART_API_KEY` was
available.

## Compatibility

Additive. `models.realtime("lucy-vton-3.6").supportedSpeeds` changes
from `undefined` to `["fast"]`. No ids, geometry or types change.

## Server-side

- Fast mode for `lucy-vton-3.6` is already live on the API.
- The `lucy-vton-latest` → 3.6 alias change is rolling out on the API
separately. Only docs and comments here depend on it, so merge order
doesn't matter.

---
### Companion PRs (lucy-vton-3.6: fast mode + `lucy-vton-latest` → 3.6)
- JS SDK: #222
- Python: DecartAI/decart-python#73
- iOS: DecartAI/decart-ios#49
- Android: DecartAI/decart-android#34
- C++: DecartAI/decart-cpp#15

<!-- conductor-workspace-link -->

---

[Open workspace in Conductor](https://app.conductor.build/decart/w/261)
@tomershlasky
tomershlasky merged commit 4672952 into main Oct 12, 2026
4 checks passed
@tomershlasky
tomershlasky deleted the vton-3-6-fast-latest branch October 12, 2026 10:29
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants