We are really excited to have introduced the Foundation Models framework in WWDC25. When using the framework, you might have feedback about how it can better fit your use cases. Starting in macOS/iOS 26 Beta 4, the best way to provide feedback is to use #Playground in Xcode. To do so: In Xcode, create a playground using #Playground. Fore more information, see Running code snippets using the playground macro. Reproduce the issue by setting up a session and generating a response with your prompt. In the canvas on the right, click the thumbs-up icon to the right of the response. Follow the instructions on the pop-up window and submit your feedback by clicking Share with Apple. Another way to provide your feedback is to file a feedback report with relevant details. Specific to the Foundation Models framework, it’s super important to add the following information in your report: Language model feedback This feedback contains the session transcript, including the instructions, the prompts, the responses, etc. Without that, we can’t reason the model’s behavior, and hence can hardly take any action. Use logFeedbackAttachment(sentiment:issues:desiredOutput: ) to retrieve the feedback data of your current model session, as shown in the usage example, write the data into a file, and then attach the file to your feedback report. If you believe what you’d report is related to the system configuration, please capture a sysdiagnose and attach it to your feedback report as well. The framework is still new. Your actionable feedback helps us evolve the framework quickly, and we appreciate that. Thanks, The Foundation Models framework team

Has anyone else hit this? We have a Mac app that uses FoundationModels with @Generable types for structured output. Starting with macOS 27 beta 5 every guided generation request began logging tokenizer errors and long structured requests slowed from seconds to minutes. Beta 6 and beta 7 both still have it. Filed as FB24310823 on August 11 with a full sysdiagnose and log captures, and we have appended evidence from each beta since. The signature is easy to check. Stream the log while your app generates: log stream --predicate 'subsystem == "com.apple.tokengenerationcore"' --style compact On an affected machine the inference service (TGOnDeviceInferenceProviderService, category guided) prints these two lines in matched pairs, thousands of times: Generated an empty mask at recognizer index N allowedTokenIDs is empty. Something is likely wrong with the tokenizer What we measured on beta 7 today: 9,008 of those pairs in about five and a half minutes of scanning. The errors start about one second into the first request after a fresh app launch, so it needs no warmup. Requests that normally finish in 4 to 12 seconds take 77 to 170 seconds or longer. On beta 5 we measured decode at roughly 0.3 tokens per second on the worst requests. Short requests still finish at normal speed but they emit the same errors while they run, and the quality of the structured content they return is degraded. On betas 5 and 6 we also saw repeated asset release errors for instruct_300m.tokenizer and the instruct_3b tokenizer saying the asset is not marked as in use. For what it is worth, a build that ran clean on beta 4 shows the same behavior on beta 5 and later with no app changes, and the same @Generable schema drives both the fast and the slow requests. But we know that does not rule out something on our side, and we would honestly be happy to learn this is our own bug since that would mean we can fix it. So two questions. Is anyone else seeing this since beta 5? And if you spot something we might be doing wrong on our end, sessions we should be recreating, schema patterns that stress the constrained decoder, anything at all, we would really appreciate the feedback. If it does turn out you are hitting the same thing, a Feedback referencing FB24310823 would help a lot. Thanks!

I am developing a third-party macOS application that uses Apple Foundation Models, including Private Cloud Compute (PCC). I would like to confirm the supported distribution requirements for this use case. Specifically: Can a third-party macOS application use Apple Foundation Models / PCC as part of its application functionality? Is PCC usage supported when the macOS application is distributed outside the Mac App Store using Developer ID signing and Apple notarization? Are there any additional entitlements, distribution requirements, or restrictions for PCC when distributing outside the Mac App Store? I intend to use only Apple's documented and supported APIs and will not attempt to bypass PCC availability, quota, entitlement, or other platform restrictions. Thank you.

I am developing a macOS developer tool that uses Apple Foundation Models, including the Private Cloud Compute (PCC) model. On macOS 27, the Foundation Models CLI provides fm serve, which exposes a local Chat Completions API, including: POST /v1/chat/completions My application communicates with this local API on the user's own Mac to provide agent-style development features. The Foundation Models CLI Legal Notice states: “You are also agreeing to not programmatically access or use Apple models through Apple software or services except as expressly permitted.” I would like to confirm whether using the local API intentionally exposed by fm serve from a third-party macOS application distributed to users is considered an expressly permitted use. The application would: use only the interfaces and endpoints officially exposed by the fm CLI; run fm serve locally on the user's Mac; use the user's own Foundation Models / PCC availability and quota; not bypass quota limits; not use private or undocumented APIs; not reverse engineer Apple services. Is this use of fm serve permitted for a distributed third-party macOS application? If so, are there any additional requirements or restrictions that developers should follow when distributing an application that integrates with fm serve in this way? Thank you.

