@@ -86,3 +86,21 @@ jobs:
             echo "Building $pkg..."
             (cd "$pkg" && uv build --out-dir dist)
           done
+
+  # ─── Packaging ──────────────────────────────────────────────────────────────
+  # Installs each wheel into an empty virtualenv with its documented install
+  # command, then imports its public modules and every module its source
+  # imports, lazy ones included. The workspace test run cannot catch an
+  # undeclared dependency, because it installs every package's at once.
+  packaging:
+    name: Packaging check
+    needs: [lint, typecheck, test]
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v4
+      - uses: astral-sh/setup-uv@v5
+        with:
+          python-version: "3.12"
+      - run: uv lock
+      - run: uv sync --all-packages
+      - run: make check-packaging
@@ -86,14 +86,12 @@ Every public module has a committed API report at `packages/<package>/api-report
 
 PRs are squash-merged with the PR title as the commit message, and release-please builds each package's changelog from those messages.
 
-- **A change to an experimental feature uses that feature's scope:** `evaluations` (Evaluations from Code). `feat`, `fix` and `perf` commits with that scope are listed under **Experimental** (`changelog-sections` in `release-please-config.json`), for example `feat(evaluations): score rows in parallel`. Any other scope, such as `client` or `skills`, lists the change as a core feature or fix. Agent Skills is core, so `feat(skills):` lands under Features.
-- **Use exactly one scope.** `feat(evaluations,client):` matches no Experimental row, so it lands under Features.
+- **A change to an experimental feature uses that feature's scope.** `feat`, `fix` and `perf` commits with that scope are listed under **Experimental** (`changelog-sections` in `release-please-config.json`). No feature is experimental now. Any other scope, such as `client`, `skills` or `evaluations`, lists the change as a core feature or fix. Agent Skills and Evaluations from Code are core, so `feat(skills):` and `feat(evaluations):` land under Features.
+- **Use exactly one scope.** `feat(beta,client):` matches no Experimental row, so it lands under Features.
 - **A PR that changes both core and experimental behaviour** should be split. If it can't be, add a `BEGIN_COMMIT_OVERRIDE` block to its description with one conventional-commit line per change. An override also corrects a merged PR's title, as long as the release PR hasn't merged yet.
-- **A breaking experimental change** uses `!` while the package is 0.x: `feat(evaluations)!:` bumps the minor version, which is what an experimental break is allowed. After 1.0, `!` would force a major release. Use `feat(evaluations):` without `!` instead, and say the change is breaking in the title.
+- **A breaking experimental change** uses `!` while the package is 0.x: `feat(beta)!:` bumps the minor version, which is what an experimental break is allowed. After 1.0, `!` would force a major release. Use `feat(beta):` without `!` instead, and say the change is breaking in the title.
 - **When a feature is promoted to core,** remove its rows from `changelog-sections`.
 
-The rule is specified in `TESTING.md` §0.3 in `launchdarkly/ai-sdks-monorepo`.
-
 ## Package Hierarchy
 
 The monorepo is organized into three tiers plus a convenience barrel. Dependencies only flow **downward** — never sideways between packages in the same tier, and never upward.
 
@@ -1,4 +1,4 @@
-.PHONY: start test typecheck lint format format-check lint-fix build clean api-report api-report-check
+.PHONY: start test typecheck lint format format-check lint-fix build check-packaging clean api-report api-report-check
 
 # Run main.py (uv run python main.py)
 start:
@@ -49,6 +49,14 @@ build:
 		(cd $$pkg && uv build --out-dir dist); \
 	done
 
+# Install each built wheel into an empty virtualenv and check its imports resolve there
+check-packaging:
+	rm -rf dist
+	@for pkg in packages/*/; do \
+		(cd $$pkg && uv build --quiet --wheel --out-dir ../../dist); \
+	done
+	uv run python scripts/check_packaging.py dist
+
 # Clean build artifacts
 clean:
 	rm -rf packages/*/dist
@@ -91,20 +91,26 @@ Tier 0 — Core Client           (launchdarkly-ai-server)
 | [`launchdarkly-ai-vercel-agents`](packages/vercel-agents/README.md) | `*` (any) | `agent` | Native Vercel `ai.Agent` loop and graph adapter |
 | [`launchdarkly-ai-typesafe`](packages/typesafe/README.md) | TypeSafe | `messages` | TypeSafe Jev judge handler |
 
+### Versioning
+
+From 1.0.0 every package in this SDK is released at the same version, so install them at matching versions. Each package depends on `launchdarkly-ai-server` within the same major (`>=1.0,<2`), and a breaking change in any package is a new major for all of them. Names exported from `launchdarkly_ai_server.experimental` are the exception: they may change in a minor release.
+
+Every third-party floor sits on the release line CI tests: the same major as the tested version for a 1.x or later library, the same minor for a 0.x one, where a minor release may break. A floor that was below that line was raised to the tested version; a floor already on it stayed where it was.
+
 ## Quick Start
 
 ### 1. Install
 
 ```bash
