Gemini caching fixes

[cte]

Context

From OpenRouter:

The current behavior on Google Vertex is to do a Gemini cache lookup with everything prior to the final cache_control directive. Unfortunately as a workaround for a Google AI Studio bug, it's slightly different there: we have to ignore any cache_control directive on the last message, so AI studio will in that situation use the second-to-last breakpoint, if present. We're working with them on making the behavior consistent between the two upstream Google providers.

---

Important

Improved caching logic for various providers with new functions and tests, and made minor UI adjustments in settings components.

• Caching Enhancements:
  • Introduced addCacheBreakpoints function for anthropic, gemini, and vertex in respective files to handle caching logic.
  • Removed formatMessageForCache and addCacheControlDirectives functions.
  • Updated anthropic-vertex.ts, glama.ts, openrouter.ts, and unbound.ts to use new caching functions.
• Testing:
  • Added tests for addCacheBreakpoints in anthropic.test.ts, gemini.test.ts, and vertex.test.ts.
• UI Changes:
  • Removed setCachedStateField prop from ExperimentalSettings in ExperimentalSettings.tsx and SettingsView.tsx.

^{This description was created by for ef7a8b7. You can customize this summary. It will automatically update as commits are pushed.}

[changeset-bot]

⚠️ No Changeset found

Latest commit: ef7a8b7

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

This PR includes no changesets

When changesets are added to this PR, you'll see the packages that this PR includes changesets for and the associated semver types

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[ellipsis-dev]

The pull request involves changes across 9 files, with 351 lines added and 95 lines removed. The changes primarily focus on refactoring caching logic for various providers and adding tests for caching functions. The changes seem to be related to caching logic across different providers and adding tests for these caching functions. The changes are interconnected as they all deal with caching logic, which suggests they might not need to be split. I might be overlooking the possibility that some changes could be unrelated, such as the addition of tests versus the refactoring of caching logic. The addition of tests is directly related to the caching logic changes, as they verify the functionality of the new caching logic. Therefore, splitting the pull request might not be necessary. The changes in the pull request are related to caching logic and its testing, which are interconnected. It seems appropriate to keep them in a single pull request.

[fatihaziz]

I have questions, how i can know if cache is hit?

Is the white area cache?