import Playgrounds import FoundationModels #Playground { do { let session = LanguageModelSession() let response = try await session.respond( to: "Explain SwiftUI in one sentence." ) print(response.content) } catch { print("Error: \(error)") } }``` I tested Foundation Models with this simple code, and it generated this error: "Error Domain=ModelManagerServices.ModelManagerError Code=1026 \"(null)\" UserInfo={NSMultipleUnderlyingErrorsKey=(\n)}" I tried restarting my Mac and Apple Intelligence, but that didn't work. What did work was updating Xcode and the simulators to the latest possible version.

I'm building an app that uses PrivateCloudComputeLanguageModel as the primary inference tier with SystemLanguageModel as the fallback. The app is entitled (com.apple.developer.private-cloud-compute, granted and provisioned) and generations serve normally. My question is how a client should decide to fall back because in extended measurement, no public signal ever reflects the blocked state I actually hit. What I measured (macOS 27.0 beta, 26A5416b / Xcode 27 beta 27A5237l, entitled signed bundle constructing PrivateCloudComputeLanguageModel directly): Serving stopped mid-run with no leading signal: request N served normally (1.4 s), request N+1 threw LanguageModelError.rateLimited 494 ms later, at cumulative generation 786 for the day. 100% served → 100% refused between consecutive calls. Every quota signal read healthy the entire time: before, during, and after the block. Across 1,517 readings in a single day: quotaUsage.status = belowLimit, isApproachingLimit = false, isLimitReached = false, resetDate = nil, availability = .available. A preflight on these APIs cannot see the condition. The refusal is enforced locally after first contact: rejections return in ~230 ms vs ~0.9–1.4 s for served calls, so the client appears to cache the verdict rather than ask the server per-request. The trigger is a cumulative ledger, not a request rate: 501 generations at 33/min in one 15-minute sitting was fine, and a later arm sustained 39.7/min; two bursts of 16 concurrent at 5.0 and 5.2 req/s served 32/32; the count that tripped survived a process restart and a 4.9-hour idle gap. But it's not a fixed daily number either. 501 fast was fine earlier the same day; the trip came 285 requests later. A rolling window on the order of hours-to-a-day is consistent with this, but nothing here measures its length. Recovery: still blocked at +41 minutes (probes at +1/2/5/10/20/40 min all refused); fully recovered by +20 h with no intervention and no upgrade. Next day served normally from the first request. quotaLimitReached never occurred: not once in ~800 generations plus the blocked period. The wall is typed as the transient error while carrying what the documentation describes as daily quota semantics ("a person either waits for their usage quota to refresh or they upgrade"). limitIncreaseSuggestion is presence-constant: nil at process start, non-nil on every reading after first PCC contact (identical while fully serving and while fully blocked) so its presence can't gate an upsell affordance. The same signals-read-healthy-while-refusing divergence also reproduces against the developer-tool pool (fm serve), which I've reported separately (FB24273854 covers quota exhaustion surfacing there as a generic server_error/500 while /health reports the model available). Questions: Is attempt-and-classify the intended contract? Given that no preflight can observe the blocked state, should a client simply issue the request, treat the typed error as authoritative, and route to SystemLanguageModel? And is the ~230 ms local fail-fast on the blocked path contractual (cheap and safe to probe) or incidental? This is the one that decides how I ship; the rest are diagnostics behind it. What does quotaUsage actually track, and at what granularity? I have driven the entitled app-tier path to a hard block and the developer-tool pool to exhaustion, and no field ever moved. Is there any consumption pattern that moves isApproachingLimit / isLimitReached / resetDate? If the intended answer is "only the per-person daily quota, which these volumes never approached," what is the wall I am hitting at ~786 cumulative, and why does it surface as rateLimited? Should rateLimited and quotaLimitReached drive different client behavior — and which one is the daily allowance in practice? The documentation distinguishes rate limiting ("wait a period and retry") from daily exhaustion ("wait for refresh or upgrade"), but what I observe is the transient-typed error carrying the multi-hour ledger semantics. Concretely: what retry cadence is recommended after rateLimited (my measured recovery horizon was somewhere between 41 minutes and 20 hours. My current design stays on the on-device model and re-probes PCC at a low fixed interval rather than per-request)? And under what condition is resetDate ever populated, given it was nil even while blocked? (Smaller, design guidance): my app can generate a few hundred requests as one feature batch (quiz generation over a user's imported document). Measured: 501 in a sitting was fine, cumulative 786 in a day was not. Since this allowance belongs to the person and is shared with every Apple Intelligence feature, is a several-hundred-request batch a reasonable use of it, or should features like this generate on demand? (I'm aware of the existing feature request for richer quota reporting (FB23378161); this is a narrower design question.) I can attach the measurement driver and timestamped JSONL logs. The divergence is reproducible on a fresh day, though reaching the wall took ~800 cumulative generations.