-pip install launchdarkly-ai-python launchdarkly-server-sdk launchdarkly-ai-openai-messages
+pip install "launchdarkly-ai-python[ld]" launchdarkly-ai-openai-messages
 ```
 
-`launchdarkly-ai-python` is a thin barrel that re-exports all of `launchdarkly-ai-server`. The base LaunchDarkly Python SDK is a peer dependency rather than a bundled one, so install `launchdarkly-server-sdk` alongside it. `init_client()` discovers it at runtime, or you can skip it entirely by passing a pre-initialized client with `init_client(client=my_client)`.
+`launchdarkly-ai-python` is a thin barrel that re-exports all of `launchdarkly-ai-server`. The base LaunchDarkly Python SDK is an optional dependency rather than a bundled one; the `[ld]` extra installs `launchdarkly-server-sdk`. `init_client()` discovers it at runtime, or you can skip it entirely by passing a pre-initialized client with `init_client(client=my_client)`.
 
 **With telemetry** (recommended for production) — traces export to the LaunchDarkly Observability dashboard:
 
 ```bash
-pip install "launchdarkly-ai-python[otel]" launchdarkly-server-sdk launchdarkly-ai-openai-messages
+pip install "launchdarkly-ai-python[ld,otel]" launchdarkly-ai-openai-messages
 ```
 
 No code changes are needed — `init_client()` detects whether the OTel packages are present at runtime and configures the tracer provider automatically. If they are absent, the SDK logs a one-time warning and continues normally.
@@ -574,7 +580,7 @@ When running inside `graph()`, every node's events carry the graph key, tool inv
 
 ### Optional dependencies
 
-The OpenTelemetry SDK packages are **optional** — detected at runtime via `importlib`. The LaunchDarkly server SDK (`launchdarkly-server-sdk`) is also an optional dependency; pass a pre-initialized client to `init_client(client=...)` if you bring your own.
+The OpenTelemetry SDK packages are **optional** — detected at runtime via `importlib`. The LaunchDarkly server SDK (`launchdarkly-server-sdk`) is also an optional dependency, installed by the `[ld]` extra; pass a pre-initialized client to `init_client(client=...)` if you bring your own.
 
 **OTel packages** (installed via `pip install "launchdarkly-ai-python[otel]"` or `pip install "launchdarkly-ai-server[otel]"`):
 - **If installed:** `init_client()` sets up a `TracerProvider` with a GZIP-compressed OTLP HTTP exporter and W3C trace-context/baggage propagators — no code changes needed.
 
@@ -5,7 +5,7 @@ Convenience barrel package for the LaunchDarkly AI Python SDK. Re-exports the co
 ## Installation
 
 ```bash
