Summary
In a project bound to a workspace whose Snowflake connection lives in the workspace (no local warehouse connection with credentials), every purpose-built FinOps tool fails: finops_warehouse_advice, finops_analyze_credits, finops_query_history, finops_expensive_queries all return FAILED. The workspace's own auto-attached Snowflake cost skills (cost-report, finding-expensive-queries) steer the model to exactly these tools, so the first thing a cost question does is fail four times; the model then recovers by writing raw SQL against SNOWFLAKE.ACCOUNT_USAGE and running it through datamate_snowflake_execute_database_query, which works because the workspace connection has the grants.
Reproduced 3 out of 3 headless runs (v0.12.0, openai/gpt-5.6-sol, engine 0.7.1, --yolo), and on a direct request:
> Call the finops_warehouse_advice tool once for warehouse COMPUTE_WH and paste its raw output verbatim.
⚙ finops_warehouse_advice Warehouse Advice: FAILED
(that run then ended with no assistant text at all; see #1334.)
Cause
packages/opencode/src/altimate/native/finops/warehouse-resolver.ts resolves the connection from the native registry only:
const all = Registry.list().warehouses // ~/.altimate-code/connections.json, project connections.json, ALTIMATE_CODE_CONN_*
...
// No requested warehouse — auto-pick first compatible.
The workspace engine is never consulted. On this machine the registry's first Snowflake entry is a stale snowflake_test with no password, so the driver fails; on a clean laptop (the workspace pilot's promise: no local credentials) there is no Snowflake entry at all and the same tools fail with "no warehouse configured".
This is consistent with the documented routing scope (only sql_execute, sql_explain, schema_inspect are shadowed by the engine, precedence.ts), but the effect for a workspace user is that the cost skills the workspace itself attaches cannot use their tools.
Suggested fix
Options, in order of preference:
- When the project is bound and the engine serves Snowflake execute, let the FinOps tools run their SQL through the engine tool (they are all SQL over
ACCOUNT_USAGE / INFORMATION_SCHEMA), the same way native sql_execute is redirected.
- Or hide / mark unavailable the
finops_* tools when no usable local connection of a supported type exists and the workspace serves that type, and say so in the ## Workspace integrations section, so the model goes straight to the engine.
- At minimum, make the failure message carry the reason ("no local Snowflake connection; the workspace engine serves Snowflake, use datamate_snowflake_execute_database_query") instead of a bare
FAILED.
Context
Found in the headless triage of Reddit-sourced use cases (u04, u06 in ~/demos/workspace-pilot/usecases/report-ab.md on Anand's machine). The recorded demo u05-idle-credits works only because the model falls back to raw SQL; the fallback costs 30 to 60 seconds of visible tool failures per take.
Summary
In a project bound to a workspace whose Snowflake connection lives in the workspace (no local warehouse connection with credentials), every purpose-built FinOps tool fails:
finops_warehouse_advice,finops_analyze_credits,finops_query_history,finops_expensive_queriesall returnFAILED. The workspace's own auto-attached Snowflake cost skills (cost-report,finding-expensive-queries) steer the model to exactly these tools, so the first thing a cost question does is fail four times; the model then recovers by writing raw SQL againstSNOWFLAKE.ACCOUNT_USAGEand running it throughdatamate_snowflake_execute_database_query, which works because the workspace connection has the grants.Reproduced 3 out of 3 headless runs (v0.12.0,
openai/gpt-5.6-sol, engine 0.7.1,--yolo), and on a direct request:(that run then ended with no assistant text at all; see #1334.)
Cause
packages/opencode/src/altimate/native/finops/warehouse-resolver.tsresolves the connection from the native registry only:The workspace engine is never consulted. On this machine the registry's first Snowflake entry is a stale
snowflake_testwith no password, so the driver fails; on a clean laptop (the workspace pilot's promise: no local credentials) there is no Snowflake entry at all and the same tools fail with "no warehouse configured".This is consistent with the documented routing scope (only
sql_execute,sql_explain,schema_inspectare shadowed by the engine,precedence.ts), but the effect for a workspace user is that the cost skills the workspace itself attaches cannot use their tools.Suggested fix
Options, in order of preference:
ACCOUNT_USAGE/INFORMATION_SCHEMA), the same way nativesql_executeis redirected.finops_*tools when no usable local connection of a supported type exists and the workspace serves that type, and say so in the## Workspace integrationssection, so the model goes straight to the engine.FAILED.Context
Found in the headless triage of Reddit-sourced use cases (u04, u06 in
~/demos/workspace-pilot/usecases/report-ab.mdon Anand's machine). The recorded demou05-idle-creditsworks only because the model falls back to raw SQL; the fallback costs 30 to 60 seconds of visible tool failures per take.