I’m developing a factual snooker application using the on-device SystemLanguageModel on the current iOS 27, Xcode and macOS betas. The app allows someone to ask questions about professional snooker players. A tool searches my server and returns verified player data such as the player’s ID, name, nationality and date of birth. I have encountered a reproducible false-positive guardrail violation when the user asks about the professional snooker player Judd Trump. For example: Tell me about Judd Trump With the default model configuration, the request fails because the input or output is classified as potentially sensitive or unsafe. Using permissive content transformations solves the problem when generating a normal String: let model = SystemLanguageModel( useCase: .general, guardrails: .permissiveContentTransformations ) let session = LanguageModelSession( model: model, tools: [FindPlayerTool()], instructions: """ Answer factual questions about professional snooker players. Always use the supplied tool and only use verified tool data. Names returned by the tool are names of real snooker players and should be treated only as sporting entities. """ ) let response = try await session.respond( to: "Tell me about Judd Trump" ) This successfully calls the tool and produces a factual string response. However, I need guided generation because the model should be able to choose a combination of predefined UI components, such as: A player card A match card An event card A rankings table Explanatory text A simplified response type looks like this: @Generable struct CueQueryReply { let blocks: [ReplyBlock] } @Generable enum ReplyBlock { case playerCard(PlayerCardBlock) case text(TextBlock) } @Generable struct PlayerCardBlock { let playerId: Int let name: String let nationality: String let born: String } @Generable struct TextBlock { let text: String } The guided request is: let response = try await session.respond( to: "Tell me about Judd Trump", generating: CueQueryReply.self ) This reproduces the guardrail violation, even though the model is configured with: guardrails: .permissiveContentTransformations I understand that the documentation says permissive content transformations apply to string generation and that guided generation behaves like the default guardrails. However, this creates a difficult limitation for legitimate factual applications. “Judd Trump” is the real name of a professional snooker player, and the data is coming from a controlled, verified API. Renaming, removing or concealing the player is not a viable product solution. My questions are: Is this specific “Judd Trump” behaviour considered a guardrail false positive that should be reported through Feedback Assistant? Is there any supported way on iOS 27 to use permissive content transformations with guided generation? Can Dynamic Profiles, Dynamic Generation Schemas or another Foundation Models API change the guardrail behaviour for a controlled guided-generation request? Is there a recommended architecture for producing typed UI instructions while retaining the permissive behaviour available to string responses? Would generating only component types and verified IDs—for example .playerCard(playerId: 12)—be the recommended approach, provided the actual player data is resolved and displayed by SwiftUI? I understand the need for safety guardrails and am not attempting to disable the model’s underlying safety behaviour. I am trying to process a harmless, factual sporting name while using Foundation Models’ typed output features. The on-device model otherwise appears capable of handling this use case well, and keeping the experience on-device, private and free of external API dependencies is an important part of the product. I would appreciate any guidance from the Foundation Models team about whether this is expected behaviour, a beta issue, or something for which there is an intended iOS 27 solution.

