The wire · review · first seen Nov 10, 10:32 UTC

Goose updates compaction prompt and Databricks token refresh

Goose v1.58.1 shipped a reworded compaction prompt for Opus 5.5 and pre-expiry refresh for Databricks OAuth tokens. If either path is part of your workflow, this release gives you two specific fixes to check before changing anything else.

L0 · primary1 source2 claims checked4 min read

What shipped

The v1.58.1 release notes say Goose reworded a compaction prompt that Opus 5.5 refuses as distillation. This is a prompt change, not a stated change to Opus 5.5. The wording matters because the release identifies the compaction prompt itself as the part being refused. It does not provide the old or new prompt, so there is no basis here to judge which phrasing made the difference. [1]

The same release says Goose now refreshes Databricks OAuth tokens before they expire. The timing is the stated fix: refresh happens ahead of expiry rather than waiting until after it. The notes do not describe the refresh interval, the conditions that trigger it, or how Goose handles a failed refresh. Treat the release as evidence of the shipped change, not as a specification of its implementation. [1]

These are two separate bug fixes in v1.58.1. One addresses a compaction prompt refused by Opus 5.5; the other addresses the timing of Databricks OAuth token refresh. I would evaluate them separately. A successful compaction check says nothing about token refresh, and a successful Databricks check says nothing about the prompt. The release notes give each fix a clear target, but no broader compatibility claim. [1][2]

Why it matters if you build

For a workflow that uses Goose compaction with Opus 5.5, the relevant question is whether the reworded prompt gets past the refusal described in the release notes. That is a narrower question than whether compaction produces the result you want in every case. I would test the workflow I actually use and record whether the refusal still appears. The supplied notes report the fix but include no test results or scope of validation. [1]

For a workflow that uses Databricks OAuth through Goose, refreshing before expiry should be checked at the point where token timing matters. A short check made well before expiry would not show whether the change works when refresh is needed. The claim is about refresh timing, not a guarantee that every Databricks operation will continue without interruption. The notes provide no expiry duration or refresh schedule to build a timed test around. [1]

Neither fix comes with a quantified cost or limit in the supplied release note. There is no stated token-use effect for the compaction prompt and no stated frequency or overhead for OAuth refresh. That leaves a practical decision: test the affected path if you use it, but do not budget for a measured saving or assume a new service limit from this announcement. Those figures are not established here. [1][2]

How to try it today

1. Check whether the Goose workflow you use is on v1.58.1.
2. If you use compaction with Opus 5.5, run your usual compaction check and note whether the stated distillation refusal appears.
3. If you use Databricks OAuth, check your usual workflow when token refresh is relevant and note whether it continues through that point.
4. Record the two outcomes separately; do not use one as evidence for the other.

What we checked

Every claim below was walked down the source ladder. The rung is how close the source is to the thing itself; the tense is the source's own.

1. shipped L0 · primary

   Goose v1.58.1 rewords a compaction prompt that Opus 5.5 refuses as distillation.

   per GitHub releases · block/goose (L0)
2. shipped L0 · primary

   Goose v1.58.1 refreshes Databricks OAuth tokens before they expire.

   per GitHub releases · block/goose (L0)

What is not confirmed

The source does not show the revised compaction prompt, a before-and-after result, or whether Opus 5.5 accepts it in every workflow. It establishes that Goose shipped a rewording for the specified refusal. It does not establish that all compaction failures have been resolved, or that a different refusal would have the same cause. [1]

The source does not specify how early Databricks OAuth tokens are refreshed, how failures are retried, or whether the change prevents every interruption near expiry. It also gives no measured effect on cost or reliability. Pre-expiry refresh is the shipped behavior stated in the note; the result in your workflow still needs checking. [1]

Who should act, who should wait

Move now if your Goose workflow uses Opus 5.5 compaction that encounters the stated refusal, or Databricks OAuth where token expiry is relevant. Check v1.58.1 against that specific path and keep the result tied to the fix you tested. Wait for more evidence before treating either change as a general reliability improvement, a cost reduction, or a guarantee across workflows. If you use neither path, these notes alone give you no reason to change your workflow today. [1][2]

Sources

• v1.58.1 — GitHub releases · block/goose L0 · primary