-pip install launchdarkly-ai-python launchdarkly-ai-openai-messages
+pip install "launchdarkly-ai-python[ld]" launchdarkly-ai-openai-messages
 ```
 
 To enable trace export to the LaunchDarkly Observability dashboard, install the `otel` extras group:
@@ -70,10 +70,10 @@ Experimental features are not re-exported from this package. They live in
 `launchdarkly-ai-server`, the package this one depends on, and need a `launchdarkly-ai-server`
 release that includes them. Import them from `launchdarkly_ai_server.experimental`; if that
 import fails, upgrade `launchdarkly-ai-server` itself, since upgrading this package alone can
-leave an older `launchdarkly-ai-server` in place. The experimental feature is:
+leave an older `launchdarkly-ai-server` in place. No feature is experimental now.
 
-- **Evaluations from Code**, in `launchdarkly_ai_server.experimental.evaluations`; see the
-  [evaluations guide](https://github.com/launchdarkly/python-ai-sdk/blob/main/packages/client/README.md#run-an-evaluation-from-code-experimental).
+Evaluations from Code is core, so this package re-exports it. See the
+[evaluations guide](https://github.com/launchdarkly/python-ai-sdk/blob/main/packages/client/README.md#run-an-evaluation-from-code).
 
 ---
 
 
@@ -9,7 +9,7 @@ license = "Apache-2.0"
 authors = [{name = "LaunchDarkly", email = "team@launchdarkly.com"}]
 keywords = ["launchdarkly", "ai", "feature-flags", "sdk"]
 classifiers = [
-  "Development Status :: 3 - Alpha",
+  "Development Status :: 5 - Production/Stable",
   "Intended Audience :: Developers",
   "License :: OSI Approved :: Apache Software License",
   "Programming Language :: Python :: 3",
@@ -24,6 +24,7 @@ Repository = "https://github.com/launchdarkly/python-ai-sdk"
 
 [project.optional-dependencies]
 otel = ["launchdarkly-ai-server[otel]>=1.0.0,<2"]
+ld = ["launchdarkly-ai-server[ld]>=1.0.0,<2"]
 
 [build-system]
 requires = ["hatchling>=1.32,<2"]
 
@@ -6,6 +6,7 @@
 __version__ = "0.4.0"  # x-release-please-version
 
 from launchdarkly_ai_server import *  # noqa: F403
+from launchdarkly_ai_server import __all__ as __all__
 from launchdarkly_ai_server import register_ai_sdk_package
 
 register_ai_sdk_package("launchdarkly-ai-python", __version__)
@@ -1,6 +1,5 @@
 """
-Tests for §5 launchdarkly-ai-python re-export barrel.
-Reference: TESTING.md §5
+Tests for the launchdarkly-ai-python re-export barrel.
 """
 
 import importlib
@@ -16,6 +15,12 @@ def test_all_named_exports_from_server_are_reexported(self) -> None:
                 f"launchdarkly_ai_python is missing re-export: {name!r}"
             )
 
+    def test_all_matches_server(self) -> None:
+        server = importlib.import_module("launchdarkly_ai_server")
+        barrel = importlib.import_module("launchdarkly_ai_python")
+
+        assert barrel.__all__ == server.__all__
+
     def test_reexported_values_are_identical_references(self) -> None:
         server = importlib.import_module("launchdarkly_ai_server")
         barrel = importlib.import_module("launchdarkly_ai_python")
@@ -27,9 +32,9 @@ def test_reexported_values_are_identical_references(self) -> None:
                 f"launchdarkly_ai_python.{name} is not the same object as launchdarkly_ai_server.{name}"
             )
 
-    def test_experimental_evaluations_are_not_reexported(self) -> None:
-        importlib.import_module("launchdarkly_ai_server.experimental.evaluations")
+    def test_evaluations_are_reexported(self) -> None:
+        server = importlib.import_module("launchdarkly_ai_server")
         barrel = importlib.import_module("launchdarkly_ai_python")
 
         for name in ("init_evaluations", "EvalTool", "Judge", "Scorer", "DatasetRow"):
-            assert not hasattr(barrel, name), name
+            assert getattr(barrel, name) is getattr(server, name), name
@@ -7,7 +7,7 @@ Anthropic Claude handler for `launchdarkly-ai-server` using the **Claude Agent S
 ## Installation
 
 ```bash
-pip install launchdarkly-ai-server launchdarkly-ai-claude-agents
+pip install "launchdarkly-ai-server[ld]" launchdarkly-ai-claude-agents
 ```
 
 Set `ANTHROPIC_API_KEY` in your environment (the Anthropic SDK reads it automatically).
@@ -74,6 +74,15 @@ to_claude_agents(
 )
 ```
 