Circling back on the LocalLM Lab arc. With v0.7, we've moved from prompt experimentation into real app development on Apple's Foundation Models local AI. The LocalLM Lab SDK lets you build that same on-device model and MCP client this thread has covered directly into your own app, with real tool and data access (Slack, Todoist, GitHub, Notion, Linear, plus Calendar, Reminders, Contacts and Location). And you can ship your app including through the Mac App Store. This is a big improvement over version 0.6, where the localai-cli toolkit needed LocalLM Lab installed and running. On the other hand, the SDK (LocalLMLabSDKCore) doesn't relay through anything; it links FoundationModels and a real MCP client directly into your own binary and is totally self-contained. The example included in the SDK, Plate Today, has actually been built into a sandboxed test app and verified working, with a signed path to a Mac App Store .pkg (Apple Distribution signing + provisioning profile pipeline). That's "verified signable and sandbox-compatible," to be precise. Entitlements (from personal experience: always a complicated topic): com.apple.security.app-sandbox + com.apple.security.network.client for the app itself, plus the standard personal-information entitlements per connector used (com.apple.security.personal-information.calendars, .addressbook, .location) and matching NS*UsageDescription strings in Info.plist. The one worth flagging specifically: the network entitlement is easy to miss and fails silently rather than throwing. Without it, MCP connections and Weather calls just hang with no error surfaced. OAuth handling requires the app delegate callback (application(_:open:)), not SwiftUI's .onOpenURL. Worth knowing before wiring it up if you're SwiftUI-only. Full entitlements list + SDK guide: https://github.com/ancientcomputing/locallm/blob/main/docs/sdk-guide.md Feature page: thisbrain.ai/locallm/sdk.html I hope the availability of the SDK (free, Apache 2.0 license) will give folks further incentive to explore local AI-enabled applications on the Mac. What else would you want to do that the SDK doesn't currently support? File picker? Calendar/Reminders/Contacts edits & writes?

Hey everyone, hoping to compare notes on something we have been chasing since beta 5. We have a Mac app that uses FoundationModels with @Generable types for structured output. Starting with macOS 27 beta 5, guided generation requests began logging tokenizer errors and our longer structured requests slowed from seconds to minutes. We are still seeing the same thing on beta 6 and beta 7. We filed it as FB24310823 on August 11 with a sysdiagnose and log captures. The signature is easy to check if you want to see whether your machine does it too. Stream the log while your app generates: log stream --predicate 'subsystem == "com.apple.tokengenerationcore"' --style compact On our machine the inference service (TGOnDeviceInferenceProviderService, category guided) prints these two lines in matched pairs, thousands of times: Generated an empty mask at recognizer index N allowedTokenIDs is empty. Something is likely wrong with the tokenizer Some numbers from beta 7 today: 9,008 of those pairs in about five and a half minutes. The errors start about one second into the first request after a fresh app launch. Requests that normally finish in 4 to 12 seconds take 77 to 170 seconds or longer. On beta 5 we measured decode at roughly 0.3 tokens per second on the worst requests. Short requests still finish at normal speed but they emit the same errors while they run, and the structured content they return looks degraded to us. On betas 5 and 6 we also saw repeated asset release errors for instruct_300m.tokenizer and the instruct_3b tokenizer saying the asset is not marked as in use. For what it is worth, a build that ran clean on beta 4 shows the same behavior on beta 5 and later with no app changes, and the same @Generable schema drives both the fast and the slow requests. But we know that does not rule out something on our side, and we would honestly be happy to learn this is our own bug since that would mean we can fix it. So two questions. Is anyone else seeing this since beta 5? And if you spot something we might be doing wrong on our end, sessions we should be recreating, schema patterns that stress the constrained decoder, anything at all, we would really appreciate the feedback. If it does turn out you are hitting the same thing, a Feedback referencing FB24310823 would help a lot. Thanks!

I'm seeing a reproducible difference in Foundation Models behavior between an iPhone 16 and iPhone 17 Pro Max, both running iOS 27.0 beta 6. My pipeline is roughly: Input → model generation → tool call → validation/correction → structured output Each test starts with a fresh model session. I run the same 50-case dataset on both devices with the same app build, prompt, tool, data, and execution order. The main difference is not just speed: the iPhone 16 consistently makes many more tool calls, which causes the session context to grow until some runs exceed the available context window. Both devices report a context size of roughly 4,096 tokens. Metric iPhone 16 iPhone 17 Pro Max Completed 30/50 49/50 Total tool calls 222 67 Mean calls/run 4.44 1.34 Max calls/run 22 2 Verified outputs 75.1% 91.0% The pattern is very consistent across repeated runs. On the 17 Pro Max, most requests converge after 1–2 tool calls. On the iPhone 16, some requests enter longer tool/correction loops and eventually fail because the context grows too large. I can probably mitigate this by limiting tool calls or changing the prompt, but I'd like to understand the underlying behavior. Is this difference expected across supported devices even on the same OS version? In particular: Can different on-device model variants be used depending on hardware? Is there a way to determine which model/profile a SystemLanguageModel session is using? Should tool-selection behavior be expected to remain reasonably consistent across devices? Would this be worth filing as a Foundation Models regression during the beta?

