You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
ai: tighten public surface and document CuaProvider + supported models (#7)
* ai: tighten public surface and document CuaProvider + supported models
- Un-export parseCuaModelRef/formatCuaModelRef (internal helpers).
- Add docs/supported-models.md enumerating CUA-supported models per
provider with source citations, linked from README.
- Add a CuaProvider section to the README explaining the type, its
relationship to pi-ai's Provider, and the gemini/google rename.
- Drop the now-redundant "See examples/quickstart.ts" line from the
README quick start.
* ai: rename gemini -> google, gate public API via named re-exports
- Rename CuaProvider key from "gemini" to "google" so it matches pi-ai's
Model.provider exactly. providerForModel becomes a thin isCuaProvider
guard. Drops the rename map and the dead piProviderFor switch.
- Switch packages/ai/src/index.ts from `export *` to named re-exports
for models.ts and providers/common.ts. Keeps the public surface to
getCuaModel/listCuaModels/providerForModel/isCuaProvider, the action
types/input types, CUA tool name constants, CUA_ACTION_TYPES, and
createComputerToolDefinitions. Internal exports (parseCuaModelRef,
formatCuaModelRef, findCuaAnnotation, CUA_PROVIDERS,
CUA_MODEL_ANNOTATIONS, schemas) stay reachable from tests via
../src/models.js but are no longer part of the package interface.
- Restore parse/format unit tests, plus update annotation tests to the
new google key.
- Trim README copy: drop the registry/override caveat, drop "with
source citations", and rewrite the CuaProvider section now that the
rename is gone. Reword the action-vocabulary section to talk about
types instead of dropped schemas.
* ai: update integration test gemini ref to google
* ai: stabilize tzafon batch tool integration expectations
Tzafon's model is non-deterministic about emitting tool calls under our
test prompts; mirror the requireToolCalls guard from #8 so a no-tool-call
response no longer fails CI.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
---------
Co-authored-by: rgarcia <72655+rgarcia@users.noreply.github.com>
Co-authored-by: Claude Opus 4.7 <noreply@anthropic.com>
-`isCuaProvider(value: string): value is CuaProvider`
95
106
96
107
Provider namespaces expose `createComputerToolDefinitions({ actions? })` for
97
108
building model-facing pi-ai `Tool[]` definitions. Omit `actions` for the
@@ -130,9 +141,8 @@ Current coordinate contracts:
130
141
-`yutori`: normalized coordinates in the 0-1000 range ([source](https://docs.yutori.com/reference/navigator), [SDK helper](https://github.com/yutori-ai/yutori-sdk-python/blob/main/yutori/navigator/coordinates.py))
131
142
-`tzafon`: normalized coordinates in the 0-999 range ([source](https://docs.lightcone.ai/guides/coordinates/), [model card](https://huggingface.co/Tzafon/Northstar-CUA-Fast))
132
143
133
-
`CuaActionSchema` validates one normalized computer action. The action
134
-
vocabulary is intentionally provider-neutral and OpenAI-shaped because it maps
135
-
cleanly to most browser computer-use APIs:
144
+
The action vocabulary is intentionally provider-neutral and OpenAI-shaped
145
+
because it maps cleanly to most browser computer-use APIs:
136
146
137
147
```ts
138
148
typeCuaAction=
@@ -171,21 +181,21 @@ type CuaActionGoto = {
171
181
};
172
182
```
173
183
174
-
`CuaBatchSchema` validates the input for a batched computer tool:
184
+
The provider namespace `createComputerToolDefinitions()` emits a
185
+
`batch_computer_actions` tool whose input is:
175
186
176
187
```ts
177
188
typeCuaBatchInput= {
178
189
actions:CuaAction[];
179
190
};
180
191
```
181
192
182
-
Use it for a tool like `batch_computer_actions`, where the model can plan
183
-
several writes and reads in one call. Read actions such as `screenshot`, `url`,
184
-
and `cursor_position` can be interleaved with writes so your executor can return
185
-
fresh state in the same order.
193
+
The model can plan several writes and reads in one call. Read actions such as
194
+
`screenshot`, `url`, and `cursor_position` can be interleaved with writes so
195
+
your executor can return fresh state in the same order.
186
196
187
-
`CuaNavigationSchema` validates a smaller convenience tool for high-level
188
-
navigation:
197
+
When `actions` is omitted, the OpenAI namespace also emits a `computer_use_extra`
198
+
navigation tool whose input is:
189
199
190
200
```ts
191
201
typeCuaNavigationInput= {
@@ -194,9 +204,6 @@ type CuaNavigationInput = {
194
204
};
195
205
```
196
206
197
-
Use it for a simple `computer_use_extra`-style tool when you want navigation
198
-
available without exposing the full batch action surface.
199
-
200
207
Provider namespaces:
201
208
202
209
-`openai`: `createComputerToolDefinitions`, `COMPUTER_TOOL_COORDINATES`, OpenAI CUA action schemas, and `OPENAI_BATCH_INSTRUCTIONS`
0 commit comments