+### Output limit and thinking
+
+- `max_tokens` in the config's model parameters sets the output-token limit for each model request. The Agent SDK has no option for it, so the handler sets `CLAUDE_CODE_MAX_OUTPUT_TOKENS` in the environment of the Claude Code process. Without `max_tokens`, Claude Code uses its own default. A `CLAUDE_CODE_MAX_OUTPUT_TOKENS` in the `env` of a Claude Code settings file, including `~/.claude.json`, wins over `max_tokens`.
+- Thinking is off unless the config sets `thinking` or `max_thinking_tokens`. Models that reject disabled thinking, such as `claude-fable-5`, still use their own default. Claude Code lowers a thinking budget to one less than `max_tokens`, so when a config sets both, keep `max_tokens` above the budget.
+
+#### Migrating from a version that used Claude Code's thinking default
+
+Earlier versions passed no thinking setting when the config had none, so Claude Code chose one: adaptive thinking on models that support it, and a 31,999-token budget on others such as `claude-haiku-4-5`. A run now thinks only when its config asks. To keep thinking, set it in the config's model parameters, for example `{"thinking": {"type": "adaptive"}}`.
+
 ### Convenience wrapper
 
 ```python
 
@@ -55,7 +55,7 @@ def claude_graph(key: str, *, cwd=None, setting_sources=None, **options): ...
 
 # Native graph adapter — builds a Claude code-agents graph from a resolved GraphDefinition.
 # opts: context, tool_handlers, and the host options cwd and setting_sources
-def to_claude_agents(def_promise: Awaitable[dict], opts: dict | None = None): ...
+def to_claude_agents(def_promise: Awaitable[GraphDefinition], opts: ClaudeNativeGraphOptions | None = None) -> NativeGraphRunner: ...
 
 # NativeTool sentinels for Claude Code built-in capabilities
 ClaudeBash: NativeTool
@@ -141,7 +141,7 @@ The CLI also writes its own `AssistantMessage`, with `model` set to the literal
 an API call fails and after a response stops at `max_output_tokens`. It is not a model response:
 it gets no `chat` span and never joins the conversation a later span reports.
 
-**Important:** a bare `return` inside `async for` abandons the generator. Python's asyncio finalizer will try to `aclose()` it later and may raise `RuntimeError: aclose(): asynchronous generator is already running` if the generator is still suspended inside a real SDK `await`. Always use `break` + explicit `aclose()`. See **Appendix A.4** in `TESTING.md`.
+**Important:** a bare `return` inside `async for` abandons the generator. Python's asyncio finalizer will try to `aclose()` it later and may raise `RuntimeError: aclose(): asynchronous generator is already running` if the generator is still suspended inside a real SDK `await`. Always use `break` + explicit `aclose()`.
 
 ### 4. Telemetry
 
@@ -236,6 +236,6 @@ Span names and attributes are described in [Implementation Details → Telemetry
 ## Common Pitfalls
 
 - **MCP tool name prefix**: tools registered in the MCP server are accessible as `mcp__tool-mcp__<name>`. The `allowed_tools` list must use this prefix; omitting it will cause the agent to not invoke any tools.
-- **Async generator teardown**: always use `break` inside `async for` (not `return`) and wrap the loop in `try/finally: await gen.aclose()`. See TESTING.md Appendix A.4.
+- **Async generator teardown**: always use `break` inside `async for` (not `return`) and wrap the loop in `try/finally: await gen.aclose()`.
 - **`message.usage` shape**: the raw usage dict from the `claude_agent_sdk` is passed through directly to `parse_usage`. It accepts `input_tokens`/`output_tokens` which the SDK provides.
 - **Native tools** (`ClaudeWebSearch`, etc.) are registered in `tool_handlers` as `NativeTool` sentinel instances (not callables). The handler's `_partition_tools` function separates them from user-defined tools — native tools go into `native_tool_names` for the agent's built-in access, user tools go through the MCP server.