I keep running into rate limit issues that never go away while the app is running when trying to analyze images using Private Cloud Compute in iOS 27 Beta 6. After 20 or so images, I get a rate limit error from PCC, but the actual rate limit seems to come from SCML (see relevant log entries below). Once this happens, any attempted PCC requests result in an immediate rate limit error, no matter how long I wait, so long as the app is running. If I kill the app and relaunch, I no longer receive the rate limit error (unless, again I run several images through in succession). So it seems like once this state is triggered, you are stuck in it until you kill and relaunch the app. Has anyone else encountered this or have a workaround? I've filed a feedback already: FB24419603 Passing along Client rate limit exceeded, try again later in response to ExecuteRequest Passing along Client rate limit exceeded, try again later in response to ExecuteRequest systemPromptID failed for task textSafety: Rate limited. Wait a little bit and then try again.::Rate limited. Wait a little bit and then try again.: Client rate limit exceeded, try again later::Client rate limit exceeded, try again later; prompt template also not found: Rate limited. Wait a little bit and then try again.::Rate limited. Wait a little bit and then try again.: Client rate limit exceeded, try again later::Client rate limit exceeded, try again later End sanitizeText with error: Error Domain=com.apple.SensitiveContentAnalysisML Code=15 "SCML.CombinedTextSanitizerBackend.BackendError("SafetyGuardrailTextSanitizerBackend"): Rate limited. Wait a little bit and then try again." UserInfo={NSLocalizedDescription=SCML.CombinedTextSanitizerBackend.BackendError("SafetyGuardrailTextSanitizerBackend"): Rate limited. Wait a little bit and then try again., NSUnderlyingError=0x11a632ee0 {Error Domain=SensitiveContentAnalysisML.CombinedTextSanitizerBackend.BackendError Code=1 "SCML.CombinedTextSanitizerBackend.BackendError("SafetyGuardrailTextSanitizerBackend"): Rate limited. Wait a little bit and then try again." UserInfo={NSUnderlyingError=0x11a5dd380 {Error Domain=com.apple.GenerativeFunctionsFoundation.GenerativeError Code=1010000 "Rate limited. Wait a little bit and then try again."}, NSLocalizedDescription=SCML.CombinedTextSanitizerBackend.BackendError("SafetyGuardrailTextSanitizerBackend"): Rate limited. Wait a little bit and then try again.}}}

Hi all, We're currently evaluating Private Cloud Compute (PCC) for a technical accuracy assessment. No production release or monetization is planned at this stage — our only goal is to test/evaluate the model. Per the official documentation, PCC access requires: Enrollment in the App Store Small Business Program Fewer than 2 million first-time downloads The Private Cloud Compute entitlement assigned to the account To complete Small Business Program enrollment, our Paid Applications Agreement is currently stuck at "User Information Pending", and we're being asked to submit a bank account and U.S. tax forms (Certificate of Foreign Status of Beneficial Owner / Substitute Form W-8BEN-E) before the agreement can go Active. Honestly, we're having a hard time accepting that submitting banking and revenue-related tax documentation is required when we have no intention of selling a paid app at all. The Small Business Program itself is meant to be a reduced-commission program for developers earning revenue through paid apps/IAP — using it as a gate for free AI model evaluation feels like a mismatch. On top of that, we're a Japan-based company, which raises the bar further. The required tax forms (W-8BEN-E etc.) are aimed at non-US entities and require pulling in our legal/finance teams just to prepare — a fair amount of overhead for what is, on our end, purely a technical evaluation. Before we go through the internal process of preparing this documentation, I wanted to confirm: Is there any path to obtain the PCC entitlement / Small Business Program status for evaluation purposes only, without completing the full Paid Applications Agreement (banking + tax forms)? Is submitting real banking and tax information a hard technical requirement of the Small Business Program itself (i.e., the Paid Apps Agreement cannot go Active without it), or can an account remain PCC-eligible while the agreement is "pending"? Is there an official Apple document (beyond the general Small Business Program / PCC pages) that explicitly confirms banking/tax submission is mandatory before PCC entitlement can be granted? We need something citable for internal approval. For non-US companies (e.g. Japan-based), has anyone gone through this purely for evaluation purposes? Is there any simplified path for foreign entities, or is the full W-8BEN-E process unavoidable? Any pointers to official documentation, or confirmation from anyone who has been through this, would be greatly appreciated — we need a clear, citable answer to justify preparing this documentation internally. Thanks in advance.

