Repository navigation
feat(grid): Unify CLI commands and migrate usage team discovery - #169
Conversation
…listing
The usage command listed your teams and your Code settings in each with
GET /v1/routes/settings/users/me/teams, which is being removed. Use
GET /v1/teams for your teams and GET /v1/routes/settings/teams/{team}/users/me
for your settings in each, which say the same things. Org admins are
members of every team, so they still see every team.
Claude-Session: https://claude.ai/code/session_01UkWMh7GwDgbmR88spBWMEm
There was a problem hiding this comment.
🟡 Changes recommended
An existing usage test still invokes the removed harness usage path and will fail.
1 open issue
What changed in this PR
Moves the CLI’s pre-release harness and route commands under baseten grid, preserving their flags and API behavior.
Changes:
- Adds the Grid command tree and removes legacy root paths.
- Updates runner registrations, help examples, and command hints.
- Migrates existing tests and adds namespace regression coverage.
| File | Description |
|---|---|
| internal/cmd/command.route.go | Re-registers route commands under Grid. |
| internal/cmd/command.route_usage.go | Moves route usage registration. |
| internal/cmd/command.route_usage_test.go | Updates route usage invocations. |
| internal/cmd/command.route_test.go | Updates route test paths. |
| internal/cmd/command.route_apikey.go | Updates key registrations and hints. |
| internal/cmd/command.route_apikey_test.go | Updates key-management test paths. |
| internal/cmd/command.harness.go | Updates harness registrations and hints. |
| internal/cmd/command.harness_usage.go | Registers Grid usage. |
| internal/cmd/command.harness_usage_test.go | Migrates usage test invocations. |
| internal/cmd/command.harness_test.go | Updates lifecycle tests and expected hints. |
| internal/cmd/command.harness_defaults.go | Moves defaults registration. |
| internal/cmd/command.harness_defaults_test.go | Updates defaults test paths. |
| internal/cmd/command_test.go | Adds help and legacy-path regression tests. |
| cmd/command.route.go | Updates route help and examples. |
| cmd/command.org.go | Updates API-key help wording. |
| cmd/command.harness.go | Retains shared types after moving declarations. |
| cmd/command.grid.go | Defines Grid and its command subtree. |
| cmd/command.go | Replaces legacy roots with Grid. |
Review effort: Balanced
Pins baseten-go to the client regenerated for the renamed Grid API, so every call site moves to the GetGrid*/PostGrid*/PatchGrid*/DeleteGrid* methods. grid usage now reads your settings from GET /v1/grid/team_settings/users/me and passes --team straight through as team_id: the server uses your only team, or asks for --team when you belong to several. The client-side team listing and name matching are gone, along with the "No usage this month" branch they fed. Claude-Session: https://claude.ai/code/session_01UkWMh7GwDgbmR88spBWMEm
|
Pushed db76a44 on top of this branch (Young). It does the API half of the rename that this PR left for later, and addresses Chad's point on #165 about resolving teams server side. What it changes
Sequencing: this needs the three backend PRs merged and the baseten-go regen merged and re-pinned before it can release, which matches Chad's note that the CLI rename cannot land ahead of the API. The mock-based suite passes; |
Preserve the source PR's all-team usage and team name/ID filtering while using the current Grid API and Grid-named files. Resolve the usage implementation and test conflicts without restoring legacy command files.
* adding functionality to cli * Update go.sum * adding functionality to cli
| Summary: "List API keys", | ||
| Description: "List API keys (metadata only; key values are never returned). " + | ||
| "Routes API keys, which harness setup creates and manages, are listed only with --type routes.", | ||
| "Routes API keys, which grid setup creates and manages, are listed only with --type routes.", |
There was a problem hiding this comment.
I am curious, will we be changing this API key type to "grid routes" and/or do we potentially plan to get rid of this API key type altogether?
There was a problem hiding this comment.
I think we need to support some long lived credentials for the near future, and calling it a Grid API key feels better than Grid Routes? Maybe that introduces some confusion on whether this API key is inference only vs gives the capability for Grid management as well.
I would vote for CLI documentation just calling this Grid API keys for now
There was a problem hiding this comment.
Changed to say Grid API keys
There was a problem hiding this comment.
But does this fix the problem? We still have an API key type API side called "routes" and that API key type will stay named "routes" forever?
There was a problem hiding this comment.
We should probably update the API key type that is surfaced to end users from Routes -> Grid, internally not worth the migration. So I think this change is correct, and we can fast follow with the key type rename
| ctx.LogLine("If you're using a team or workspace API key, run 'baseten auth login' to see your own usage.") | ||
| } | ||
| } | ||
| listing, err := api.GetTeams(ctx, managementapi.GetV1TeamsParams{}) |
There was a problem hiding this comment.
Can you help me understand this a bit? Guess I didn't review this closely when it was first written, but why are we collecting user teams and making an API call per team here? Does this show there is a use case for getting settings across teams and that our assumption in API that you will only want settings for one team is incorrect?
There was a problem hiding this comment.
@cretz how do you feel about us merging route usage and usage into a single command to simplify:
grid route usage [--team] [--user].
--teamis required if the caller is part of multiple teams. if specified,--usermust be in the team specified- you can pass in
--userwhen you are an admin to see a specific user's usage, or no user. that'll give you usage for everyone in the team (resolved or explicit)
There was a problem hiding this comment.
how do you feel about us merging route usage and usage into a single command to simplify:
I would be very much in favor of this and had suggested this (I always like CLI structure being close to API). See the comment I made on grid usage in the internal design document.
--team is required if the caller is part of multiple teams. if specified, --user must be in the team specified
IMO the team and user arguments (or their absence) should react the same as they do API side
There was a problem hiding this comment.
@ShivainVij do you want to centralize around this? lemme know if this works for you too
There was a problem hiding this comment.
cool! going to remove grid usage and all associated tests
`grid usage` listed your teams and fetched your settings in each to draw your spend against your limit, the one place the CLI still stitched teams together client-side. Per the review on this PR, usage is one command: `grid route usage [--team] [--user-id]`, whose arguments behave as the API does. Without --team, usage spans the teams you can see; without --user-id, members see their own usage and admins see everyone's. Your spend against your limit in a team is `grid user-settings describe`. Claude-Session: https://claude.ai/code/session_01UkWMh7GwDgbmR88spBWMEm
The list spans every team you can see unless --team narrows it, so two rows can share a name. A TEAM column, as the connection list already has, tells them apart. Claude-Session: https://claude.ai/code/session_01UkWMh7GwDgbmR88spBWMEm
cretz
left a comment
There was a problem hiding this comment.
Looks good, mostly only little stuff. Can also merge basetenlabs/baseten-go#70 and update go.mod here to use Go SDK main's commit hash
| Summary: "List API keys", | ||
| Description: "List API keys (metadata only; key values are never returned). " + | ||
| "Routes API keys, which harness setup creates and manages, are listed only with --type routes.", | ||
| "Routes API keys, which grid setup creates and manages, are listed only with --type routes.", |
There was a problem hiding this comment.
But does this fix the problem? We still have an API key type API side called "routes" and that API key type will stay named "routes" forever?
| CommandFlags | ||
| GridTeamFlags | ||
| Harness string `flag:"harness" desc:"Harness whose default route IDs to update." enum:"claude-code,codex,opencode,pi"` | ||
| PrimaryRoute OptionalFlag[string] `flag:"primary-route" desc:"Primary route ID; null clears the configured default. Requires --harness." nullable:"true"` |
There was a problem hiding this comment.
Technically this still is inconsistent in that we're asking users to refer to routes by different unique identifiers in different commands. But if you can confirm we are ok with this inconsistency, no prob.

🚀 What
Move the pre-release Grid commands into a consistent
baseten gridhierarchy:baseten harness setup|sync|status|harness-defaults|usage|teardown→
baseten grid setup|sync|status|harness-defaults|usage|teardownbaseten route ...→
baseten grid route ..., includingapi-key list|deleteThe old top-level
harnessandroutecommands are removed without compatibility aliases.Also absorbs #165: replace usage’s dependency on the removed user-teams settings endpoint with team discovery through
/v1/teamsand per-team settings requests through the Grid API.💻 How
Grid command hierarchy
/v1/grid/...API endpoints.Usage team discovery — absorbs #165
GET /v1/teams.GET /v1/grid/team_settings/users/me?team_id=<id>.--teamto select one team by name or ID.The combined implementation no longer calls
GET /v1/routes/settings/users/{user_id}/teams.🧪 Testing
go vet ./...passes.⏭️ Next steps
Planned follow-up PRs: (follow-ups completed here: #173)
grid team-settingsandgrid user-settingscommands (new; including the--team-becomes-optional change for setup/sync)grid connectionandgrid classifiercommands (new)