Hello, My app fully relies on the new Foundation Models. Since Foundation Models require Apple Intelligence, I want to ensure that only devices capable of running Apple Intelligence can install my app. When checking the UIRequiredDeviceCapabilities property for a suitable value, I found that iphone-performance-gaming-tier seems the closest match. Based on my research: On iPhone, this effectively limits installation to iPhone 15 Pro or later. On iPad, it ensures M1 or newer devices. This exactly matches the hardware requirements for Apple Intelligence. However, after setting iphone-performance-gaming-tier, I noticed that on iPad, Game Mode (Game Overlay) is automatically activated, and my app is treated as a game. My questions are: Is there a more appropriate UIRequiredDeviceCapabilities value that would enforce the same Apple Intelligence hardware requirements without triggering Game Mode? If not, is there another way to restrict installation to devices meeting Apple Intelligence requirements? Is there a way to prevent Game Mode from appearing for my app while still using this capability restriction? Thanks in advance for your help.

After updating my iOS and xcode to latest iOS 27 beta5 and xcode 27 beta5 all the system language model session calls with tool calls inclusion throwing Unrecognized system-instruction prefix ID: com.apple.fm_api.tool_calls_override error. The same code was working perfectly in iOS27 beta 4. Even the apple sample project OrigamiCraftingADynamicTutorialForAppleIntelligence failing with the same error when tool calls invoked. Anybody else facing similar issue or any workaround for this issue? sample code: struct GetRecordNotesTool: Tool { let name = "getRecordNotes" let description = "Fetches internal notes and returns Note_Title and Note_Content for up to 10 notes." @Generable struct Arguments { @Guide(description: "The API name of the module, e.g. Companies or Contacts") var module_api_name: String @Guide(description: "The unique record ID to fetch notes for") var record_id: String } func call(arguments: Arguments) async throws -> String { return "Fetched content" } }

When using Private Cloud Compute, I want to be able to submit more than one prompt per LanguageModelSession, ideally using the prompt and response from the first interaction to inform a second interaction. How can I reference this first prompt and response when making a subsequent prompt in a session? I have tried plain language like "current data" and "previous prompt" but it does not seem to understand.

While building with Apple's Foundation Models, I kept running into a workflow problem before the app code itself. The hard part was not only calling LanguageModelSession. It was figuring out the shape of the interaction: What should be in the system prompt? What should stay in the user input? What output is actually usable by the app? How much instruction is too much? How do I test the same prompt repeatedly without creating another small Xcode project? I ended up building a small macOS tool for myself, LocalLM Lab, mainly to speed up that loop. The first use case was a Prompt Playground: system prompt, user input, model output, and a repeatable way to compare results before moving the workflow into app code. The current version also experiments with connector-style context, such as system clock, weather, reminders/calendar, contacts, and a scoped filesystem folder. That has made the prompt design problem more interesting, because the question becomes: what context should the model see, and how should the app frame that context so the output is useful? I am curious how other developers are handling this while building with Foundation Models. Are you mostly iterating inside Xcode playgrounds? Are you building small internal test harnesses? Are you separating system prompts and user inputs during testing? How are you evaluating whether the output is reliable enough for the app workflow? For reference, this is the tool I have been using for my own experiments: https://thisbrain.ai/locallm I would be especially interested in any patterns people have found for designing and testing prompts before committing them to app code.

Hi guys, I'm testing the Foundation Models Framework with the on-device model in iOS 27 (beta 4) and macOS 27 (beta 4) and is completely failing to respond. There are many errors. For starters, the model doesn't respond to prompts directly, you need to specify instructions, otherwise it refuses to provide an answer. It is always looking for tools, even when no tool has been provided, and returns an error saying that it couldn't find the tool. Then, when it produces a response, it shows all the thinking process first, which completely ruins the response. Most of the time, the response begins with all the JSON code. And when I try to have a long conversation, it just says "I cannot write content or generate text." I wonder if someone is experiencing the same issues or maybe the way to implement this model changed and I'm missing something? Here is a screenshot of one of my interactions when I asked the model to describe a unicorn. It tried to access a tool that doesn't exist. (the app just prints the value of the content property) Here is the code. It is performing a simple request. struct ContentView: View { @State private var response = "" var body: some View { VStack { Button("Send") { let prompt = "Write a paragraph describing a unicorn" let session = LanguageModelSession { "Respond to the user's request. Never acknowledge the request, add preamble, or comment on what you are about to write." } if !session.isResponding { Task { do { let answer = try await session.respond(to: prompt) response = answer.content } catch { response = "Error accessing the model: \(error)" } } } } .buttonStyle(.borderedProminent) Text(response) .font(Font.system(size: 18)) .padding() Spacer() } .padding() } }

On macOS Golden Gate Developer Beta 4 the following code: import CoreSpotlight import FoundationModels let tool = SpotlightSearchTool() let session = LanguageModelSession(tools: [tool]) let response = try await session.respond(to: "What hikes have I gone on?") , returns the following error: Model Catalog error: Error Domain=com.apple.UnifiedAssetFramework Code=5000 "There are no underlying assets (neither atomic instance nor asset roots) for consistency token for asset set com.apple.modelcatalog" UserInfo={NSLocalizedFailureReason=There are no underlying assets (neither atomic instance nor asset roots) for consistency token for asset set com.apple.modelcatalog} , although the model is available in general and can return responses without using the tool. The code: print(SystemLanguageModel.default.availability) returns 'available'. What am I doing wrong?

So I'm having an issue with the FoundationModels framework but idk if this is just my feeling or not, the issue comes up after I updated my Mac into 26.6 the code was very simple actually: #Playground { let model = SystemLanguageModel.default let session = LanguageModelSession(model: model) print(model.availability) var query = "How to hide button" Task { do { let response = try await session.respond(to: query) print(response.content) } catch { print("\(error)") } } } the code works before I updated the version, but then after I updated the version it says: Error Domain=FoundationModels.LanguageModelSession.GenerationError Code=-1 "The operation couldn’t be completed. (FoundationModels.LanguageModelError error -1.)" UserInfo={NSMultipleUnderlyingErrorsKey=( "Error Domain=FoundationModels.LanguageModelError Code=-1 "(null)" UserInfo={NSMultipleUnderlyingErrorsKey=(\n "Error Domain=ModelManagerServices.ModelManagerError Code=1026 \"(null)\" UserInfo={NSMultipleUnderlyingErrorsKey=(\n)}"\n)}" ), NSLocalizedDescription=The operation couldn’t be completed. (FoundationModels.LanguageModelError error -1.)} this is runned in Xcode 26.6, additional information I have also coder 27 beta 4 installed in my Mac, is this problem occurring because the Xcode 26.6 and Xcode 27 beta 4?? can u guys help me

I'm trying to use Foundation Models to identify the things in an image. That part is easy and is working well. I'd like to also know where in the image the things are. This is where I'm hitting a wall. For example, if there's an image of a horse and a cow, I'd like to be told (even approximate) coordinates of where in the image the horse is and where the cow is. Bounding boxes are fine for my needs. (Any coordinate system will work because it's easy enough to convert from one to another) The LanguageModelSession consistently lists the items in the image and gives me bounding boxes for their location that are reasonable approximations of where the images are in relation to one another, but it will (usually, not always) completely fail at explaining where the objects are in relation to the image as a whole, which is what I need. What's more, the failures are not consistent. Sometimes it will tell me that all the images are in the top half of the image. Other times, it will blow up the location of one or more objects in the image to multiples of their actual size. I've tried asking the LanguageModelSession to output the locations in various coordinate systems: raw pixel numbers normalized position (0 ... 1) integer percent position (0% ... 100%) a few different attempts at "soft location" systems where I just ask the LLM to tell me if the objects are in the top left corner or in the center for instance Of these, the "soft location" gives more consistent answers, but nothing that is complete enough to be usable. Asking for raw pixels gives answers that are ALMOST usable, but the position rectangles it gives are often off by one or two times the width or height of the object or suffer from the issue of "bunching" all the rectangles into the top of the image. I believe that part of the problem I'm having is that FoundationModels must downsample the image before processing. It appears that it's downsampling to 896px for the longest dimension of the image. Even accounting for this, though, I get strange output. Yes, I have considered using VisionKit's GenerateObjectnessBasedSaliencyImageRequest. It works well for another part of my project, but it doesn't fit exactly the particular need that I have here. It gives me locations of objects but not what they are. FoundationModels gives me what objects are in the image but not their locations. It may be that FoundationModels just isn't going to give me an accurate enough location for the objects in the image. It's a LLM, not a ML model, after all. If that's the case, I'd appreciate if someone would verify that so I can stop barking up this tree. It just seems like it should be possible, and I keep getting results that are almost accurate enough to be useful to me. Any help at all would be appreciated. Below are the instructions and prompt I'm using. let session = LanguageModelSession( instructions: """ You describe images to help another AI model identify and label distinct objects. Identify the distinct foreground subjects — objects, animals, people, or things that stand out as individual items someone would point to and name. Be specific (e.g. "a black and white cow", "a red coffee mug", "a wooden chair"). For each subject, provide a tight bounding box as pixel coordinates: - topLeft: upper-left corner of the box (x from left edge, y from top edge) - bottomRight: lower-right corner (x and y must be larger than topLeft's) - (0, 0) is the top-left pixel; x increases rightward, y increases downward - the exact pixel dimensions of each image are stated in the prompt you receive Also note background objects — items visible in the scene but not the main focus. Describe the setting — the background environment (surface, room, landscape, or space). Do not merge subjects and setting. A cow standing in a field has the cow as a subject and the field as the setting — not both as subjects. """ ) let prompt = Prompt { "Describe this \(imageWidth)×\(imageHeight) image. Bounding box coordinates are in pixels: (0,0) is top-left, (\(imageWidth),\(imageHeight)) is bottom-right." Attachment(modelImage.cgImage, orientation: modelImage.orientation) }

In the Foundation Models framework utilities package, the private method buildURLRequest in ChatCompletionsLanguageModel handles the construction of OpenAI-compatible API URLs: private func buildURLRequest(for request: ChatCompletionRequest) throws -> URLRequest { let isVersioned = baseURL.pathComponents.contains("v1") let endpoint = isVersioned ? "/chat/completions" : "/v1/chat/completions" let url = baseURL.appendingPathComponent(endpoint) ... } Problem The current implementation hardcodes "v1" to determine if the baseURL already includes a version. This limits compatibility with API providers using alternative versioning schemes. For instance, Volcengine Ark uses "v3" in its Base URL, making it difficult to seamlessly integrate their services. #Playground { let baseURL = URL(string: "https://ark.cn-beijing.volces.com/api/v3")! let modelName = "doubao-seed-2-0-mini-260428" let headers: [String : String] = [ "Authorization" : "Bearer \(apiKey)" ] let model = ChatCompletionsLanguageModel(name: modelName, url: baseURL, additionalHeaders: headers) let session = LanguageModelSession(model: model) do { let result = try await session.respond(to: "Hello").content } catch { print(error.localizedDescription) // HTTP error with status code 404: } } #Playground { let baseURL = URL(string: "https://ark.cn-beijing.volces.com/api/v3/responses")! let modelName = "doubao-seed-2-0-mini-260428" let headers: [String : String] = [ "Authorization" : "Bearer \(apiKey)" ] let model = ChatCompletionsLanguageModel(name: modelName, url: baseURL, additionalHeaders: headers) let session = LanguageModelSession(model: model) do { let result = try await session.respond(to: "Hello").content } catch { print(error.localizedDescription) /* HTTP error with status code 404: {"error":{"code":"InvalidAction","message":"The specified action is invalid: /api/v3/responses/v1/chat/completions Request id: 021784381168842fdfd2e3c33d5b6eddad55ac385080e727cab08","param":"","type":"NotFound"}} */ } } Suggested Solution To better accommodate different versioning conventions (e.g., v2, v3), we can leverage Swift's modern Regex (#/v\d+/#) to dynamically detect the version pattern in the path components. Here is a recommended update for the isVersioned check: let isVersioned = baseURL.pathComponents.contains { component in component.wholeMatch(of: #/v\d+/#) != nil }